Strategic Planning Framework
The following diagram depicts at a high-level our Strategic Planning Framework:
In our view Strategic Planning can be broadly split into two activities. The first is determining the strategy itself – How will we compete? What differentiates us from our competitors? What are our Values? We refer to this as an organisation’s DNA. This first part tends to be more stable and only undergoes major revision in the case of major changes to the business and/or its environment. M&A activity and major events like the Global Financial Crisis (GFC) in Financial Services being classic points at which an organisation may wish to re-visit these core strategies. The arrival of the National Broadband Network (NBN) in Australia is a similar “game changing” event which would likely cause Internet Service Providers to revisit their core strategy.
The second part of Strategic Planning is our view is how is how to actually execute this strategy? For the period of an organisation’s strategic planning horizon, this differs for every organisation and industry segment but let’s say three years for the sake of example, what outcomes are we going to achieve? (What are our goals and objectives?) Where are we now? Where do we need to be? What do we need to do to make that happen?
Organisational DNA – “Who we are, who we aren’t”
Firstly, to be clear, Fragile to Agile does not help an organisation determine its core strategy or Organisational DNA, we simply capture the key aspects of it that have a material impact on an organisation’s Enterprise Architecture. If an organisation has not already determined the answers to the questions below we can help facilitate this conversation, but our preference is for this to be done with our partner organisation, 2nd Road. Similarly, the sections below only discuss the questions that do have a material impact on Enterprise Architecture and are by no means an attempt to cover off on all the questions that an organisation needs to address as part of its strategy determination.
Private Sector Organisations
Government Sector Organisations
How we will compete
The most important question here with respect to Enterprise Architecture is on what basis does the organisation compete? Does it compete on price, product or service and if a combination of these which is the primary and which is the secondary (attempting to compete on all three is not typically viable)? Most importantly for an organisation with multiple business units do they all compete on the same basis? The impact this has on an organisation’s Enterprise Architecture can be quite profound. If you are competing on price for example the cost of solutions is naturally more important to you that an organisation that competes on either product or service. If different business units of the organisation compete on a different basis, say one on service and one on price, think of the implications this has for these two divisions agreeing on a solution to a particular business capability.
Value Proposition
The most succinct way of expressing this aspect of an organisation’s DNA is can you answer the following question unambiguously – What makes a customer choose us over a competitor? Is it the same for all business units of the organisation? From this you can then determine what business capabilities provide your source of competitive advantage. The Fragile to Agile Business Capability Model is the ideal vehicle to support this conversation. Again the impacts this has on an organisation’s Enterprise Architecture are significant. One example of this is the key decision whether to buy or build an IT solution (or more broadly insource or outsource the business capability). Clearly it makes more sense to consider building a dedicated IT solution for your organisation to support business capabilities that contribute to your competitive advantage. The corollary to this being that it makes no sense to build a unique solution for your organisation for a business capability where you only need to be “in-market”.
Operating Model
The term operating model is used in many different ways by different organisations. Here we are using the term as described in Wikipedia and in more detail in the seminal publication “Enterprise Architecture as Strategy“. The following diagram summarises the key concept:
The first point to make is that for mono-line organisations that only have a single business unit the operating model is by definition Unification. For all other organisations the operating model is determined by placing yourself on the above grid based on the desired level of cross business unit process standardisation and the desired level of cross business unit process integration. For very complex organisations a matrix of operating models is possible, e.g. unification for a number of business units and co-ordination for others.
This is one of the most critical strategic decisions an organisation makes with respect to its Enterprise Architecture. The above cited book discusses a lot of these impacts. At Fragile to Agile we have developed a technique, using our Business Capability Model , to take this to the next level of detail. By overlaying the Operating Model Decision on the Business Capability Model and taking into account any differences in how each business unit will compete and their value proposition we can determine where it makes sense to share a solution for a given business capability across different business units and where attempting to do so would be counter-productive and negatively impact competitive advantage. Most importantly correct consideration of these factors simplifies Business Change Management and helps significantly in minimising resistance to change.
Values
Of the four major areas of an organisation’s DNA, the values area typically has the least impact on Enterprise Architecture. There are however some notable exceptions. For example if an organisation has “green” as a value, assuming it is not just “green washing” then this will have an impact on a number of design domains, for example Infrastructure Architecture.
Making the Strategy Executable
It is one thing having a strategy. It is quite another to have a plan to how to realise that strategy, in our terms how to make that strategy executable.
This is summarised quite well by Wikipedia:
“Strategic planning is a very important business activity. It is also important in the public sector areas such as education. It is practiced widely informally and formally. Strategic planning and decision processes should end with objectives and a roadmap of ways to achieve them.
One of the core goals when drafting a strategic plan is to develop it in a way that is easily translatable into action plans. Most strategic plans address high level initiatives and over-arching goals, but don’t get articulated (translated) into day-to-day projects and tasks that will be required to achieve the plan. Terminology or word choice, as well as the level a plan is written, are both examples of easy ways to fail at translating your strategic plan in a way that makes sense and is executable to others. Often, plans are filled with conceptual terms which don’t tie into day-to-day realities for the staff expected to carry out the plan.”
The Fragile to Agile Enterprise Architecture Framework was first designed to address this very problem. The following diagram depicts how it is used to achieve this.
The first thing we do is determine, or capture if it already exists, the outcomes expected to be achieved over the Strategic Planning period. We refer to this as Strategic Business Intent and it is considered over a number of domains as shown above. From there we traverse the framework for each domain of design within the broad categories of business, people and technology design. For each domain we describe the key features of that domain required to implement the strategy and achieve the desired outcomes. Most importantly we define a set of principles for each domain, a set of “building codes” if you like, that must be adhered to if the desired outcomes are to be achieved. Each of these principles is linked back to the business outcomes that are helping to achieve.
To use the analogy of the Westminster form of Government, traversing the Framework at this strategic level lays down the legislation, laws, in each domain that must be followed in this organisation. The Architecture Governance Framework establishes the Police Force and Courts aspects of the system.
Finally, where an organisation faces the need for a significant refresh of its information technology solutions in order to achieve its desired outcomes the Solution Architecture domain of design requires particular focus. We first assess the current state solution architecture and its ability to support the outcomes; we then determine the target state solution architecture and the set of projects required to move from current state to target state. This approach is superficially the same approach used by most organisations. However, at Fragile to Agile we utilise our Business Capability Model, taking into account the Operating Model and other organisational DNA inputs, to drive this process. This business driven approach is core to our philosophy; it is part of our own Organisational DNA.
