Understanding EBA - Part 1

Discussion for EA874 Topic 6 > Emerging Business Architecture
Post # 1

Enterprise Architecture if it wants to live up to its primary purpose of aligning business strategy with IT directions, would need to be cognizant of both areas of business and IT - not only clear on what IT thinks and want to do, but also clear on what big things business wants to achieve and how to get there.

There has been an on-going debate on whether the domain of Business Architecture is really part of EA's business, and I would think that based on our class directions and discussions, we think that it should, i.e. there should be a significant part of the EA discipline whose primary focus is clarifying the business side for the other technology domains to understand and connect.

As far back as 2010, there were EA circles who believe that Business Architecture is something different from enterprise architecture. Gartner's Philip Allega has described this to be a blatant attempt to classify EA as something only applicable to IT,  and argued that, in fact, EA is applicable to the the whole enterprise that covers numerous viewpoints for stakeholders, including business, information, technology and solution architecture. I would think that indeed, this is an early old school perception of enterprise architecture, during those times that the EA discpline tries to reach out to make the business connection coming from the IT camp. Today, we know that to effectively align IT strategies clearly with the business mission, EA must have a strong holistic view from both business and technology sides if it wants to present a meaningful and integrated enterprise architecture that can truly bring value to the organization.

To pursue EBA clarification, Allega first reviews and sums up Business Context, arguing that context is composed as follows:

1. A vision of the future state.  Gartner calls 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.


The earlier Gartner article of Burke, Allega, and Lapkin (2009) offers a key diagram to show that it is the business context that feeds the EBA viewpoint, and not the other way around.

EBA artifacts is said to describe the aspects of the business ("how we do business") and describe how these aspects must change or evolve to reach the overall EA future state. Gartner defines EBA as: That part of the enterprise architecture process that describes — through a set of requirements, principles and models — the future state, current state and guidance necessary to flexibly evolve and optimize business dimensions (people, process, financial resources and organization) to achieve effective enterprise change.

Thus "business context" is focused on articulating the business strategy; environmental trends (including internal, external and macrotechnology trends); and requirements to ensure an effective strategic alignment with business and a focused direction of effort. On the other hand, Enterprise business architecture (EBA) is focused on producing the business dimension in order to "architect the business."

"Architecting the business" is that significant amount of work supported and addressed by the EBA discipline,  the impact of which benefits the organization by having the clear understanding of the ripple effect of these business dimensions with regard to the rest of the enterprise architecture. As such, this makes Enterprise Business Architecture that particular discipline that provides the road maps needed to effectively manage business transformation, turmoil and evolution.

Summary:

I think most of the confusion comes from the boundaries that the current literature place on business context and business architecture. While most of the Gartner discussions advise the separation of business context and business architecture as shown above,  I think it comes intuitively that these two areas of work are really closely related, and it is not surprising that they are usually thought of one and the same, or at least tightly inter-related areas of concern that feed each other to make it seem like it is one and the same contiguous set of concerns -- for all practical intents and purposes.

Does it really damage our EA schema if we combine these areas?  I don't think so, as long as we know that there are business context deliverables and there are EBA deliverables, we can just really make sure to take care of these two critical areas, and label them as part of the Business Architecture discipline. No harm done. At least I don't really see any, and simply shifting the label actually removes a lot of confusion.

/

References:

Philip Allega. (2010 August 30). Business Architecture is Part of Enterprise Architecture. Retrieved from http://blogs.gartner.com/philip-allega/2010/08/30/business-architecture-is-part-of-enterprise-architecture/

Betsy Burton, Philip Allega, Anne Lapkin. (2009 November 13).'Business Context' and 'Business Architecture'Are Not the Same. Research paper. Gartner. ID G00170922.
/