What exactly is an IT system and how do you manage it? For more than 20 years I have worked with mid-sized and large enterprises, across industries, both in the US and in Sweden. I have come across the same challenge in all these organizations. How to manage their IT systems, or not, as is often the case.
Before we go on, I want to clarify that I will be talking about those IT systems that provide business value. I will refer to them as business IT systems or just business systems. There are also IT systems that do not directly provide business value. This figure illustrates the overlap.
There are also non-IT systems that provide business value, but for now I will be focusing on business IT systems.
Business Ownership
Business IT systems are more business systems than IT systems. IT is what they are made of, but providing business value is their purpose. Business systems should be owned and managed by the business side of an organization. It does not matter if the business system is made up of people or information technology.
Teams are systems made with people, but that does not mean teams are run by the Human Resources (HR) department. The HR department supports the business and IT should support the business in similar ways, when it comes to systems made with IT.
Business IT systems, because of their IT make up, often end up without any clear business owners. The IT organization is often responsible for taking care of the business IT systems and in many cases does not know who the business owner is. Before anyone disagrees with this last statement, let me clarify how I define business owner.
A business owner is the person or team that pays for all system costs, out of their budget, and is responsible for the business value the system provides.
With this definition of a business owner of a business IT system, can you identify the business owners of the systems you work with? Caretakers in the IT organization are not owners, even if they are funding the system out of their budget, because they are not ultimately responsible for the business value the system provides.
The main point is that an owner must be responsible for both the costs of a system and the benefits, i.e. the value the system provides. You cannot manage a system effectively if you do not understand and take responsibility for both costs and benefits to the organization.
When an IT organization is managing the costs of a system and the business organization is responsible for the benefits, then over time, the system will become less effective. IT will build what the business is asking for and the costs will be buried in an ever-increasing IT budget. A cost-benefit analysis or return on investment analysis for a project is meaningless unless they are followed up on after a project is over and a business party is held accountable. If you recognize this situation, then one problem likely is a lack of business ownership.
The good news is that it is simple to own and manage a business IT system. One goal in writing this article, is to make this clear. What is hard is changing the culture and the current way of working.
The first step is to realize and recognize that business IT systems are owned by the business and not by IT. Identify the business owner of the systems, and make sure they understand they are responsible and will be held accountable. This is easier said than done. It should also mean the business owner is empowered to make decisions. The budget of a system, which IT could manage, should roll up to the business owner. It is amazing how people start to pay attention once they are responsible for how money is spent.
You do not need some deep technical experience to own and manage a business IT system. No more than you need deep mechanical experience to own and manage a car. From a business ownership perspective, I need to understand that my car exists and roughly what it is. I do not need to understand all the parts that make up the car. To handle the detailed technical internals, we have mechanical or IT engineers.
The System Box
A business system can be simply described as a simple box using three different parts: structure, behavior, and information.
At the highest logical level, this is the basic information that best summarizes what a system is all about.
NOTE: I use the PrimaryScape modeling notation for most diagrams. I specifically created this notation to be a simple notation that can be used to describe real things, in other words — systems. Green is always used to represent information. Yellow (red border) is always used to represent behavior, functionality, processes. Blue is always used to represent the structure that realizes the behavior and information. Red, green, and blue are also commonly available whiteboard marker colors, which makes it easy to use this notation in workshops and brainstorming sessions.
Let us use a simple example of a customer relationship management (CRM) system.
This simple depiction represents a real system that exists within an organization. With this as a starting point one can explore and elaborate on different aspects concerning the system.
Inside the Box
One can drill into more detail about the functions/processes and the information the system handles. This is illustrated in the figure below, even if it still is an oversimplification of what a CRM system does.
Using the structure, behavior, information approach is also useful when documenting a system in writing. It is common for system documentation to describe the functionality of a system. It is also important to describe the information stored in the system. For the structure it is useful to describe how robust it should be, or the quality attributes of the system. For example, how a system handles an increase in users, an increase in information stored, an increase in processing, or the failure of an internal component?
Capturing a complete set of system functions and information in one diagram is not always practical. What is important is that by agreeing that a CRM system exists, one can use the highest level, simple representation to outline the scope of the system. When needed, one can capture/describe different aspects of a system to support different discussions or initiatives. The earlier drill down representation can be broken into different views, to communicate different aspects of the system. The figure on the left focuses on maintaining customer information. The figure on the right focuses on how customer information is used.
One can also break down a business IT system into its structural components. Using the CRM example, one can drill down into the structural components that make up the system. The figure on the right shows that the system is made up of an application, where the logic takes place, and a database, where the information is stored.
The simple breakdown can still be a logical representation. When looking into the application component, it may turn out that it is a pair of application servers set up in a cluster to provide greater reliability, as shown this figure.
Different detailed, inside-the-box views can be created and maintained as needed.
Outside the Box
It is important to understand how a system fits into a larger context. This is the outside the box perspective.
The most important context is the business system context. It shows the systems and teams that the business system interacts with, when the system is achieving its main purpose.
The figure on the left shows a business system context for the CRM system. In the figure on the right the direct dependencies to other systems are shown in red.
The business system context is great for understanding the current state of the system within the enterprise landscape. It is also great for describing target states.
The slideshow below shows how you can walk through a system context diagram in a way that makes it a lot easier to understand. Just remember, green is information, yellow is functionality, and blue represents structure. Click the arrow to move forward and backward.
ust like there are many different inside the box views that can be created, there are many different outside the box system contexts that can be described. It all depends on what aspect of the system one wants to understand.
Another outside of the box view of the system is how an organization is working with the lifecycle of the system. What is shown in Figure 12 is just one example of how to look at handling a system. For each of the activities below, separate diagrams can be created to link the system with specific teams and systems. Figure 13 shows how the different activities inform each other.
Even without going into further detail, sitting down to discuss how an organization handles a system is useful. The change process is the process most organizations focus on. Whether waterfall or agile DevOps approaches are used, depends on each system. Who is managing the system and how it is managed, is often not as well understood. How is a system monitored and what is being monitored? How is the support of the system handled? At a high level, these are all important to understand, as they should be driving costs for the system.
In Conclusion
A simple box to represent a business IT system is all that is needed to understand an IT system from a business perspective. From that starting point one can explore and understand more details inside and outside of the business system box. The strength of this approach lies in it starting with a representation of reality, of a system that exists in a system landscape that exists. Regardless of what processes or frameworks that have been adopted by an organization, understanding what systems exist is valuable, and understanding it will make you more effective.
Dsdfg