Following my recent article 'Still Building Shanty Towns', this post describes a strategy/execution loop using an adaptive change style. It illustrates the need to introduce feedback loops (the green dashed lines) so that the strategy continuously evolves. It also shows the importance of information systems in strategy formation and, later, the role of joined-up architecture between business and I.T. to bring the strategy to fruition.
This simplified model (based on my client interactions) aims to provide context to the C-Suite and then anyone involved in transformation planning. As is usual with many of my models, the logistics industry is my mental reference point, however, I'm sure it will apply to other operating models without much adjustment.
Of course, it goes without saying that strategies always evolve. Partly due to the long timeline and partly in response to markets and competition - all four VUCA aspects apply. The addition of intentional feedback loops provides a useful guard-rail for continuous improvement & adaptive change. From a more parochial I.T. perspective, it provides a needed back-channel to the C-suite. The model also helps to illustrate the need for peer level participation across the entire cycle.
This first provides a view of the overall context, but is hard to read. Please scroll down to view readable slices.
I show building the Vision as a C-suite Accountability where all CxOs (including the CIO & maybe the CTO} take an active role. You'll note that information (but not usually technology) is always an explicit part of the CEO-Owned, 'Enterprise Vision'.
Building out from the vision, there are four fundamental planning and forecasting activities. These represent the minimum and could be augmented by others, like HR, if the proposed change has a high impact on the workforce or, if for example Unions need to brought in early for consultation.
Moving again from left to right, the ever contentious area of Enterprise Architecture comes to the fore. To try to keep things simple, the 'Enterprise Architecture' domain includes Business Architecture and IT Enterprise Architecture. In know these labels/taxonomy creates a huge amount of debate. Here's the rationale for this representation:
In plain English, an Enterprise is either:
a project or undertaking, especially a bold or complex one. "a joint enterprise between French and Japanese companies".
a business or company."a state-owned enterprise".
So it makes sense to make it the higher order for collective understanding.
I the refer to Business Architecture as separated concept from IT because this is how it's most commonly understood. It should include every aspect that will be touched by the pursuant transformation, except Information Technology (although in the case of a Utility firm, it will likely include Operations Technology).
'IT Enterprise Architecture' is a commonly used term for 'big' architecture covering most, if not all, IT applications, databases, messages, software & hardware infrastructure and environments (e.g. Cloud or On-Premise). In this sense, 'Enterprise' has a subtly different meaning - simply put, the on-going undertaking of planning, designing & managing information technology. Note the role of the 'Enterprise Architect' spans business & IT domains, even though he/she usually live in the IT function, reporting to either the CIO, CTO, or Chief Architect.
The last panel shows the flow into execution of the transformation required to implement the strategy. In this example, there are two main change programmes, one for Operations and another for IT. The blue cycle arrows indicate the necessary continuous coordination between the programmes. Again, also note the green feedback loops that lead back to top-level strategy.
The aim of this simplified model is to engage the C-Suite, and others executing strategy, leading on to discussion about:
The need for an evolving and adaptive strategy
The need for the CIO to be a 1st Class citizen in Strategy formation and execution.
The value of architecture (Business & IT) i.e. delivers the blueprints for realising the strategy (Note: Project-centric Business Requirements don't do this)
How Design Thinking applies - Innovation through iteration, a Safe-To-Fail (managed risk) environment, anti-fragile systems, and response to VUCA.
An adaptive, evolving, inclusive strategy, is the only way to thrive, or maybe just survive, in a turbulent world, evermore dependant on IT. You may well have other models and approaches to achieve this - let's discuss.