Introduction
This paper discusses a new depiction of Business Architecture within Enterprise Architecture to bring clarity on how Business Architecture relates to other Architecture domains & to Business Planning.
Author: Richard Hillier (retired Enterprise Architect)
Enterprise Architecture Domains
The above diagram represents a variation on the normal depiction of architecture domains. It’s an attempt to reconcile the older pillars with the newer layers orientations. Crucial to this depiction are components which exist in both the vertical pillars and the horizontal Business Architecture layer as follows:
- Application Architecture: includes the Business Process component, to associate application components (logical & operational) with the business activity they support.
- Information Architecture: includes the Information Component from a business perspective separately from any logical or operational representation of that information by data (structured or unstructured).
- Infrastructure Architecture: contains the location component. This is to recognize that business infrastructure is linked to an organization / location either by physical installation or network access.
Business Architecture consists of these business components – shared with the other domains – and, in addition, more complex views which link the architecture with the business plans. For example, an architecture view for a business capability (as defined through capability-based planning) would show how the components support that capability.
The 3 vertical domains can be considered to constitute IT Architecture (for the enterprise). It’s important to note though that the IT architecture still includes the basic components of business architecture in its 3 pillars; without them it would not be an IT Architecture at all – as an IT Architect defines the relationship between IT systems & their business environment.
The distinction between the full scope of business architecture and the IT architecture scope is not fixed by any means. An EA which included some of the business architecture complex views in some form e.g. value streams as business scenarios might still be considered an IT architecture.
The total picture – Business Architecture layer and the 3 IT pillars – is Enterprise Architecture. Business Architecture might be practiced in a very extensive manner dominating the Enterprise Architecture but it’s still important to see EA as a holistic single architecture of the enterprise. A reason for this, in the modern world, is that complex business architecture views are often dependent on IT.
The Architecture & Planning Relationship
Enterprise Architecture is closely related with Strategic Business Planning:
The highest level of planning in the organization is Strategy. The Strategy defines what business activities the company will be engaged in and the use of resources. It might even be argued that it’s not planning at all but “direction setting”. Next comes business unit planning in some shape or form (i.e. high-level plans for marketing, production etc). Together these form Strategic Planning and are the key driver for EA in two respects; 1) They define the business activity of the company (reflected in the EA business architecture) 2) They include decisions on the use of resources for integration of that business activity (by Information Exchange using IT).
When developing the EA, a number of critical decisions have to be made
1) Decide how to describe the business plans in a consistent manner and so that it’s understood by the stakeholders (the owners of those plans). A challenge in this respect is that the different business units may have varying perspectives and terminology in use. Some may adhere to Capability Based Planning and some may not.
2) Decide what entities within the EA come under “architectural control” and which are merely used to describe the architecture to stakeholders. The three components shared between Business Architecture and the IT Architecture pillars in this depiction can be seen as the minimum which would come under architectural control.
“Architectural Control”
The concept of “architectural control” is critical to this depiction in that the business architecture components which are shared with the IT pillars (“process”, “information” & “location”) would be the minimal business architecture entities which are under “architectural control”. Other entities e.g. capability would be part of the architectural views but not under such control. What this mean is that business plans can be developed which dynamically introduce new capabilities and variations on existing capabilities as long as they execute known processes, producing the required information & in recognized locations. Architecture views may still be drawn up to support these business plans but there would be no formal architecture change. On the other hand, if plans are created which require new process, information or location components then there’d need to be a full architecture revision and ARB (Architecture Review Board) agreement.
Conclusion
This paper is an attempt to carry forward the discussion on the definitions of Business Architecture recognizing that it’s an evolving field. Comments to the author are very welcome.
