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 provide 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 it 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 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. The 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.

Why Interfacing?

Interfacing can also explain how you can adopt our Enterprise Process Center to document and manage your Business Architecture and Enterprise Architecture. With the adoption of our Enterprise Process Center, your organization will experience an increase in agility and flexibility, as well as delivering fast responsiveness to new business challenges and demands. Enterprise Process Center also allows your organization to develop with cost-effective, long term planning capabilities.

If you would like to see more or discuss how Interfacing can help your organization, be sure to click below.