The first time published on OCTOBER 6, 2021
Some people cross a traffic flow looking to the closer lane first and only then – to the distant lane. Other people do exactly opposite. When one looks at the closer lane, s/he risks stacking in the traffic ‘cause the distant lane might be occupied by cars and the person cannot cross the traffic flow. When one looks at the distant lane first, s/he waits when the destination becomes reachable and then only the closer lane managed to be crossed without the risk of getting in the middle of the traffic.
Practical wisdom.
One of the major tasks in the Practice of the Architecture of Business (AoB) is an understanding of the corporate strategy by decomposing the strategic goals and objectives into fine-grained sub-tasks. The Cause Pyramid decomposition method was developed about 2011, extensively tested and published in 2013. Using this method, every strategic goal specified by the Board and corporate CxO executives, has to be presented by a group of coarse-grained sub-tasks. Then, each coarse-grained sub-task (the first sub-level) has to be split further in the finer-grained sub-tasks (the second sub-level), and so forth (see Figure 1). In the end, we receive a structure of layered tasks where each upper layer represents the cause for the existence of the sub-tasks in the lower layer.
Altogether, this structure forms a collection of interdependent tasks, which when resolved, will deliver the solutions for the strategic goals and objectives. In other words, this structure defines what the company should have done in order to reach its strategic goal.
In every step of the Cause Pyramid construction, a developer keeps the target state or goal of the work in focus and uses all available means to brainstorm what the sub-tasks are needed to be solved at a certain level of granularity to address the upper task. Some sub-tasks may be repeated and appear in different layers depending on the needs of the upper layer task.
About the same time, Simon Wardley independently developed his method named Wardley’s Value Chain Mapping (WVCM). A reader familiar with this method might find a mirroring similarity between the diagram motivations for both methods but quite difference in the start-point, reliability and subjective/objective perspectives. Here are a few examples supporting our statement (the quotes are referred to the Wardley’s publication). The WVCM recommends, “to first focus on the user need” meaning the needs of an external user while in AoB we focus on the corporate strategy first, i.e. internal needs. The WVCM depicts the needs “by mixing the components” of different nature and call them Values while the used components may have no values on their own without a context or may have different values unrelated to the target need. Because of this, we understand the Wardley’s Values as potential values that might satisfy the needs if the components are realised. In parallel to this, in the Cause Pyramid, we use a term “task” or “sub-task” instead of ‘component’, leaving some creativity of how to realise these tasks to the ‘delivery’ people. Our “sub-tasks” address what should be done/gained/achieved/delivered in order to satisfy the task/sub-task in the upper level. Also, a method of Cause Pyramid enforces the rule that the lower level has to identify all sub-tasks (to the best of our abilities) required for realising of the task in the upper level. We have not noticed such rule in the WVCM.
Looking at the WVCM, we cannot explain why certain components are elaborated to a particular level of needs while other components are presented with more or with less detailed needs when all of them are on the same panel. Obviously, that Wardley’s mapping and the Cause Pyramid aim different goals, and expecting them to be the same is not right. The significant difference between these two tools is in the notion of mapping.
The Cause Pyramid starts with the strategic decision, which by itself provides a value during the decomposition in the sub-tasks. We have understood the WVCM as a journey from a current state of needs to the future state. Unfortunately, here is an additional severe issue – one doesn’t know what the future state of the need may be, especially when the pace of changes outside becomes comparable or higher than the pace of change adoption inside. Put it differently, in the dynamic market described above there may be no enough time for each component to path through Genesis, Custom Built, Product to its Commodity; plus, different components can evolve at different speed. Thus, a simple diagramming can result in a complex statistical analysis…
According to the provided WVCM examples (Figures 3 and 4), the designer assumes that the external customers will have the same needs in the future as they have now and only supplemental components will evolve. Well, it is a working assumption, but its validity still requires a serious justification. In the today real market, we can map only some/several components (values?) to all WVCM evolution phases because the one won’t know how all components will or will need to be changed in the “future”. To say more accurately, an ability of reliably predicting the evolution of the components depends not only on the market (execution context), but on the market/context dynamics, and this is totally different game. If this dynamic is omitted, the future component structure has a high risk of becoming inconsistent and disintegrated.
In contrast, our assumption is about the high pace of market changes; we do not try to predict the needs of uncontrolled external customers. Instead, we engage a mechanism of architecture of business that influences the CxO Executives and the Board in defining such a strategy goals and objectives that count in market trends and likely changes. The work of decomposing corporate goals into tasks (or components in the WVCM terms) includes continuous reviews and validity checks of the impact of market dynamics.
This is one of the reasons why Architects of Business are not the same people as Operating Managers – these two should address different concerns and have to have different skills. The Cause Pyramid for the TV Company example of WVCM is shown in Figure 1; the blue elements are those that are mentioned in the original example and the yellow elements are added based on the Cause Pyramid analysis. The comment about an unreliable source is made due to market dynamics – a category of single Brand programme has a high risk of disappearing from the market by the moment when the corporate strategy should be realised.
Figure 1.
At the same time, we agree that categorisation of component changes from genesis to commodity is a rich and fruitful idea. For some components of the initial structure, the mapping is capable to outline potential gaps and concerns if we can be confident in their future state used for the mapping.
In Architecture of Business, the purpose and the major task of architectural practice, which uses the Cause Pyramid method, is in defining the requirements to the Target Operating Model (TOM) for the given corporate strategy. This is a top-down work, which needs to be built, modified, acquired and constructed when considering market dynamics at each step. Instead of predicting the future state, we continuously monitor the market and adjust business capabilities that are supposed to realise identified tasks/sub-tasks. Also, we include a mechanism that helps us to either amend TOM on the fly or escalate appropriate modifications into the architectural design for TOM.
The AoB Practice treats every sub-task in the Cause Pyramid as a business capability or as a composition of business capabilities. The similarity between the sub-tasks with the WVCM’s components allows us to use the component structure for the illustration of business capabilities for different fragments of the Cause Pyramid. The same can be applied to the business services representing business capabilities in the AoB (and in the OASIS SOA RAF standard). Moreover, the WVCM may be used in AoB Practice when preparing materials for the corporate strategy or when validating impacts of the environment changes on certain business capabilities.
We highly recommend an adoption of the WVCM in conjunction with the Cause Pyramid method for designing of capability resources that have more or less predictable target states for the period of time covered by the corporate strategy. This method can be also useful for the illustration of transition from one capability-based blueprint to another in the Capability Deployment Plan. The criteria for applying the WVCM’s mapping is the subject of confidence in the to-be state of the components. To increase the confidence, it is also recommended to use WVCM in combination with “What if?” simulation for competing trends in the economic environment.
HOW to ARCHITECT for DEVELOPERS 