Using Enterprise Architecture to Drive IT Strategy, Architecture and Planning
“Technology can bring benefits if, and only if, it diminishes a limitation.”
Eli Goldratt
A strategy is the explicit set of choices that an organisation makes to succeed in achieving its objectives and goals. It acts as the ultimate North Star, guiding investment and focus. A plan is a list of the activities that describe how you will get there. In IT strategy deployment we have two levels of planning: tactical and operational. The relationship of IT strategy and tactical and operational planning can be seen in Figure 1.
- IT Strategy represents the highest level of intent, the city plan if you will. It focuses on the long-term actions IT will focus on to close business capability, value stream, or csutomer journey gaps required for the business to win.
- Tactical planning takes that intent and turns it into a concrete architectural vision (both technical and organisational) that we can drive toward. You can think of this as the district plan. Tactical planning defines the large steps, Tactical Initiatives, to achieve that architectural vision and thus deliver on the strategic actions.
- Operational planning covers the programs, projects and or product team investments, the Operational Actions, that we can execute to move toward that vision. Think of this as the blueprints that will be used to construct the buildings.
Why Strategy is Critical
“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”
Peter Drucker
There is a myth that you don’t need strategy if you have agility. Unsurprisingly, this is simply not the case. Agility cannot replace strategy. Agility is the ability to adapt your path toward a goal. Strategy is about clarifying the goal and giving clear direction and alignment. Without this there won’t be a focus on the right things. If you are not focusing on the right things, then it doesn’t matter how agile you are at achieving them as it’s likely to have little benefit to the success of an organization.
Strategy is the choices we make on where to focus effort. It is about where we need to be agile to sense and adapt to exploring new opportunities, where we need to exploit our advantage by being lean and removing waste, and where we need to standardize and outsource when there is no competitive advantage.
Without a strategy you have no framework for making decisions or understanding trade-offs. Without the strategic bigger picture, it is difficult to determine the effective use of the organization’s resources and capabilities. Without a strategic context, all initiatives can be deemed worthy of investment if they result in a measurable business improvement. This, however, quickly leads to siloed thinking and local rather than global optimization, or in other words, departmental goals over the business goals. Strategy can be used to determine that which is critical to success and that which is simply an improvement to business performance. This can speed up priority decisions and quickly highlight wasteful or vanity projects. Fundamentally, you need a target; you need a clear set of choices, a strategy for how you intend to contribute to the organization’s success. We can then be agile and sense and adapt on the path to achieving that target.
Using Enterprise Architecture To Guide Strategic Planning
To guide our strategic, tactical, and operational planning, we can utilise the practice of enterprise architecture. Enterprise architecture (EA) is a blueprint for how IT will be used to contribute to meeting business goals. EA has gotten a bad reputation for being too high-level and impractical to be of any use. This is largely down to the proliferation of the many overly abstract and complicated EA frameworks. However, in The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment (SK Publishing, 2018), Svyatoslav Kotusev has written a very practical book on the subject based on the reality of EA rather than what people believe it should be. In the book, Kotusev details the CSVLOD (Considerations, Standards, Visions, Landscapes, Outlines and Designs) Model, as shown overlaid with the three levels of strategic planning in Figure 2.
We will use this model and the various artifacts associated with each component to build our strategy. Kotusev’s book is centered around aligning IT action with business strategy. At its core, EA is nothing other than an alignment exercise, alignment between the business intent and IT action. EA plays two roles in alignment; the first is to convert strategic intent into something actionable, and the second is a bridge from action to technology contribution. It’s important to note that EA is also a continuous process rather than a one-off exercise.
Figure 3 shows the artifacts from the CSVLOD and how they relate to each level of strategic deployment.
Strategic Level: Setting out our long-term strategic intent
- Considerations are high-level, clear, and concise statements that describe long-term strategic intent. These can be in the form of guiding principles, policies, or descriptions of actions we will take. They are simple to read and business-focused, applicable to both IT and business. These are the fundamental considerations we need to take into account when planning.
Tactical Level: Building a vision and a bridge
- Visions represent the conceptual view of the organisation, detailing the are typically in the form of target architecture state diagrams or a road map of initiatives. As with considerations, they are business-focused but are more detailed in order to guide and prioritize IT investments.
- Landscapes are the technical artefacts describing the current IT landscape. Typically these are technical diagrams and inventories of IT applications, infrastructure, and interfaces.
- Outlines are the high-level descriptions of IT initiatives required to deliver the vision. Again, these are focused on the benefits to the business but also contain more detailed solution overviews and options.
Operational Level: The executable projects, programs and product investments to build the bridge
- Designs are the detailed and actionable solution artefacts used for teams to execute IT projects, programs or invest in products.
Applicable to all levels:
- Standards describe the high-level technical rules, principles, patterns, and best practices to guide to IT execution.
Strategy Nomenclature
The terminology that people use to describe the creation of strategic planning throughout the business and in IT is often used interchangeably or inconsistently, leading to confusion. Figure 4 is a glossary of some of the terms that are associated with each of the levels of strategic planning to help your orientation.
IT Strategy is about articulating Intent
“Strategy is essentially an intent, rather than a plan.”
Steven Bungay, author of The Art of Action
In his book The Practice of Enterprise Architecture, Svyatoslav Kotusev refers to a consideration artefact called Direction Statements. Kotusev describes Direction Statements as:
“the most action-oriented EA artifacts of all Considerations. While other Considerations merely describe how an organization needs to work or analyze the technology environment, Direction Statements point to a certain direction where an organization needs to go in the future and explain the rationale for this direction. However, they still do not provide any specific details regarding how exactly it should be done. Essentially, Direction Statements only indicate where an entire company needs to go without specifying how.”
I have been referring to these Direction Statements as strategic actions. These actions will guide the more specific planning decisions at the tactical and operational levels.
The IT actions will bridge the business capability gaps or create new capabilities. These actions should clearly articulate what IT is going to do, in alignment with other business functions, to contribute to business success. The IT strategic actions should focus on the key strategic contributions and therefore should not represent everything you will do. Do not be distracted by noncritical capabilities (i.e., avoid Bikeshedding, aka the Law of Triviality). Don’t spend time on relatively unimportant but easy-to-grasp capabilities that you will supply, such as a service desk or collaboration tools, unless these capabilities are critical to the organization and will result in competitive advantage. Instead focus only on what is critical to enable the capability directly linked to business strategic choices.
The strategic actions that you propose need to be measurable. They should not simply show an improvement to a capability, they also need to show how the improvement leads to business impact that contributes to a strategic objective. For example, the capability improvement measure could be quantified as a business outcome of “We will adjust our prices every 20 mins by scraping our top 5 competitors.” That would lead to a business impact of “increasing market share by 10% due to price parity” that contributes to a strategic goal of “becoming the market leader.”
Figure 5 gives an example of some IT strategic actions
Tactical Planning: Deploying Strategy
“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.”
Sun Tzu, The Art of War
Strategy defines the high-level guidance on what a business and IT need to do to achieve the organization’s long-term goals and aspirations. However, the strategic actions only give us direction; they are not immediately actionable. To understand exactly what solutions we will invest in and the most appropriate way of operating, we need to understand the tactics required to deliver on the strategic direction. Tactical planning is the process that turns strategic intent into IT initiatives that in turn can be distilled into programs, projects or product investments to be executed at the operational level. You can think of tactical planning as the bridge between high-level strategic action and low-level operational execution.
The process of tactical planning is essentially about gathering facts and making decisions. Figure 6 lays out the flow of a common approach to tactical planning, what Svyatoslav Kotusev refers to as decision paths. I say common because different organizations will have different ways of operating, and different scenarios require more or less process. What I present here is the core artifacts and decision paths that have worked effectively for me in the past. As highlighted in Figure 6, we will use several artifacts covering the standards, visions, landscapes, and outline components of the CSVLOD model to support our planning decisions.
The two main processes of strategic planning are as follows:
- Determine the target architecture features required to support the business as well as addressing any architectural optimisation needs.
- Identify and prioritize IT initiatives into a road map.
The process involves designing a target state for both the technical architecture and the operating model based on the strategic actions and business capability needs, then defining the initiatives to move toward that target state. The output of the process is a tactical investment road map detailing the selected initiatives and an investment budget, required to achieve the strategic goals. As Svyatoslav Kotusev very articulately sums up in his book:
“The overall meaning of this process can be best summarised as strategy-to-portfolio, i.e., converting an abstract business strategy into more specific suggestions regarding the desired IT investment portfolio.”
1. Determine the target architecture features required to support the business as well as addressing any architectural optimisation needs.
In order to realize the strategic actions we will need to make changes to the IT architecture to address the business capabilities in need of improvement. Each action will require target architecture (technical and organisational) recommendations to provide technical capability as shown in Figure 7. The goal of the target state suggestions is to show how we intend to use technology to address business needs and how the landscape can be consolidated to reduce complexity. The aim is not to create a highly detailed and executable diagram of the future state of the IT landscape. The intent is to establish a vision and standards, the purpose of which is to help guide the planning effort at the solution architecture level.
2. Identify and prioritize IT initiatives into a road map.
As shown in Figure 8, an initiative is the link between the strategic intent and operational execution. It’s a way to take the abstract vision of the company and turn it into a tangible goal that we can build an operational plan around. A strategic initiative proposal focuses on a specific goal, typically framed as a business outcome with a high-level solution, effort, and cost along with an accompanying business case. Initiatives can include operating model changes like the creation of new product teams or changes in the ways of working. Some will be cross-cutting, some focused on transformation, and some focused on brand-new business endeavors. Others will be focused on improving constraints of existing capabilities. Some will be driven by the product strategy, others by marketing or finance business needs. Some initiatives will be delivered in an agile way by small internal product teams, while others will need to integrate off-the-shelf software and may use a partner. Initiatives can vary in size from transformational, consisting of multiple projects and programs spanning many years, to a solidarity project with a much shorter time frame.
Figure 9 gives an example of some tactical initiatives.
The initial drafting of a roadmap, as shown in Figure 10, helps to reveal the feasibility of the business strategy given the current investment strategy and capacity of the organisation. The process of deciding how to phase the initiatives can be rather subjective. Gaining agreement on the phasing approach is an iterative and often a political process.
What about Product teams??!? This doesn’t sound very agile?!?!
This is agility — using the appropriate method based on the context of each initiative. Larger initiatives may themselves have multiple sub models within them. This is the essence of the adaptable and agile operating model. Understanding context of the problem you are trying to solve and apply the appropriate technical and operating model solution.
Transient teams formed for specific projects is not an anti-pattern and is sometimes necessary for large one-off changes or cross-team collaboration. However, this shouldn’t be the default mode of organization if you want to be able to adapt quickly, deliver at pace, and have healthy teams that are intrinsically motivated. In terms of the product mode operating model you can think of initiatives as the large outcomes we set product teams or product groups.
Operational Planning: Execution
Solution Designs, the last step of the CSVLOD model as shown in Figure 11, extend the high-level tactical initiatives by providing a more granular level of technical detail to show how teams will contribute to achieving the tactical initiative. Tactical initiatives focus on the longer term, so by design they are not particularly detailed. Whereas the role of a solution design is focused on the short term, explicitly defining how a solution will be delivered and how it will encompass the enterprise architectures target suggestions for consolidation and optimization. Solution Designs will vary in detail depending on the nature of the problem they are solving. If the solution is to support the exploration of a new problem area, where there is complexity and unknowable unknowns, then the solution design may only cover the technologies being considered, such as frameworks, integration strategies, databases, and third-party services plus the initial product team set up. Where the problem is better understood, it makes sense to invest in more substantial upfront planning and a more detailed design. Where the decision is to buy, the solution design may resemble a request for project (RFP) or request for information (RFI) and include a list of requirements for potential system vendors.
Figure 12 gives some example of operational actions. These can be product team investments, programs of work or single projects.
Feedback, Learning, and Adapting
“However beautiful the strategy, you should occasionally look at the results.”
Winston Churchill
Change is the only thing that you can rely on. Strategies, tactics, and operational plans need to be constantly reevaluated, adaptable, and fluid, factoring in new learnings and changes in context on route toward delivery of a vision. Jeff Bezos, CEO of Amazon, once said, “We are stubborn on vision. We are flexible on details.’’
Jeff Bezos knows that the path toward success is not set in stone. New competitors emerge, constraints appear, and technology advances open new opportunities. A business may need to change its proposition in response to customer demand or to respond to a new entrant into the marketplace. As Arie de Geus, a Dutch business theorist, commenting on an ever-changing business context puts it, “The ability to learn faster than competitors may be the only sustainable competitive advantage.” We can only achieve this by accepting that change is the norm and learning is key. We need to accept the reality of working in complex problem domains with an unpredictable future and respond to change as opposed to religiously following a plan based on assumptions that may no longer be true. We achieve this by reviewing and adjusting, not only at an operational level but at a tactical and strategic level as well.
Feedback on Execution
As shown in Figure 13, we have nested PDCA (Plan, Do, Check, Act) feedback loops that integrate the operational plans with the tactical and strategic objectives:
- The strategic objective loop: Once a quarter the feedback of the tactical initiatives is studied at a strategic level to judge how well they have contributed to the strategic objective and, based on the learnings, how best to act on further investments. At the start, a strategic objective will have a rough outline of how it should be achieved, but as we constantly gather new information along the way, this plan will adapt and evolve using the PDCA loop.
- The tactical initiative loop: The plan part of the strategic objective loop is a portfolio of countermeasures or tactical initiatives. The “do” part of the strategic objective loop is the start of the tactical initiative loop.
- The operational action loop: The plan part of the tactical initiative loop is composed of programs, projects, or continuous product investments. The “do” part of the tactical initiative is the start of the operational execution loop.
FeedBack On Strategic Direction
A strategy is not something you should do once every three years; it should evolve as and when the context changes. Internal feedback and insight from actions you take along with external impacts to changes in the business environment should trigger a review of the strategic choices, enabling the business to adapt to the analysis of new information. We must be willing to challenge and test our strategic assumptions if the context that they were based upon was to change. We would expect the high-level strategy to change and respond to major impacts to the environment that it was based on. Forecasting over years is hard; however, it is good to have a vision and an overall direction, but we must iteratively progress and adapt on the way, including how to continuously monitor the environment your organization operates in as well as the feedback from your actions.
If the execution of strategy via strategic objectives, tactical initiatives, and operational execution loops are about working in the business, then we need another feedback loop to work on the business. The regular planning cadence also needs to consider the changes to the environment it operates within. The business goals an organization sets and the strategies to achieve those goals are heavily dependent on the context at the time the strategy is created. However, during the rhythm of planning cycles, we must observe for any changes to the context. Changes to the context should be the catalyst to revisit and check the validity of our strategic choices of how to win and where to play as well as the IT strategic actions that will contribute to achieving them. This should not be an annual event but happen as and when required. At a minimum, they should be reviewed on a quarterly basis to assess whether the assumptions made at the strategy creation are still valid. Context can change based on either an internal or external event:
- Internal: React to new information via the feedback cycles discussed in the previous section.
- External: Competitors, geopolitical events, legislation, market changes, etc.
If the context that the strategy was designed in has radically changed, so must the strategy itself. It must adapt to the new reality. After all, vision is fixed and strategy is fluid. Being able to realign our strategy with the changing internal and/or external landscapes is vital to capitalizing on new opportunities and mitigating new challenges. To ascertain if our strategic choices are still relevant, we must constantly observe, orient, and decide and act, the four activities of the OODA (observe, orient, decide, act) loop.
The OODA loop, as shown in Figure 14, is a decision-making model that focuses on distilling the available, and often incomplete, contextual information, understanding how it impacts you, and rapidly deciding on how to react. It was created by John Boyd, a US Air Force colonel, and designed so that fighter pilots could adjust strategies quickly in combat situations. When applied to business or IT strategy, it can be used to react to events in your business environment faster than your competitors and thus take a strategic advantage.
Observe: We need to observe and be aware of the environment we are working within. We should constantly gather data on external and internal events to gain an understanding of a threat of opportunity.
- External: Are there new competitors; has a change in technology made a competitive capability now a commodity? Is there talk of new legislation or compliance needs? Have security issues been exposed? Is there a chance of an acquisition or merger? Are there changes in the market?
- Internal: What information have we gathered from initiatives under way? Has a team made a discovery that has made a hypothesis invalid? Has an experiment unearthed a new opportunity or revealed a new constraint? Has internal feedback resulted in a change of strategic goal?
Orient: When we have gathered data and observed the event, we can analyse and reflect on how it impacts us. Is our business model still valid? Are our strategies no longer correct? Have we under- or over-invested in an area? What is different in the context now compared to when we set the strategic direction? At this stage, we also refer to our strategic principles, doctrine, and measures to guide how we observe and react to new changes in the context and how we act on new decisions.
Decide: After we have digested how the observed event affects us, we can decide on the best course of action. What should we stop or continue to do? Do we need to create a new goal, or should we evolve an existing one? Should we increase investment? Should we switch from an agile team to off-the-shelf software? Should we change the tech stack?
Act: Once we have decided, we need to act on it in a manner that enables fast feedback. We need to validate our decisions as they may have been made with limited and incomplete data. If we are unsure, we need to get clarity before we fully invest and drop into the PDCA loop. We should carry out experiments, use AB tests or pilots to gain clarity, and study how effective our response to the event will be.
Integrated Feedback Loops
“When it is obvious that the goals cannot be reached, don’t adjust the goals, adjust the action steps.”
Confucius
The OODA and PDCA loops may appear to differ only by the terminology used, but as shown in Figure 15, they are applicable to different levels of organizational planning. The PDCA loop is useful to follow when we are trying to solve a problem; the OODA loop will help us identify the most worthwhile and strategic problems to solve. The organization’s strategy is concerned with setting intent and making explicit how and where an organization will win. Because of this, the factors that can influence the strategic out- look are chiefly, but not exclusively, external in nature. Strategic choices and intent are reevaluated based on a change to the environment that an organization operates within.
The OODA loop allows us to react to changes in the context, understand how they impact us, and decide, usually on insufficient data, how to act. This loop may result in just trying things to sense how we can deal with market changes, new opportunities, or challenges. However, as our experience of the new reality increases, we can move to the PDCA loop to help the organization execute a strategic objective, a tactical initiative, or an operational project.
The PDCA loop is applicable when the organization has more clarity and a strong hypothesis on a way forward to respond to changes in context, whereas events that question the strategic direction are managed by the OODA loop. The flow between the two loops is not one way. Feedback from operational execution can rise and influence the strategic outlook just as an external event can. The catchball method of Hoshin Kanri is about the flow of information and data between the strategic and tactical layers of an organization so that there is a synergy between strategic thinking and operational execution.
In Summary
Creating a strategy is more of an art than a science. As well as plans being adaptable, we also need to ensure our strategy is kept relevant by allowing it to adapt based on external and internal feedback. From an IT perspective, our strategic actions can be impacted by external factors, more obviously by the advances in technology. This is why it is important for IT leaders to keep an eye on how technology evolves as it may change what we do, or at the least how we do it. Both internal and external contextual information will evolve the strategic outlook and challenge assumptions and bias. We looked at employing the OODA loop to check overall strategy against changes in context and to adapt quickly and out manoeuvre competitors.
The act of defining a strategy and plan should not be considered a once and done activity. In the new reality, there is a need for a continuous evolving and adaptable process to allow strategy and our plans to emerge and guide us toward an organization’s vision. Our strategy and plans will over time evolve based on choices from feedback made by independent teams across the organization in addition to events in the environment we operate in that question the assumptions our strategy was based upon. The actual path you take to deliver business success will differ from what you had when you set off, but this is optimal, as it shows your organization is learning and adapting. Remember, the value is in the planning, not the plan. In the end agility at an organisational level is the balance between a stable vision and fluid iterations of work toward that vision. Or as Simon Wardley puts it, “Crossing the river by feeling the stones.”
What to read more?
This article was a summary of four chapters from my new book The Accidental CIO: A lean and agile playbook for IT leaders. If you want to read more please follow these links or look for it at your favourite book seller.
