Digital Transformation: How to Manage and Govern a Multi-Speed IT Environment – part I
Feb 8, 2016
Looking back to many discussions about Digital Strategy with different organizations, most of them have the challenge of going through a balancing act day by day. Firstly, a Digital Oriented Organization needs to accept that the roles and responsibilities of Business and IT will merge together, whilst both parties need to enable business and IT innovations towards digital business needs. Simultaneously, they need to set up an agile approach across the whole organization for developing and managing innovative digital business models, dealing with new business moments, and realizing the associated technology and services. Finally, cost control for IT and its services also remains high on the agenda of the organization.
Such changes are especially difficult in organizations with a large legacy base, both in terms of IT and in terms of organizational processes and culture. In finance, for example, we see that banks and insurers are under attack from nimble FinTech companies and struggle to respond in a timely manner. They are weighed down by complicated IT landscapes, a risk-averse culture and ever increasing regulatory compliance demands. In architectural terms, they have an outdated baseline architecture in place and need to develop a new target architecture to enable innovative and digital business models, best realized by an agile approach.
But at the same time, they cannot simply replace the old systems that run their core business processes, or radically change the way these systems and the associated business processes are maintained. The operational risks, compliance demands and the culture of the development organization preclude such a radical approach. This is where the so-called two-speed IT approach comes into play; the IT and Enterprise Architecture teams need to manage the complexity of both worlds: the stable, risk-averse legacy environment and the innovative and agile digital business.
The stable and strong baseline architecture is reflected on the right side of the picture below. This is fully managed by proper portfolio, architecture, and release management based on defined and established methods, standards and frameworks. This architecture is normally quite stable and underpinned by robust internal and external services, which seldom change during the year. The focus is on reducing cost and risk, keeping the lights on for the business, and not on developing innovative business and IT solutions.
In the context of Enterprise Architecture, the target architecture represents the envisioned future state of the organization, which partly replaces and transforms the baseline architecture. Nowadays, the development of a target architecture is mostly a medium-term transformation project, taking 1 or 2 years to implement a full complex architecture landscape and solutions across various business and/or IT domains. But is this really sustainable in the near future? The speed of change of the environment and the competitive pressure from innovative new players demands a much faster response. In our view, this approach will change dramatically, or rather is already changing in many organizations.
Even in the near future, we will talk about developing and integrating micro-services into the existing architecture landscape, and we will be faced with managing these services and their related service providers, creating an entirely new role for architects.
So, let us assume an insurance company plans to develop a community platform to enable co-creation for designing and developing new insurance products. Simultaneously, they want to improve the customer experience by proper omni-channel management. From the current perspective, this seems to be a medium-term transformation project, which we see all the time. To be fair, they are even taking too much time to pick the low-hanging fruit.
But what happens if you break it down into smaller bunches of services, or rather micro-services, to be developed by different providers and other players using an agile approach? Using methods and concepts such as minimal viable products, agile development and DevOps, each of these smaller services can rapidly be developed and deployed to prototypes, and end up as working products within 2-4 weeks. In doing so, it is crucial to understand that this approach entails fast and agile experiments which may also fail. Consequently, a culture of accepting failures, learning from them and doing it right afterwards is essential for long-term success. You can also think about so-called AB-testing, trying out different variants of services with customers for identifying which variant works better in practice. No one has the right answers right from the beginning, so you just have to test what fits better to customers. Naturally, this approach implies a fast and agile development process with frequent releases of new services, coordinated by concepts like the Agile Release Train from the Scaled Agile Framework. These agile release trains, combined with the infrequent releases of the stable baseline architecture are jointly considered as part of the Enterprise Portfolio Management function we wrote about last year.
Figure 1: Two speed IT and Enterprise Portfolio
So, the enterprise architecture team has to manage and govern both worlds towards a common digital architecture vision and strategy. But the crucial question here is how to manage and govern this digital world? Quite often you hear about approaches like bi-modal or tri-modal IT. But do these really help you deal with the complexity of digital transformation? We will address this in our next blog.
