Business Architecture Anti-Pattern: The Nature of the Inventory Viewpoint

Friday, December 24, 2010 |

The Portfolio Viewpoint is a collection of well-defined capabilities and their relationships across a set of domains. The Portfolio Viewpoint supports executive level discussions and business strategy because it traces stakeholder (CEO, CIO, COO, CISO) vision to decision grade information for IT investment.

But the Portfolio View usually doesn’t start out that way.

It frequently begins life as an Inventory Viewpoint that has little value outside of Enterprise Architecture or Business Architecture teams. Some attributes of the Inventory Viewpoint are as follows:


As you can see the level of order is much higher and therefore of greater value in the Portfolio Viewpoint and while there are probably other attributes one can add to the mix the table above identifies some important ones.

The danger with the Inventory Viewpoint is that if it is maintained in the same condition long term then it becomes an anti-pattern. Collecting capabilities without understanding the depth of their connections and the wealth of their meaning will end up as shelf-ware in a repository, however sophisticated that repository may feel.

So resist the temptation to hoard capabilities. Don’t be afraid to talk to the business. And, above all, pay attention to what your stakeholders and their deputies tell you, particularly the office of the CEO, CIO, COO, and CISO.

Business Architecture without Capabilities?

Tuesday, December 7, 2010 |

There's been a tremendous uptick of chatter about capabilities.  At SenseAgility, we've been on the Capability Based track all along, so it's been fascinating to see how the market has evolved in a relatively short period of time.  When I presented at Open Group Boston in July, I removed several background slides on Capabilities waiting for my speaking time slot.  I usually spend at least 5-6 slides setting the context on this topic before getting to main points of my presentations.  Fortunately, the first two speakers laid that educational groundwork for me, so my presentation became much more concise.

Concurrently, there's been a tremendous uptick of interest in Business Architecture.  I don't believe these two developments of increased interest are orthogonal.  If you look back just a year ago when we first published our Vanilla Enterprise Architecture Capability Map, neither one of these terms were common.  Forrester had just came out in support of capabilities as a communication vehicle between business and IT.  Business Architecture had just been tossed around by Gartner, Forrester, and a few independent analysts.  

Given the relative immaturity of this space - we didn't even know what to call ourselves a mere 18 months ago - confusion is the order of the day.  Business Architecture, as I mentioned in the Open Group Boston presentation, is being defined in various ways to suit what various interests are selling.  Fortunately, those of us in management have developed a good "BS Filter" considering how much of it we have to wade through to make a decision.  Capabilities are also being defined in various ways, but the trouble with these ways is that every single definition is correct.  That is due to the fact, as Doug explained last year, that capabilities can be applied in every level of granularity.  Hence, they're not the easiest creatures to understand.

So the question that I'd like to toss out is whether effective Business Architecture practice can be conducted without capabilities?  Being so close to the fray, I'm not sure I have the objective context to answer this question myself!

AAB