Actionable suggestions that can help architects at least provide some rigor in mapping to the strategy level.
We’ve already seen how architecture modeling can potentially benefit from integration with a CMDB, and how a level of integration to the project planning system can reap benefits under the right circumstances. A third area of possible overlap that comes up on regular occasions is how the architecture can link in to the strategic aspect of the business.
There are two main types of strategic model that come up in these conversations. First of all is the strategy map, as popularized by Kaplan and Norton. A strategy map displays the strategic objectives of the organization, arranged into four layers derived from the standard four perspectives of the Balanced Scorecard – Financial; Customer; Internal; Learning and Growth.
Now where there can be value in mapping this to architecture initiatives is if the IT organization is able to articulate a set of IT goals that support the organization’s strategic objectives. If this can be done, then it becomes possible to map the IT goals to initiatives undertaken within IT and provide a clear traceability. Technically, IT could simply offer a direct mapping from organizational goals to projects, but articulating IT goals provides a level of causation that otherwise gets omitted – “this project supports this top-level goal because we say so”.
Historically this approach has struggled because of the need to search for and define some IT goals. However, this task has become significantly easier with the release of COBIT 5, which introduces a reference set of corporate goals (classified according to the BSC schema), mapped to IT goals (also classified according to BSC), mapped to IT processes. Following the advice of Steve Jobs (“good artists copy, great artists steal”), we can select from the COBIT 5 IT goals and then map to IT operations, giving us a mapping from strategy maps down to IT initiatives.
The one other common strategic model that regularly provokes questions on possible touchpoints to architecture modeling is the business model canvases.
First proposed by Alex Osterwalder in 2008, the business model canvas has grown to be the de facto standard for mapping out the business model(s) used by an organization. Osterwalder’s book comes highly recommended, but the limitation for our discussion is that it does not offer any suggestions about how the business models map to architecture (nor did it intend to).
When confronted with this question, how to map the business model canvas to an architecture model, I borrow heavily from a post by Tom Graves. It’s a classic post from Tom, as while it gets somewhat involved and also branches off into a campaign against IT in EA, it also offers some deep insights. Tom’s major insight is that the key resources and key activities act as interfaces to the key partners in the model. At the same time, the customer relationships and channels serve as interfaces to the customer segments.
So, the key activities and key resources, and customer relationships and channels that are defined on the business model canvas can be mapped to business services and business interfaces.
So, to summarize: when asked to show an integration or mapping to strategy maps, the goals cascade idea from COBIT 5 offers a justifiable way to do this (corporate goal->IT goal->IT initiative).
In contrast, when business model canvases are used, we can use the mappings between entities that they provide to help identify business interfaces and business services. One caveat here needs to be that an organization might have more than one business model, and so it’s necessary to question if this is case to ensure that mapping is performed for all relevant business models, and not just one.
When we start trying to perform mappings like this, it makes it clear that the state of the art of EA meta-models could use some work. However, in this post I’ve attempted to offer some actionable suggestions that can help architects at least provide some rigor in mapping to the strategy level.