#entarch #bizarch Following a Linked-In discussion on business architecture and capability modelling, I was slightly alarmed to see how many contributions to the discussion were based on an argument from authority: IBM says this, Michael Porter says this, Forrester/Gartner says this.
Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.
In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.
I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.
So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)
This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.
Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)
Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.
Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.
It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.
Richard,
ReplyDeleteI am with you about dependencies. Recently I used a primitive way to understand / illustrate them - see illustrations in http://improving-bpm-systems.blogspot.com/2011/09/writing-it-strategy.html
Also, I think that dependencies / relationships should be captured as executable models (something like processes which make "bigger" capabilities from "smaller" ones).
Thanks,
AS
Good post - I particularly liked the phrase "the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership" ... too many people go looking for a formulaic approach that will neither differentiate their firm nor solve the medium term problems coming down the pipe.
ReplyDeleteThere is a famous saying by Emile Auguste Chartier that "Nothing is more dangerous than an idea, when you have only one idea", it all starts from an idea to form an organization, the capability of leadership leads it to success.
ReplyDelete