13 years, 8 months ago

Business Architecture is Part of Enterprise Architecture

Link: http://blogs.gartner.com/philip-allega/2010/08/30/business-architecture-is-part-of-enterprise-architecture/

A common misperception being hyped in EA circles concerns the notion that business architecture is something different from enterprise architecture. This is a blatant attempt to classify EA as something only applicable to IT when, in fact, EA is applicable to the ENTERPRISE that covers numerous viewpoints for stakeholders, including business, information, technology and solution architecture.

Where does this confusion come from?  To be blunt, the number of practitioners who have only used EA for IT, focusing upon the technology viewpoint of EA, have left a few large gaps in their approach to developing their EA viewpoint.  These gaps include:

  1. Developing a business contextthat guides the advice and deliverables within the technology architecture viewpoint, and all other viewpoints.
  2. Consuming the resulting advice within, minimally, the IT  investment decision-making process.
  3. Creating a governance and assurance mechanism that communicates the change that has occurred, or not occurred, in light of EA advice.

A common mistake we see is when well-meaning EA programs conflate the business architecture viewpoint of EA with the business context of EA.  The business context of EA is formed of:

  1. A vision of the future state.  At Gartner, we call this the Common Requirements Vision.  This deliverable is typically 10-12 pages and explicitly connects environmental trends, business strategies and requirements of business process and IT together in priority matrices.  This is a conceptual level document that requires confirmation of the target state, and its associated priorities, by the top of the governance decision-makers – typically, the people who decide how to allocate resources in the organization.
  2. A root, anchor model. The highest visualization of the enterprise, recognizable to the business, may be in the form of a business operating model, a hyper-extended view of the business ecosystem, business capability maps, a federated model or some combination of these for particular stakeholders.  All business processes, information, applications, solutions, technologies, people skills, people, other entities, are overlaid upon and disaggregated from this root, anchor, model.
  3. A set of guiding principles. These shape the investment and action behaviors of all those who seek to select, create, and implement anything within any EA viewpoint.

Unfortunately, some have conflated this business-context package with the work done in the business architecture viewpoint of EA.  These folks have mistakenly lured other EA practitioners into believing one or more of these myths:

  • I can continue to do technology architecture without having a business context
  • Business architecture is something completely separate from enterprise architecture.
  • EA is for IT only.

Mature practitioners lead EA programs that encompass all viewpoints of EA, informed by a business-context package.  They may focus more heavily upon one viewpoint or another, but they always link the interdependencies and interrelationships of these viewpoints in light of the business context over temporal states (past, current, near-transitional, future, optional future, retired future and more).

These leaders do not wait for the existence of a business architecture viewpoint to engage their EA advice in investment decision-making or wait to introduce assurance and governance into their EA processes.  Some pundits seem to believe that it’s only when business architecture is engaged that assurance and governance is possible.  This is, simply put, not true.

When I first ran across EA programs engaging in business architecture in the late 1990′s it was very early days.  10+ years later and we have more mature programs that understand and embrace this viewpoint of EA, but we also have, sadly, current practitioners who are not familiar with business architecture’s proper place in relation to an overall EA effort.

I am certain that this attempt to set the record straight will be controversial.  I hope that it encourages a dialogue of discovery and helps correct a hype filled market incorrectly placing business architecture outside EA.