This is a response to a very thought-provoking discussion that's been going on at the Business Ecology Initiative LinkedIn Group on the topic of whether Business Architecture is synonymous with Business Ecology.  I suppose the answer depends on where one draws the scope boundary around Business Architecture.  Based on our observations from how this works in practice, it will probably be different in different organizations. For example, in our Vanilla Enterprise Architecture Capability Map, Business Architecture is a core business capability portfolio (or core function) of Enterprise Architecture, similar to how The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) positions the discipline.  Business Ecology, on the other hand, encompasses Enterprise Architecture, along with other Office of the CXO strategy and planning functions, such as Risk Management, Portfolio Management, Asset Management, et al.  It also includes the delivery and ongoing operational steady state functions of a given organization.

That's not to say that two are unrelated.  The challenge for every organization is to find the "right" level of investment in the various core functions to balance short-term profitability with long-term competitive advantage.  If one were to view each core function - whether strategy/planning, delivery, or operations - as a separate business unit, each of these core functions would have their own business architecture.  Consider two core functions that most organizations of scale have (sometimes in spades) - Risk Management and Portfolio Management:

• They each (RM and PM) have unique organizational attributes (e.g. culture, org structure, etc.), as one would expect of two organizations with completely different mission statements-especially around communication!
• They each have unique business attributes - the business of mitigating risk is quite different than that of getting leadership to agree on the priorities of various efforts;
• They each have unique technology needs and tools - although a seasoned Enterprise Architect may detect a certain amount of commonality between GRC and EPPM tools.

So in the example above, there are two core functions within the same organization, bound by the same organizational goals and objectives, empowered by the same leadership, with two competing missions, business operating models, organizational constraints, and technology.  And that's just within the Office of the CXO.  Once the analysis reaches the various business profit and loss centers, whose entire business operating models may be disparate, the natural result is complexity. 

As I presented at BEI last year, complexity is nothing to be afraid of - it's just complicated (podcast here).  Even in the simple example above, there is an optimal range of options that allow for the two competing core functions to work in harmony. Finding the range that works to align the given set of core functions is an obvious use case for business architects.  The more core functions there are to align, the more complicated it gets, since there are quite a few dependencies (and personalities) to align. 

Before I get too far down the rabbit hole, here's the gist:  the business of Business Architecture is creating and managing the "right" equilibrium and range for Business Ecology - the alignment of all of the disparate business operating models and their core functions within a given organization. Not to say that it can't be done without a formal Business Architecture function.  But the likelihood that it can be done consistently well diminishes as level of scale increases.

AAB

In a prior post, Doug was quite diplomatic in detailing why the Capability Inventory Viewpoint can become an anti-pattern. For those of you who've followed my insights over the years, I tend to be a bit more direct. I could dedicate a whole blog to psychoanalysis, but that's not why we're here. So in a typical direct fashion, here are some points that drive the Capability Inventory Viewpoint to become a Business Architecture Anti-Pattern:

Static - as Doug explained, the static nature can be bothersome. Let me take it further - just accumulating enough data to create an inventory viewpoint can be a major undertaking. In the project-based demands of many organizations, creation of this viewpoint can in itself be perceived as "success." Which means that project usually ends with little or no ongoing support for what is essentially a knowledge deliverable. That can (and usually does) lead to ...

Neglect - without the proper knowledge-worker staffing levels to continue updating the inventory, it can grow stale. Whether due to its static nature or lack of support, once created, there appears to be an inertia around the Capability Inventory Viewpoint.  This is mainly due to ...

Omission - when capturing capabilities with the Capability Inventory Viewpoint as an end-goal, certain information tends to be left out. What's worse, as I wrote in 2010 when looking at the EA product market, even products that appeared to be ahead of their competitors were not ready for our consumption, because the Capability Inventory Viewpoint is really the only viewpoint available. So there are few, if any, facilities (outside of heavy meta-model customization that is anathema to most enterprise-scale clients) to capture and maintain things like capability dependencies, classification, and other portfolio attributes. Without these portfolio attributes, it is a Sisyphean task to properly valuate a capability vis-a-vis its peers, and communicate that value to appropriate stakeholders. That, indubitably leads to ...

Wrangling - initiative prioritization without capability portfolio information is difficult at best. There is no shortage of opinions that can come from every corner of the organization. Without the capability portfolio attributes to constrain these discussions, it is more likely that initiatives that are selected, and their order of execution, will not yield optimal results.  Insufficient dependency identification has been a mainstay on every Top-10 project failure list since these lists emerged in mid-90's.

So if constraining the constant battle of opinions in your organization is of interest, my recommendation is to not allow yourself to be SNOW'd by the Capability Inventory Viewpoint!

AAB