In this paper, in which the second part of the Plan to Capability Model is discussed I will explain how capabilities can be derived from strategic plans by using a model that was developed over the years and which now uses Archimate 3.0 for this translation. In other papers the complete model will be used to not only define capabilities, but also business functions, processes, services, resources, principles, etc. necessary to develop a successful capability model.
In the first part I explained how the Plan-to-Capability model evaluated from the Goals-Means model based in the Business Motivation Model into the final Plan-to-Capability model to translate business, IT and architecture goals into necessary Outcomes of Capability actions. I pointed at the possibility to develop Capabilities in more detail, and addressed how Principles, Constraints, Requirements and ISO 25010 quality aspects can lead to optimization of the Outcomes.
In this second part I will explain how strategic plans can be translated into the above components, delivering several different Capabilities that sometimes service the same Business, IT or architecture goals, and how Generic IT Resources like ESB, Data warehouses or Data Factories, Dossier and Archiving tools, etc. can service the Capabilities.
So, how can we use Goals-Means modeling and the Plan-to-Capability model to analyze the plan and define the necessary capabilities? Normally, this is a phased approach in which we first use Goals-Means modeling to get the wider picture and then the Plan-to-Capability two-way approach: first top-down and then bottom-up. Top-down to be sure that all goals are met by necessary capabilities. In this way each Goal can result in several necessary Capabilities.
Next, the model is used bottom-up to integrate the Capability-Goal combinations per Capability, and the generic IT components, like ESB, DMS, CMS, Big Data and BI tools, etc., that serve Capabilities derived from the top-down approach. In this way, each Capability serves several Goals, but also uses different or the same generic IT components to help realizing the Goals. For example a component based proposition (Products, Business Services and business means) realizes agility and flexibility on the business side, like the service oriented architecture with its generic IT components fulfils these goals on the IT side.
A strategic plan is the result of an external and internal analysis and the way the organization wants to support their stakeholders in creating value with their proposition. The SWOT (Strengths, Weaknesses, Opportunities and Threats) is a combination and wrap-up of the analysis.
Other examples are techniques like the business model canvas, models like the operation model based on the chosen value discipline, (operational excellence, customer intimacy, and product leadership), etc. The strategic plan might also focus on (new) markets, business channels, customer profiles, price lines, propositions, necessary core competences, organizational culture, and resources (both financial, human, natural, machines, tools, etc).
Normally, not all strategic plans offer the results of above methods and techniques, especially not the mentioned components, in such a detail as to address all capabilities. But they should at least address the changes to what I call the essence of any organization, defining its ontology:
The essence of any organization is to create value for their stakeholders with their proposition. To execute this various core competencies are necessary.
So not profit, but value – not shareholders but all stakeholders. The proposition is the combination of products, services, value, competencies, etc. I will discuss this in a future paper.
As a strategic plan is seldom complete enough to define all necessary capabilities for all teams and all departments, it is necessary to use a general Capability framework or Map to fill in the gaps. The Capability Map consists of the generic Business Capabilities like Financial Management, Risk Management, Asset Management, etc., and specific capabilities like the Product Delivery Capabilities and the Business Support Capabilities that integrate all capabilities. For this, we used the following generic Capability Map.
The municipality I worked for had a master plan and derived a strategic IT plan, the so-called “Digitization Agenda”, from that. This was the innovation plan for new IT products and services based on the new opportunities IT enables like versatile apps for personal and other stakeholders, big data analysis for better service delivery and product, and service profiling, etc. The plan was a structured paper integrating the different ideas of the clusters (divisions) on how to use IT for their strategic goals. This agenda was used by the enterprise and business architects of the business support division to derive and define the necessary capabilities to deliver the agenda’s results.
From the point of view of architects, there was a wide variance of components used by each division that had helped to set up the plan. Because of this, the Plan-to-Capability model was an ideal model to be used: we have been able to use nearly every part of text as content of the different components. Some parts of the text were used to identify the Goals of the municipality or the sub-Goals of the division or even the IT departments. Other parts were used to define the necessary Outcomes and based on this, the necessary Capabilities, the Course of Action of each Capability, and at other times the necessary generic or specific IT resources. Based on keywords represented by components of the used Plan-to-Capability model we were able to analyze the texts, find more keywords for new components that better supported the plan, and define the target component or components and Capabilities.
In the strategic plan the top goals of the municipality were addressed in what might be called “scenarios”, or “long term metaphors”. We could derive the goals of the divisions based on these three top goals, interpret the text, and define the sub-goals. Often the names of the sub-goals were already delivered by the divisions. We then interpreted the text and gave each part of the text a place based on the available types of components and related each component to one or more Capabilities. Participants came up with more components when we found that in the model the then available components could not describe the contents of the texts.
As I also worked on the aspect architecture of generic IT resources, like ESB (Enterprise Service Bus), CMS (Content Management System), DMS (Document Management System), BPM/CM (Business Process Management/Case Management), etc. I could fill the model with these different IT-based components.
After processing the strategic document (top-down approach) and the generic IT solutions (bottom-up approach) it became possible to collect the different models per capability. One of the top performance indicators that should be the result of the goals, both from the top-down as well as the bottom-up approach seemed to be the necessity to raise the agility and flexibility of business and IT.
So, architects are able to use strategic plans to integrate architectural components and based on that
fill a large part of the contents of Enterprise and Business Architecture components. The complete Capability Map, the Motivational Aspect Architecture with Principles, Requirements, Quality Characteristics, Constraints, but also the Service Delivery per Capability, the necessary generic and specific IT components that support the Capabilities can be defined. Also, as we will see in later papers, the different Business components composing the Capability can be delivered. Based on that the Architectural multi-year plan could be set up and budgets for the realization can be derived with support of the business.
(c) Paul Christian van Wely/Emc2 Holding BV
 The Business Service Delivery model describes how external Actors (for example customers) based on their Roles or Life Events request via selected Channels the Business Products that will be delivered to the Actor via logical sets of activities integrated into a Business Service and based on Contracts, defined Value Creation, etc. The IT Service Delivery model works likewise. Both will be discussed in a later paper. From the architectural point of view this is the next step.
 In the model represented as application components etc.
 The strategic architecture model for propositions is another thing that will be addressed later. It is one of the most important things, and also foundational, for the enterprise architecture.