Enterprise Architecture vs. Business Architecture
Understanding the Differences
When diving into the deep end of digital business transformation, it is not uncommon during the process to take a step back to look at the big picture and get a sense of how an organization is tracking against their overall goals.
Is this an Enterprise Architecture view or Business Architecture view? Good question.
While the terms Enterprise Architecture (EA) and Business Architecture (BA) are used interchangeably, in reality, BA is a component of EA and provides the foundation for the other domains within the EA.
Let’s start by what Enterprise Architecture and Business Architecture are not:
- Enterprise Architecture is not about just technology
As its name implies, it’s about the enterprise, i.e. organization as a whole, including the ecosystem in which it operates.
- Business Architecture is not just about process
While processes are a key component of a Business Architecture, it is not the only thing.
So next, let us look at what Enterprise Architecture and Business Architecture are.
Writing in a recent MIT Sloan Management Review article, Jeanne Ross and Cynthia Beath define Enterprise Architecture as:
… the holistic design of people, processes, and technology to execute digitally inspired strategic goals.
While this definition is framed around a digital point of view, it is also relevant for all types of Organization. The primary goal of Enterprise Architecture is to provide a roadmap for organizational redesign and change.
On the other hand, Business Architecture is best thought of as a blueprint providing a structured, model-driven approach to building and managing an organization. Business Architecture provides an understanding of how the organization’s business strategy and its value streams translate into operation, including the organization structure, processes and supporting information.
Business Architecture doesn’t just define the outcome, Business Architecture helps to realize the outcomes.
It provides an enterprise-wide understanding of the ways in which business strategy and value streams are translated into operation, integrating organization, process and information elements. Business Architecture does not define the strategy, it enables the realization of the strategic objectives.
Operationalizing Business Strategy: Understanding Business Architecture’s contribution
Enterprise Architecture frameworks are typically divided into 4 primary components, sometimes called domains:
- Business
- Information
- Applications
- Technology
Some Enterprise Architecture frameworks, such as The Open Group’s Architecture Framework (TOGAF), merge the information and Application components. The components are usually represented in layers:
Architecture Principles and Vision: another view
There are also often other components that provide the architecture principles and vision, as well as the implementation considerations of the architecture. For example, TOGAF has two such additional components:
- Architecture Principles, Vision and Requirements; and
- Architect Realization.
The Business Architecture provides the anchor point for the remainder of the architecture, as it defines the organization’s vision, strategies, structure and what it does. OMG’s Business Motivation Model shows a simple and direct link between the Motivation and other aspects of the Business Architecture:
The Business Architecture defined in who the organization currently (or are planning to) deliver or realize “what it does”.
Aligning Business Architecture to the rest of the Enterprise Architecture
The Information and Application Architectures are aligned to the organization’s motivational, organizational, and behavioral elements of the Business Architecture to ensure that the information used while conducting its business processes, together with the applications that are deployed to support the business processes are in line with the business objectives and strategies. The organization’s objectives and strategies will influence what applications and underlying information are needed to realize its objectives and strategies.
Further, the Technology Architecture defines what technology platforms and components are needed to support the running of the applications contained within the Application Architecture. The Technology Architecture will also be aligned to and influenced by the organization’s objectives and strategies to ensure these are realized.
We see Business Architecture defined as the sum of its components and how they operate, specifically focusing on the interrelationships and integration of strategies, people and processes, together with information.
It is critical for organizations to analyze and consider:
- Their role in an ever-changing marketplace
- The impact on customers of the changes occurring in their own marketplace
- The right time and financing for decisions on changes to services, products, suppliers and partners, technology, the organization and core business processes.
One of the key driving forces within the Business Architecture is in its set of strategic support and core processes that go beyond organizational boundaries. For Business Architecture to be effective, it must enable proper planning for integration of process not only within the organizations, but also with partners, suppliers and customers.
In taking an end-to-end view of business processes, it exposes the importance of how we view and understand the support of the business value chain and underlying processes by the organization’s applications and technology. Using an end-to-end approach not only breaks down functional silos, but also application and technology silos created by functional thinking. The key here is that while we each may belong to a particular functional group within the organization (such as Finance, Sales, Customer Service or IT), our business processes and supporting applications should not be constrained by any organizational structures.
The Introduction of Process Architecture
One of the important roles of a Process Architecture is to not only document how the organization will operate, but to also provide guidance in defining what information is to be supported by each of the applications within the Application Architecture. In some circumstances, the applications may be reliant of the integration components and methods defined in the Technology Architecture. The integration components will allow applications to speak with each other via their API’, Enterprise Service Bus or other middleware, in support the business processes.
BPMS as a mechanism
An increasingly common mechanism of achieving this integration between business processes and applications is the use of a Business Process Management Suite (or BPMS), such as Interfacing’s EPC.
A BPMS provides a process driven mechanism to facilitate communication between business processes and applications, without being constrained by the workflows mandated within applications.
Where once a BPMS was only applicable in large corporate businesses with significant technology expertise, the current generation of BPMS products, such as EPC, democratizes the use of a BPMS to even small organizations. They are designed to improve or automate business processes, allowing processes to be design, documented and implemented within the BPMS in order to increase operational efficiencies. It is often even possible to build custom process-based solutions using low code in some BPMS products, such as the Rapid Application Development add-on available for Interfacing’s EPC.
A BPMS is also an appropriate way to bring Services Architecture into play, which is another component of Technology Architecture. By using Process Architecture to determine services that are commonly used for multiple business processes, a “service-oriented approach” begins to take shape in the Services Architecture. If the BPMS has been setup properly, it can then monitor the effectiveness of business processes (and efficiencies as well) and in turn leverage those services to support further process improvements.
Benefits of aligning Business Architecture to Enterprise Architecture
- Business Architecture brings forth a business centric and robust focus within the Enterprise Architecture as a whole.
- All aspects planning, and strategic analysis are integrated through the “lens” of Business Architecture.
- It will provide a comprehensive cost/benefit and perspective analysis from both technology and business operations.
- Alignment of multiple cross-disciplines across the organizations leading to optimizing value while maximizing investments.
Let’s use a case study to help illustrate how business objectives and strategies influence and shape the Information, Application, and Technology Architectures.
Case Study
Background
ElectCo (not a real company) is an electronics retailer that started out a single store and now has 10 stores located across a regional area covering many small towns and cities. The company until recently run by its founders. Its operations, including purchasing and stock management are mainly based on Excel spreadsheets and the company’s website is information only. Although it is still a family-owned company, management has now been passed to the second generation. The new management team are all university educated with business, marketing and technology qualifications. They recognize that the current strategies limit the company’s growth and make it susceptible to local environment factors and economic downturns.
New Clicks and Bricks Strategy
At the last stock-take, the new management team discovered considerable stock was being held that were no longer current models. Analysis of this excess stock found that often because of:
- Over ordering of items that didn’t sell as well as expected
- Stores could place their own orders without knowing if another store had stock of an item
- Customer could order items and then cancel the order before taking delivery without making any payment.
The new management team have decided to make a number of key changes to the business, applications and technology:
- Changes to business policies, such as centralizing inventory management, including minimizing stock on hand and just-in-time stock ordering based on minimal stock, customer orders can only made with 25% deposit, cancelled orders will be charged a cancellation fee
- Replacing their existing operational processes and existing applications to manage not only the accounting, purchasing and inventory management applications, but also a move to an e-commerce-based website allowing customers to order online for either pick-up or delivery.
To help them complete the implementation of this new strategy, they have engaged two former university friends with experience in Enterprise Architecture and Business Architecture.
Impact of New Clicks and Bricks Strategy
The first step for the Business and Enterprise Architects is to work together in accurately documenting motivation component of the target business architecture. This starts by defining the new business goals, objectives, strategies and tactics. Defining and analyzing the external and internal drivers and influences and completing an assessment of these new objectives and strategies against the existing business goals, objectives, strategies and tactics.
Once this is completed, the Business Architect can begin created the organizational and business process components of the Business Architecture. At the same time, the Enterprise Architect can begin assessing the impact of the new business goals, objectives, strategies and tactics against the existing information, applications and technologies. As there is unlikely to be Enterprise or Business Architecture artifacts available, this will require development of the current state artifacts before developing the target state artifacts.
Clearly, the proposed changes in business goals, objects, strategies and tactics requires major changes to existing business policies, business rules and business processes, they must be a priority for the Business Architect.
As the Business Architecture enables the realization of the business strategy, the Enterprise Architect requires it as the basis for determining the changes required in the Application and Technology. Once these changes are defined and their impact on the existing portfolio of applications and technologies is understood, you can then begin to define the target state Application and Technology Architectures and the requirements and details of the change programs required.
Final Thoughts
In reviewing the above information, it is apparently clear that the distinction of Business Architecture’s involvement with Enterprise Architecture is not one of combat but more of an excellent yet complex working relationship where Business Architecture supports the bigger picture of the Enterprise Architecture.
To give strong value to any organization, Enterprise Architects will spend a large amount of time on the Business Architecture foundational domain. To succeed, the organization needs to focus resources in the build and communication of Business Architecture roadmaps that involve not just the enterprise or business architect teams, but the business stakeholders and senior executives as well.
This post does a fantastic job in distinguishing the roles of Enterprise Architecture (EA) and Business Architecture (BA) and their interconnectedness in an organization. The detailed analysis and the case study nicely illustrate how both architectures work together to achieve the business objectives.
One point that really resonates with me is the emphasis on BA’s role as a facilitator in the realization of business strategy. It’s noteworthy how BA aligns organizational goals with processes and enables strategic objectives by providing the structure for operation.
I appreciate the emphasis on the alignment of Information, Application, and Technology architectures to the business objectives and strategies. This integrated view is pivotal in ensuring that an organization remains agile and can respond effectively to changing business conditions.
Lastly, your point on the introduction of Process Architecture and the use of a Business Process Management Suite (BPMS) like Interfacing’s EPC is insightful. It reinforces the idea that an end-to-end approach in managing business processes not only helps in breaking down functional silos but also allows for an improvement in operational efficiencies.
Overall, this post underscores the need for both EA and BA to work in tandem to ensure an organization’s success in the digital age. A good read for anyone interested in understanding the complex dynamics of enterprise and business architectures.
Thank you, you for thoughtful feedback!
I think that technology departments have had to deal for years with the language difference between them (technical) and the business side. Paradigm to always being made to look like the bad guys when something doesn’t work. Enterprise architecture is now seen as a holistic component within Enterprise, and Business Architecture is studied within the subject is a response to all of the above.
I don’t think they both are used or should be used interchangeably because they are not the same and as you mention in the post, BA is more than processes and EA is more than technology infrastructure. I think BA is the foundation and provides a broad understanding of the business and EA is how I execute the strategy leveraged on the technology tools.
Hello Sukesh,
Diving into digital business transformation is indeed an exciting journey, but it’s crucial to take a step back occasionally and assess how an organization is progressing toward its overall goals. Your question about whether this view belongs to Enterprise Architecture or Business Architecture is intriguing and highlights the subtle yet essential distinctions between the two.
While the terms EA and BA are often used interchangeably, Id classify BA as a subset of EA and serves as its foundational element, supporting the other domains within EA. It’s important to clarify that EA isn’t solely about technology; it encompasses the entire enterprise, including the broader ecosystem in which it operates. Similarly, BA is more than just process-oriented; though processes are a critical component, there’s much more to it.
EA is the holistic design of people, processes, and technology to execute digitally-inspired strategic goals. While this definition emphasizes the digital perspective, it applies to all types of organizations. The primary objective of EA is to provide a roadmap for organizational redesign and change.
On the other hand, BA can be likened to a blueprint, offering a structured, model-driven approach to build and manage an organization. It provides an understanding of how the organization’s business strategy and value streams translate into operations, including the organization’s structure, processes, and supporting information. Unlike defining the strategy, BA enables the realization of strategic objectives by facilitating the enterprise-wide alignment of business strategy and value streams with operations.
To operationalize business strategy effectively, Business Architecture plays a crucial role in bridging the gap between strategic vision and execution. It should integrate organization, processes, and information elements, which will provide the holistic understanding of how a business strategy is actualized.
Id say that EA frameworks are generally divided into four primary components, often referred to as domains: Business, Information, Applications, and Technology. Some frameworks, like TOGAF, merge the Information and Application components. These domains are usually represented in layered structures, offering a comprehensive approach to managing the complexities of enterprise-wide transformation.
Thank you for your blog post!
The difference between the EA and the BEA are blurring more and more. If not the same person in a small show, surely these individuals are able to bounce ideas off of each other.