Two weeks ago, we wrote about the impact of multi-speed IT on the IT organization and enterprise architecture. Let us now talk about the different options for managing a multi-speed IT approach.
The management and governance of the agile fast track architecture and the stable and robust baseline architecture we discussed previously can be done through various options, which are shown in Figure 1. You might assume that we are just talking about a simple two-speed IT approach as mentioned elsewhere, but it is not as easy as it looks.
Why Bi-Modal IT Won’t Work
Many organizations tend to establish a Digital Office function that includes governance for new digital initiatives supported by a dedicated team. That sounds a bit like the bi-modal approach as advocated by Gartner. Just like any other approach, this has its pros and cons. Separate teams working on separate issues sounds like a good idea, as each team can concentrate on their specific tasks bringing this forward to the target.
However, it also results in a disconnection between the two teams. When establishing two different teams to work on two different tasks, the communication between them will suffer, independently from the quality of the communication strategy. Furthermore, the team of the stable baseline might feel disadvantaged in their reputation (being perceived as ‘slow’ and ‘old-fashioned’ compared with digital initiatives), access to resources and budget, and power and influence in the organization. This circumstance often leads to major conflicts between the two teams, and the quality of the work may suffer dramatically.
Furthermore, the bi-modal approach, unfortunately, does not seem to offer a sustainable, long-term solution. It is even found to be incapable of putting forward a potential solution to the simplified agility-stability problem. Moreover, organizations that actually implemented a bi-modal approach had to face harsh consequences, such as the formation of artificial silos for products, processes and people, and institutionalizing stagnation by deterring innovation in traditional platforms with the excuse that “if it ain’t broke, don’t fix it”.
Next to this, there is also a major architectural and technological challenge: the stable baseline systems need to be connected to the rapidly changing innovative systems of the new digital business domain, since they often contain core business data. Such systems of record are indispensable but difficult to integrate. Placing this integration and transformation burden on the digital business team may slow them down to an unacceptable pace, whereas the baseline team is already busy enough keeping the lights on, and dealing with new rules and regulations. Hence, it appears we need something in between, to bridge both the cultural and the technical differences between a stable baseline world and a rapidly moving digital business world.
Is Tri-Modal the Solution?
A tri-modal approach, as shown in Figure 2, offers a more sophisticated and flexible method than a simple two-speed scenario. This approach considers three different teams: the Pioneers, the Settlers, and the Town Planners. The Pioneers develop the target digital organization enabling innovation and co-creation, using agile techniques and methods. On the other end of the spectrum, the Town Planners represent the baseline, providing stable and robust services to the Pioneers and Settlers. Simultaneously, they manage external service providers via a service integration and management function and add value to the other teams. The Settlers are positioned in the middle and deal with transitions or rather transition architectures, helping the organization industrialize and personalize the target services, systems, and applications to fit with the baseline architecture, and to gradually transform that baseline architecture to accommodate the new digital business needs. They also ensure a better management of workflow and communication as it proceeds from one level to the next.
Towards a Cellular Structure
Evolving the tri-modal approach results in a cellular structure (Figure 3), where each team (or rather a team member of one such team) supports the teams above, fulfilling their objectives and thus being involved in the daily business of this team. Different teams are responsible for different parts of the IT, some focused on stable baseline functionality, some on advanced digital capabilities, and some in between. Applying DevOps practices implies that each team is fully responsible for building and running their part of the IT. Communication between teams happens on a daily basis at the ‘shop floor’, and necessary decisions across teams can be made quickly and efficiently. Furthermore, relevant stakeholders from business and IT can smoothly be integrated into the team work, contributing their views and providing strategic and tactical guidance when needed. Enterprise architects are one such group of stakeholders, tasked to ensure that the teams’ efforts and results are aligned with the organization’s digital strategy and medium- to long-term goals. Their broad scope and knowledge of the enterprise makes them pivotal factor. If you are in this position, take advantage of that knowledge and facilitate your organization in its business transformation journeys to come.