Now that we have wrapped up Perspective 4 around Business rules, and had our special bonus interview with Robert Thacker on Process Mining and Process Automation, it’s now time to talk about Perspective 5: The Systems. If you have missed the previous Perspectives you can find them on my blog.
First, we should start with defining what a system is for the purpose of this perspective. If you have ever studied the concept of systems thinking, you know a system is defined as more than just technology. A system in the context of systems thinking consists of interacting, interrelated and interdependent components to form a complete whole. So, a system is made up of many components, not just technology. A system consists of the organization culture, framework, processes, resources, technology and more. However, for the context of this perspective we will be focusing on technology. We will focus on what a system is from the standpoint of technology, how systems work independently and with other systems, how to identify systems, why having this knowledge is important, and finally we will wrap up with the system context diagram technique as a way to visualize systems.
Before we get started there is one item I do want to address. There may be some of you reading this post that are business analysts, and I want to address a question I receive a lot from business analysts in regards to, what technologies do you have to know in order to be a successful business analyst. My answer to that question is, it depends! There is no way you can learn every single technology/software language out there. You will lose your mind. It’s just not a realistic goal, and you will swirl forever trying to keep up. However, there is some reflection you can leverage to determine (1) do you need to know certain technologies to be successful in a certain industry? (2) What technologies do you need to know to be successful in your role if that is required? (3) Do I want to work in an environment as a business analyst where I have to be a technical business analyst? Here are some reflections to consider:
Determine if the business analyst role you want for your career is focused on the business side, technical side, or you’re open to both.
Based on the business analysis roles you are interested in pursuing, determine if you see patterns of technologies mentioned in the job descriptions consistently. If so, this may be a clue for you there is a need to know certain technologies/system languages (such as SQL as an example).
Determine if there is a certain industry of focus you desire, or if you want to work in different industries.
If you have determined there is a certain industry of focus, determine if that industry leverages certain technologies that would be beneficial for you to know, and at what level.
If you have determined you want to work in different industries, understand the main technologies that are used so you have an idea on what is required without having to know them inside or out, unless required.
As you can see, there is no black and white answer to this. Actually, there can be quite a bit of grey. It boils down to the needs of the organization, and the organizations expectation of certain roles. It can even depend on where you reside geographically, as some geographies have different requirements.
Now that I have addressed that question, let’s go a little deeper into Perspective 5.
What is a System
As stated earlier, when I reference systems for this perspective, I am specifically referencing the technology systems, or applications organizations use to deliver services to their customers. Examples, could be user interfaces, mainframes, databases, artificial intelligence, robotics, and more. Now, the complexity comes with understanding what the systems are, what the systems do, how the systems interact with other systems, or if they are a stand-alone system. Every organization has a system of some kind leveraged to deliver services. Sometimes finding out what those systems are, and how they are used is challenging, but it can be done.
How Does a System Work?
A system helps to deliver some type of a capability/service to an end user/consumer. Input(s) trigger the system to perform some sort of task. In some instances, there may be other systems (sub systems) that are leveraged by the main system to complete the task. In most cases there are also controls in place to ensure the service functions as expected (that is the hope anyway 😊). Once the task is completed some sort of output is rendered which delivers some sort of capability to the end user/customer. The diagram below depicts what this might look like visually.
To give an example to bring this to life. Most of us have some type of bank product.
Let’s take your checking account as an example. Let’s say you want to deposit a check you received via your phone to your checking account. Here is what the system may look like to deliver this service outlining the components above in the diagram:
Input(s): Phone and check
System: Mobile Banking System
Sub System(s): Customer Management System, Deposit System, Phone Mobile App
Customer Management System – Houses the customer information
Deposit System: Processes the transaction to post to the checking account
Phone Mobile App: Connects to the main mobile banking system to complete the transaction request
Controls: Authentication of customer prior to access to the mobile banking system
Output: Confirmation message check was electronically deposited into account
Capability: Allows customer to deposit checks through their mobile phone
This is just an example on how a system works and interacts with other systems. Knowing this type of information is great because it can help you understand capabilities that already exists, capabilities that may not exist that can deliver a better service to the customer, and much more.
Let’s discuss a little bit about how to identify systems.
How to Identify Systems
There are few ways you can identify what systems are used in an organization:
Ask – create a relationship with your technology partners where you can either ask questions, or see if they have system architecture, or design, documentation you can review to help you understand the different technologies leveraged in the organization. Having a strong relationship with your technology partners is critical, because at the end of the day the developers are helping to make dreams and wishes a reality. Who better to gain knowledge from, than those who helped to create the reality?
Research – find existing documentation that explains the systems in play, especially if you do not have access to your technology partners easily.
Process Analysis – as you are analyzing processes, or even better yet, documenting them, you will uncover systems that are leveraged. We discussed how to document processes earlier on in Perspective 3, if you need a refresher.
Observe /Job Shadow– conduct side by sides with individuals who do the work. Observing what others are doing brings a lot of clarity. It also identifies gaps that may have been missed
Past Experience/History – if you have worked for the organization before, or have worked in a different part of the organization your previous knowledge can help you put the pieces together. Also, if you have worked in a certain industry for the majority of your career you might find there are certain technologies used more consistently and that knowledge may help you uncover what may, or may not be there.
Why is Knowing Important
As stated above, depending on your job, you may not have to know the technologies in detail. However, having some common knowledge of what the systems are, and how they work is beneficial for the following reasons:
You have knowledge of what is out there already, so when it’s time for potential solution recommendations you know what is currently delivering on the business needs, and what is not.
You have knowledge of how systems integrate with each other which gives you insights on complexity, or simplicity of infrastructure.
You have knowledge on where there are technological gaps and can offer options on how to fill those gaps.
You have knowledge on where data is housed, and how it’s housed that deliver services to customers (more on data coming in Perspective 6).
You have knowledge on some of the common technologies used for the industry in which you work.
You have knowledge on where systems are used, and if there are opportunities to leverage those systems in other parts of the organization.
You have a more granular understanding of the engine(s) that are behind the processes and if they producing the optimal performance for the best service to your customers.
You have knowledge on where there may be gaps in processes that can leverage existing systems to make the process more efficient.
These are just a couple of high level examples of how understanding the systems architecture in an organization is powerful. Though you may not the coding, or language used to drive the system functionality, knowing the systems, and the capabilities of those systems is extremely powerful.
Until next time, signing off,
The BA Martial Artist 🥋
P.S. Sign-in and leave a comment below, I would love to hear your comments.