Chapter 8: Business Architecture Models

The business architecture is the highest of the three core architecture layers in an enterprise. Many architects start their Enterprise Architecture (EA) practice at this layer, followed by the application layer, and then the technology layer.

The business architecture is often approached first because it traditionally occurs when the EA practice is defined and documented, with the intent to build the other layers around the business, which is a correct approach, and it keeps the business as the driver for changes. Additionally, TOGAF® has the business architecture as phase B of the Architecture Development Method (ADM), which guides its practitioners to have it in the early stages of the EA practice. However, due to the reasons that have been described in detail in Chapter 1, Enterprise Architecture and Its Practicality, one of the practical approaches that this book encourages is to start from any layer in the enterprise where there is a demand for EA input, and not to follow a waterfall sequence.

The business architecture layer is concerned with the business aspect of an enterprise, such as what the business provides to the world, how it achieves that, how the organization is structured, which business units are assigned to which functions, services, or processes, and how these business architecture elements are automated and realized by elements from the application and the technology layers. This is what we are going to cover in this chapter, and it can be summarized in two sections:

• Modeling the business structure
• Modeling the business behavior

If you are reading this book from the beginning, this chapter should be very easy and straightforward because you will have seen that most elements have been introduced in the application and the technology layers, as covered in the previous chapters. The only difference is that they cover a different aspect of the enterprise in this layer. If you are reading non-sequentially, then we recommend that you check out the following Technical requirements section and make sure that you have what you need to start.

Technical requirements

If you want to practice modeling while reading to achieve the best results, you need Sparx Systems' Enterprise Architect. If you do not have a licensed copy, you can download a fully functional 30-day trial version from the Sparx Systems website (https://sparxsystems.com/products/ea/trial/request.html).

We will continue adding the content of this chapter to the EA repository that we built in the previous chapters. If you want, you can download the repository file of this chapter from GitHub at https://github.com/PacktPublishing/Practical-Model-Driven-Enterprise-Architecture/blob/main/Chapter08/EA%20Repository.eapx instead of starting from scratch. Some of the steps in this chapter depend on elements that have been already created in the repository, so it is best not to start this chapter with an empty repository.

We will use the following ArchiMate® 3.1 specification chapters to guide our development:

• Chapter 5, Relationships (https://pubs.opengroup.org/architecture/archimate3-doc/chap05.html#_Toc10045310)
• Chapter 8, Business Layer (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045365)
• Chapter 12, Relationships Between Core Layers (https://pubs.opengroup.org/architecture/archimate3-doc/chap12.html#_Toc10045440)

The metamodel diagrams in the aforementioned references will be used throughout this chapter, so we highly recommend that you print them and keep them within reach. When you are ready, we can start learning how to model the business structure.

Modeling the business structure

The business structure describes what the tangible elements are that compose the enterprise, and who is assigned to what. Modeling the business structure will answer questions such as the following:

• What are the business units that comprise this enterprise?
• What are the business roles that operate it, and who are the people assigned to these roles?
• Who are our customers and partners?
• What channels do these customers and partners use to access our services?

Now that we know the type of question we will answer in business structure models, let's start by defining the first business active structural element, which is the business actor.

Defining business actors

"A business actor represents a business entity that is capable of performing behavior." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045368)

Business actors can be internal or external to an enterprise. Customers and partners are considered external business actors, while business units and divisions within the enterprise are considered internal. Business actors within ArchiMate®'s context must not be confused with actors in UML. They both use the same stickman notation, and they are both called actors, which causes confusion. Actors in UML usually indicate users of the system that we are modeling, and these users can either be people or other systems. However, business actors in ArchiMate® represent business entities such as an entire organization, a division within it, or a person.

The more relevant elements to UML actors in ArchiMate® are business roles, which we will explain in more detail in the next subsection. To easily differentiate between business actors and business roles, always ask yourself, is it a position? If so, then it is a role. However, if it is a business unit or a specific person, then it is an actor. For example, accounting is a business unit, so it is a business actor. Accountant is a position, so it is a business role. John Smith, the accountant, is a business actor because individuals are business actors as well.

The last thing to keep in mind is that business actors can be assigned to multiple business roles, which makes sense as you often find some people playing multiple roles and occupying multiple positions in an organization.

ArchiMate® 3.1 provides two types of notation for modeling business actors, Rectangular Notation and Borderless Notation, as you can see in the following figure:

Figure 8.1 – Business actor notation

Business actors, in addition to other internal active structure elements, are responsible for providing the behavior of the business, such as business processes, business functions, and business interactions. We will talk in more detail about the business internal behavior elements in the Modeling business behavior section of this chapter. The following diagram shows the business actor-focused metamodel:

Figure 8.2 – The business actor focused metamodel

The simplest diagram that you can use business actors in is the organization chart diagram. You can show how the organization can be decomposed into business units that can themselves be decomposed into smaller business units, and so on. The following diagram shows an example of the ABC Trading organization chart:

Figure 8.3 – The ABC Trading organization chart

We are sure that your actual organization chart will be larger than this example, so you may consider keeping the first level of the business actors in one diagram and having multiple child diagrams, each showing the details of a single business actor at a time. We will see more examples of modeling business actors as we explore the other business architecture elements, so let's read more about business roles first.

Defining business roles

"A business role represents the responsibility for performing specific behavior, to which an actor can be assigned, or the part an actor plays in a particular action or event." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045369)

Since business actors represent business units or business entities in general, business roles represent the actual responsibilities within the business units – in other words, the job positions that are supposed to perform the behavior. The accounting business unit requires specific roles, such as the chief accountant, controller, treasurer, and tax accountant. All these roles can be assigned to actual people who are business actors. Remember that business actors can represent specific people or business units, so a person can be assigned one or more roles within a business unit.

ArchiMate® 3.1 provides two types of notation for modeling business roles, Rectangular Notation and Borderless Notation, as you can see in the following diagram:

Figure 8.4 – Business role notations

Business roles are similar to UML actors. The only difference is that in UML, actors represent the users that perform actions (or behavior) on a specific system, while ArchiMate®'s business roles exist within the entire enterprise, not on a specific system. The following diagram shows the focused metamodel for the business role:

Figure 8.5 – The business role focused metamodel

As you can see, the business role focused metamodel is identical to the business actor-focused metamodel, and that's because they both specialize from the generic type of business internal active structure element and represent entities that are capable of performing behavior. Business behaviors such as business functions or business processes can either be performed by an entire business unit or by a specific role within that unit, and therefore, you can see that both business actors and business roles can be assigned to all business internal behavior elements.

A business actor can be assigned to one or more business roles, so in small enterprises, you can still use an organization chart from a large enterprise, but in this case, you will require your business actors to play multiple roles, which is a very common practice. The opposite is also true – you can have multiple actors assigned to the same role. It all depends on the size of your enterprise and the skill sets that your business actors possess. The following diagram shows an example of how business actors can be assigned to business roles:

Figure 8.6 – Business actors assigned to business roles

One of the very powerful features of Sparx is that it can tell you how many items are linked or connected to a specific item. If you close the preceding diagram or even delete it, you will still have the items and the defined relationships in the repository. Right-clicking on the Business Analyst role in the project browser and choosing Properties > Properties > Links from the context menu will show you all the items linked to it and the types of the relationships. This way, you can find out that Max and Sarah are both assigned to this role even if you do not see the diagram.

Each business role is expected to perform a specific set of behaviors, such as business functions, business processes, and business interactions. The processes that a project manager is expected to perform can be described in a diagram such as the following:

Figure 8.7 – A business role assigned to business functions

One of the most beautiful things about ArchiMate® is that it allows you to describe almost everything in an enterprise in a model. For example, the preceding diagram can be used as a job description for the Project Manager role. You can develop a diagram like this for each business role that you have within your organization. The human resources department can publish this information on the company's website or intranet as part of its documentation process.

We will learn more about publishing content from Sparx in Chapter 11, Publishing Model Content. For now, let's look at another business structural element, which is business collaboration.

Defining business collaboration

"A business collaboration represents an aggregate of two or more business internal active structure elements that work together to perform collective behavior." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045370)

A business collaboration element can be an aggregate of multiple business actors or business roles to provide a collaborative behavior. A joint venture between a shipping firm and an online shopping business is an example of business collaboration. It is a strong form of partnership but weaker than merger and acquisition. Both businesses can still act individually and independently from each other, but together, they can behave differently.

ArchiMate® 3.1 provides two types of notation to model business collaboration elements, as you can see in the following diagram:

Figure 8.8 – Business collaboration notation

The business collaboration-focused metamodel is a replica of the business actor- and business role-focused metamodels, as you can see in the following diagram:

Figure 8.9 – The business collaboration focused metamodel

If ABC Trading and one of its partners decided to increase the level of partnership to form a union, that is a business collaboration. It is a form of aggregation that is stronger than a partnership but weaker than a merger. Through this collaboration, both partners will be able to provide services and perform processes in ways that would have been impossible individually.

The next structural element that we will look at is the business interface.

Defining business interfaces

"A business interface represents a point of access where a business service is made available to the environment." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045371)

Businesses must provide services in order to generate revenue and remain operational. Business services are provided through interfaces, and these interfaces can take the form of a web portal, a mobile app, a kiosk, a customer service number, or a reception office inside your physical location. Therefore, business interfaces are not necessarily computerized or automated. Digital business services need to be provided through digital business interfaces for sure, but if your business fixes cars, then it must be provided in a workshop. The reception office in the workshop in this case is the business interface. Think of business interfaces as the channels that make services available to their consumers.

ArchiMate® 3.1 uses two types of notation for modeling business interfaces, as you can see in the following diagram:

Figure 8.10 – Business interface notation

Business interfaces provide services to structural components in the business, application, and technology layers. The following diagram shows the focused metamodel for the Business Interface element:

Figure 8.11 – The business interface focused metamodel

An automated (or digitized) business interface is one that has been realized by one or more application or technology interfaces. If it is not realized by any, it means that it is a manual or in-person business interface. Some types of services must be provided in person, no matter how advanced your business is. The following diagram shows an example of how multiple business interfaces are assigned to one business service:

Figure 8.12 – Multiple business interfaces assigned to a service

The preceding diagram tells us that there are three business interfaces assigned to the Wholesales business service. One of them is digitized and is realized by two application interfaces. It is also possible to assign the same business interface to multiple business services, which means that this interface is used to provide more than one service to the consumers.

The next and last structural element that we will explore is the business object.

Defining business objects

"A business object represents a concept used within a particular business domain." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045381)

Business objects represent information that means something within a specific business domain. Business objects such as customer, invoice, package, and product all have meaning within the ABC Trading company, while claim, deductible, encounter, and policy are information that has meaning within another business that deals with insurance. Regardless of whether these business objects are digitized or not, and regardless of the digital format they exist in, they are considered business objects within the business context. Digitized business objects are the ones that are realized by data objects and technology objects.

Let's talk a little more about this to clarify it. The product, for example, is the physical item that you sell to your customers, and the information that you know about it is the product's business object. A customer is a business actor that consumes services from your business. The information that is related to the customer actor, such as name, phone number, and address, is the customer business object, so we're talking about two architectural elements here – the customer actor and the customer business object.

Whether the information about the customer business object is stored in paper files, in the heads of the salespeople, in databases in binary, or even in quantum formats, they are all different forms of realizing the same business object by different technologies. Even paper files and cabinets, while outdated, are considered technologies. However, the concept of the customer within the context of the business is always the same, and that is what business objects represent.

Unlike most other elements, ArchiMate® 3.1 provides only one type of notation for modeling business objects. The following diagram shows the business object focused metamodel with the Business Object notation in the middle of it:

Figure 8.13 – The business object focused metamodel

Because business objects are passive elements, the only permitted relationship between them and the other business architecture elements is the access relationship. The following diagram shows an example of how business process elements access business objects:

Figure 8.14 – Business processes accessing business objects

In real-world examples, your objects will be architected differently, such as having the customer history as an independent element or having loyalty points as part of the customer profile. It depends on how your business recognizes the objects; the size does not matter. If loyalty points mean something to the business, then you may model them in their own business object, as we did. If they are meaningless without being part of a bigger business object, then you may go with a different design. Either way, the concept of what can be considered a business object is clear, we hope.

This concludes our section about modeling business structure, and since only describing the structure of the business is not enough, we need to describe the behavior as well, and that is what we will be covering in the next section.

Modeling business behavior

Business behavior models show how your business performs things such as the following:

• How services are provided
• How requests are handled internally
• What are the steps to be followed, and are they automated or not?
• What resources are required to perform which behavior?

All these questions and more can be answered in architecture models that describe business behavior. This is what we will learn in this section, and we will cover these topics:

• Defining business services
• Defining business processes
• Defining business functions
• Defining business interactions
• Defining business events

With that said, let's start with the first business behavior element – the business service.

Defining business services

"A business service represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045378)

Business services in general are the visible parts of the business that are exposed to the external environment. A customer does not see what business units your organization has, nor which actor is assigned to which role. They also do not see how you work internally to deliver the services. All that they see and know about your business are the exposed parts, which are the business services.

However, the concept of business services does not only apply to the entire enterprise and its external service consumers. Each internal business unit can be perceived as a provider of services to other business units within the same enterprise. Additionally, each business role can be assigned to provide a specific set of services to other business roles and business actors. Therefore, the business services are contextually defined by the business structural element that is assigned to them.

ArchiMate® provides two types of notation for modeling business services, Rectangular Notation and Borderless Notation, as you can see in the following diagram:

Figure 8.15 – Business service notation

Because the business services are meant to be exposed to serve other elements, this metamodel is busier than other focused metamodels, as you can see in the following diagram:

Figure 8.16 – The business service focused metamodel

Let's take examples to clarify some ideas on business services and the preceding metamodel. As mentioned earlier in this subsection, business services that are provided by an entire enterprise can vary from business services that are provided by a specific business unit inside that enterprise. Partners of ABC Trading can only see what it offers outside its environment, as depicted in the following diagram:

Figure 8.17 – ABC Trading exposed services

However, with an inside look at ABC Trading, we can see different sets of services that are serving different sets of consumers, as indicated in the following diagram. The Human Resources internal business actor (or business unit) is assigned to the Recruiting service, which is an internal service that only other internal business actors can see and use. Accounting, on the other hand, is assigned to two business services – Billing and Salary Deductions. The Billing service serves external partners, while the Salary Deductions service serves the Human Resources internal business actor, as shown here:

Figure 8.18 – Different services provided within a different scope

External business actors such as partners do not see the internal business services. Moreover, they are also not concerned about which business unit provides the services. They see that the ABC Trading business actor is assigned to the billing and wholesales services.

A business services catalog is an architectural artifact that contains a list of all the business services that are provided by a specific business actor (or business role or business collaboration) to its external environment. So, whenever you develop a business services catalog, you need to ask who the business actor is that you are modeling, what is considered internal to it, and what is considered external.

Then, only consider the services that target its external environment. Only consider what the external environment sees from this business actor. Recruiting, for example, in Figure 8.18 cannot be considered part of the ABC Trading business services catalog because it is an internal service. However, if you are modeling the human resources business actor and want to define its service catalog, then recruiting will be a part of it for sure.

The next behavior element that we need to look at closely is the business process.

Defining business processes

"A business process represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045374)

For a business service to be realized and provided to customers, the business needs to perform some activities in a specific sequence. This sequence is what is referred to as business processes. The maturity of any business can be measured by how well documented its business processes are. Business processes need business structural elements to be assigned to them because they need something or someone to perform them. They also need to have access to a certain type of information in order to perform their activities.

Business processes exist in every business all the time. Building the pyramids must have followed a specific process or else they wouldn't exist. Building a colony on Mars would also follow a specific process. Automated or not, that's a different story, but business processes have no relation to technology. Technology makes them faster and more efficient, but the automated processes are defined using the application process and the technology process elements. They realize the business processes or parts of them. A fully automated business process is one that has all its activities realized by an application process or a technology process.

ArchiMate® provides two types of notation for modeling business processes, as you can see in the following diagram:

Figure 8.19 – Business process notation

Business processes can aggregate business functions, and business functions can aggregate business processes. In most cases, business functions are at a higher abstraction level than processes, so they aggregate them. In some cases, you may find that high-level business processes aggregate mid-level business functions, which aggregate lower-level business processes. There is no limit to the deepness of this nesting loop, but too much nesting can become confusing, so keep that in mind.

A quick and easy way to differentiate the two is that business functions are abstracted and do not have a sequence, while business services have more details and contain a sequence. We will talk in more detail about business functions in the next subsection, Defining business functions, with more examples of how to differentiate the two. The following diagram shows the Business Process-focused metamodel:

Figure 8.20 – The business process focused metamodel

Business processes can be triggered by any other behavioral element, such as business events, business functions, and business interactions. They can also be triggered by other business processes. When one process finishes, it triggers the next process, and the control flows from one process to another until the entire process is complete, as shown in the following diagram:

Figure 8.21 – A multi-level business process

When a business process is automated, it means that it has been realized by one or more application and technology processes. A single business process can have different application processes realizing it in the same application or different applications, each realizing a part of it. If you are transitioning from a legacy application to a modern one, there is a high probability that you will find that the same business process is realized more than once in multiple applications. The following diagram shows an example of a business process that is realized by multiple application and technology processes:

Figure 8.22 – A business process realized by application and technology processes

Remember not to confuse business processes with application processes and technology processes. They are all types of processes, so they all have a sequence and aim to achieve specific results. They are just describing other layers of the enterprise. Please refer to the Describing application behavior section of Chapter 5, Advanced Application Architecture Modeling, to learn more about application processes. Also refer to the Using technology behavioral elements section of Chapter 7, Enterprise-Level Technology Architecture Models, to learn more about technology processes.

The next behavioral element that we will explore is the business function, which is tightly related to the business process. Let's see how.

Defining business functions

"A business function represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045375)

Business functions are internal behavioral elements, so they are only visible internally, inside the enterprise. They can compose or be composed of other behavioral elements, such as business processes, business interactions, and other business functions. So, a business function can be composed of business processes and business functions. Business processes can be composed of other business processes and business functions.

Business functions are abstracted and answer the question of what the business performs internally. Business functions do not stipulate how to do things, so they do not involve a sequence of actions. Business functions can be grouped based on criteria that the business decides. It could be geographical, financial, managerial, or any other grouping that makes sense to the business. You can have eastern region sales and western region sales, for example, as two business functions under a bigger business function called sales. The two regional functions can share some resources, but they also have their own resources assigned to them. They may also perform things differently, which means that they comprise different sets of business processes and/or lower business functions.

Business functions need resources such as business actors and business roles to be assigned to them because behavior cannot be performed without a structure. This is why business units (actors) and business functions can carry the same names. The human resources business unit (actor) is assigned to the human resources business function. They are two elements despite having the same or similar names. The actor can either be internal or external to the enterprise, so some business functions can be performed by third parties. The customer service function is a very common example of an outsourced business function.

ArchiMate® 3.1 provides two types of notation for modeling business functions, as you can see in the following diagram:

Figure 8.23 – Business function notation

In the following diagram, you can see the focused metamodel for the Business Function element. Because business functions and business processes are both internal behavioral elements, their focused metamodels are almost identical:

Figure 8.24 – The business function focused metamodel

Business functions are realized by application functions and technology functions. The following diagram shows you an example:

Figure 8.25 – A business function realization

As we can see, the Human Resources business actor is assigned to the Human Resources Management business function. In this company, they use a business application for managing enterprise resources, and one of its application functions is Human Resources Management. Even with the business function and the application function are having the same name, they are still two architectural elements in two different layers.

The following diagram shows how a business function can be composed of smaller business functions, which themselves can be composed of smaller business functions or business processes:

Figure 8.26 – An example of the human resources business function

Using the preceding diagram as a reference, you can create your enterprise business functions catalog. Do not be surprised if you end up with a diagram that is very close to your organization chart because, in many organizations, business units are assigned to business functions in a one-to-one relationship.

The next behavioral element on our list is the business interaction element.

Defining business interactions

"A business interaction represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045376)

Business interactions are just like other behavior elements (business services, business processes, and business functions) – they describe a behavior that is performed by a business collaboration, not a single business actor or role. Therefore, business interactions exist within your enterprise only when there are business collaborations.

Business interactions can be composed of multiple business functions and processes, which means that the business interactions that are performed by a business collaboration element are actually composed of business functions and processes that are performed by the structural elements (actors and roles) composing the business collaboration.

ArchiMate® 3.1 provides two types of notation for modeling business interactions, as you can see in the following diagram:

Figure 8.27 – Business interaction notation

Due to the limited usage of business interactions, we will leave it to you to develop their focused metamodel, which will be identical to the metamodels for Business Process in Figure 8.20 and Business Function in Figure 8.24.

The last behavioral element that we will look at is the business event element.

Defining business events

"A business event represents an organizational state change." (https://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc10045377)

Business events occur either internally within an enterprise or externally to it. When they occur, they trigger other behavioral elements, such as business processes, functions, interactions, and services. An external event can be like a customer submitting a request, a partner who is out of business, a change in the supply or demand of a specific product, a merger, or an acquisition of a new business. Examples of internal events include the establishment of a new business role, the closure of a business unit, the reception of a customer request, the fulfillment of a customer request, the completion of end-of-month payroll processing, and achieving the quarterly financial goals.

Just like many other elements, ArchiMate® 3.1 provides two types of notation for modeling business events, as you can see in the following diagram:

Figure 8.28 – Business event notation

Business events trigger and get triggered by other business behavioral elements. The submission of a customer request will trigger a series of business processes to fulfill that request. These processes can themselves trigger other behavioral elements, such as other business processes, functions, interactions, and events. This series of actions will keep going until there is no more behavior to be triggered. Figure 8.29 shows an example of a business event triggering a business process that contains smaller business processes, and finally, it triggers another business event upon completion.

Additionally, and just like all other behavioral elements, business events need a business internal active structure element to be assigned to them, such as a business actor, a role, or a collaboration. The following diagram shows the focused metamodel of business events:

Figure 8.29 – A business event focused metamodel

Automated business events are realized by application and technology events, but not all business events are necessarily automated. Customers' requests can still be received over the phone or by mail, for example. If the organization has an application that allows customers to submit requests online, then an event inside that application will be fired and trigger a series of automated application processes to automatically fulfill the request. The following example depicts how automated business events and business processes can be realized:

Figure 8.30 – An example of realized business events and processes

This diagram shows that to completely automate business events and processes, you may need to realize them through multiple elements in multiple architecture layers, and that realization is not necessarily one-to-one. Some business processes, as you can see, get realized by one or more application and technology processes.

We hope that this chapter has helped you understand the principles of modeling business behavior; let's summarize what we have learned.

Summary

As we have seen in this chapter, business architecture elements look very similar to their counterpart elements in the application and technology layers. However, even if they look alike, the business architecture elements describe the business regardless of the availability of applications and technology.

Automated business elements are realized by application and technology elements. Knowing this is critical for many businesses as they seek higher maturity levels. If your organization keeps everything in an EA repository, as it should, elements can be located in a few minutes. This is the power of EA, and this is the helpfulness of an EA tool such as Sparx.

In the next chapter, we will combine the knowledge and the experience that we have gained regarding building business, application, and technology models under the business capabilities umbrella.