The Enterprise Business Architecture, Part 1
Image Source: Aviana Technologies
In previous classes as well as the beginning of this class, we discussed how Enterprise Architecture (EA) is traditionally thought of as having 4 distinct viewpoints:
- Business Architecture Layer
- Data Architecture Layer
- Application Architecture Layer
- Technology Architecture Layer.
In recent years, the importance of security has become a much higher priority and many organizations now treat the Security Architecture as a fifth distinct viewpoint within the EA. However it is important to note that there is a distinct flow to the parts, as noted by the wording in the above graphic. From the top down, the layers define the scope and boundaries of the layer below them. From the bottom up, each layer supports the architecture of the layer above it.
This week, we are talking about the Enterprise Business Architecture (EBA), the keystone of our EA “pyramid” diagram. And as the diagram suggests, the business layer drives all the rest of the viewpoints of the Enterprise Architecture while those other viewpoints are ultimately supporting the business architecture.
Gartner defines the 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.
As with information, technology and solution architectures, the EBA process translates the strategy, requirements and vision as defined in the business context into contextual-, conceptual-, logical- and implementation-level requirements. Using this process, EBA, as well as all the EA viewpoints, should demonstrate clear traceability of architectural decisions to the elements of the business strategy.
Gartner continues in the article, discussing one of the main issues regarding this concept of Business Architect, in that it is often confused with Business Context. Business Context is defined in the article as the “process of articulating the business strategy and requirements and ensuring that the enterprise architecture effort is business-driven.” In other words, the business context defines directly how the EA is related to the business strategy and how they interact with each other. It gives us a perspective on how the business operates. Back in EA872, I wrote about how the “context provides the enterprise architects with the proper frame of reference in which to link together the EA Principles, Business Strategies and Business Initiatives.” The Business Context provides us with that frame of reference for all aspects of EA, including the Business Architecture.
So the Business Context provides the frame of reference, while the Business Architecture is the organization and structure of the business processes, organizational elements, business strategy and requirements, and business rules. Simply put, the Business Context defines the “Why” while the Business Architecture defines the “What” and “How”. This is true of each of the 4 other EA layers we have been reviewing in the past weeks. Each of those layers gives us a snapshot view into the “What” and “How” of their respective fields within the business. The Business Context not only provides the “Why” for each of the EA layers, but more importantly, it provides a method to understand how the 5 layers work together to fulfill the overall business strategy.
