The complexity trap – scalable demand management

Most IT organizations struggle to keep the pace of the business evolution. Many IT organizations are seen from the business as inefficient but required to keep the company running. IT Managers struggle with the complexity of their landscape and the ever-growing demand and the tight timeline.

This complexity is one of the major hurdles for an evolutionary step into the digital transformations. This type of complexity does not correlate with the complexity of the business model. The complexity arises from mergers and acquisitions, the old business model which needs to be supported and the technological out-dated system kept because they are business critical systems. These are the most obvious reason why IT is complex. And not at least organizational structures and business goals for IT departments do not fit with the idea of lean, fast, adaptable IT. But one essential process that is overlooked is how the demand organization is structured.

Processes get over time more and more complex and require more systems involved. The demand view is either process driven or system driven. Both are not designed to reduce complexity. Both don’t see data as the core of requirements. Business is looking at functionality they would like to have. They don’t care in which system it is done, they care only about the business functionality (sometimes they favour a system). Process experts talk to systems experts, but what’s at the end missing what drives the complexity is the semantics of data used in processes and system. The semantics of the data used in the process and across processes is important to understand how a system should behave.

The current demand model splits the larger requirements always into smaller until you can map it to the systems.

Complexity is the result of splitting complex problems into smaller chunks to reduce the workload and give people the chance to overlook the area of work. The problem with this approach is that an informed decision requires a connection with multiple peers to draw the full picture of even small changes to data. Another weak point is that organization are build on roles which got overtimes decoupled from the required capabilities.

The business world is complex, this is not negotiable. But complexity should not be implemented 1:1 into systems. To find an abstraction it doesn’t help to look at capabilities, processes and functions. The key for this abstraction is, to understand data in structure and semantics, as they are used in the different business processes and business models. The focus on data and where it is used decouples the system question from the demand. Is the data identified, which forms the core data of your business, systems can be replaced without risking a business breakdown.

Getting away from the system view to an end-to-end data view requires analytic capabilities which are not required in a world where a system dependent view and a process dependent view are not aligned. Working with a data driven demand organization, the most important question to ask is: What is the intended use of the data? This question is orthogonal to the demand question raised by most demand organizations.

To ask the right the question and get behind the ideas of business requirements, a good basic understanding of business model and how it reflects on the data is needed. Let the demand organisation have stewardship for data across processes and system, helps to develop the required end-to-end understanding of the business model and prevents costly misconception. Essential to the business are not the process owners, essential are the demand managers who have the end-to-end view about your business data and the associated lifecycle. This know-how can’t be externalized. This keeps your agility and ensures a stable operation budget.

Data is nothing static, data has a life cycle and this life cycle define the value data has for an organisation. Some data are long-lived (e.g. contract data) other data ages (e.g. customer tracking data, production data) and become less relevant. Some data has high compliance requirements (e.g. customer data). If the demand organization is defined along data used in processes and across processes prevents optimization in a single system. On the other hand, people understand which functions are served by the data and from here they can find simple solutions to complex problems, driven by the complete view of data across the different system.

The semantics of the data is the key since the same data structure can be used with different semantics in different business functions. Looking at the semantics of the data, this is the key to decide if you need a central function or the data can be placed in different distributed systems without linking each other.

Changing your IT organization to a data-driven organization is a major change. This requires that you know your data flows. Not only on a high level but on the level where your business functions execute your business model. This change even reflects how your demand organization works with the business. This gets the whole discussion away from functions build into systems to data used in business functions. The required capabilities will lead to have more competence assigned to some roles and render other roles obsolete. This reflects your project portfolio planning, where you can prevent too many changes to same data objects.

The benefits of this approach lie not alone in a better, more consistent and faster demand management, it helps to get a clear picture of your IT landscape transformation. A technologically obsolete system which is business critical can be replaced if the data it maintains is understood. Agility is given back when integration is primarily viewed from the data aspect and not from the system aspect. The demand is more centralized and different demands to the same data objects are streamlined into will not end up with a different implementation. Overall, this approach allows your IT organization to more adaptable to the different load of demands. It creates, in the long run, a consistent and adaptable system landscape.