Levels of Business Architecture and Business Process Modeling

In the previous article of Modeling Business processes in the software development process, I described the meaning of modeling business processes.

In my opinion, business processes modeling in the software production process is the base to which the subsequent stages of this process relate. System analysts, based on business processes and business requirements, identify use cases and requirements for the system. Testers build test plans and test scenarios (especially when it comes to integration testing). Programmers have an easier task in planning the sequence of implementation of individual functions.

Modeling business processes in the software production process will make sense when the levels of model description abstraction are well chosen. The level of abstraction determines how many details should be presented on a given diagram. On the other hand, the level of abstraction does not specify the amount of information and its scope.

The good news is that we choose the level of complexity of business process diagrams. Bad news is that each of us has a different level of perception of details. It represents a different point of view and what will be too retail for one person and for the other too general.

For this reason, I recommend that analyst teams  should at a common workshop or workshops establish a standard for modeling business processes. It should not be discuss one but several models at the workshop to establish a similar way of looking at similar processes among analysts.

The second issue is the combination of business process models with the world of business process architecture. In my understanding the architecture of business processes is not the same like business architecture,  as its written as “a formal description of the business operation of a part of the organization, at the level of its key components and relations between them, showing how the organization uses its potential (current and planned) to achieve strategic goals and mechanisms allowing the use of this description in the process of making key decisions in the organization “(Andrzej Sobczak – Business Architecture – – How to implement it in the organization?)

My working definition is:

The business process architecture is a set of interrelated business processes that deliver products that correlate with each other or support the same business goal’.

Architektura procesów biznesowych może mniej lub bardziej szczegółowa.

The business process architecture can be more or less detailed. Levels of modeling perfectly reveals the hierarchy proposed by Artie Mahal in the book “How Work Gets Done: Business Process Management, Basics & Beyond, Technics Publications LLC (2010)”

source: https://www.slideshare.net/Dataversity/anatomy-of-a-business-process-how-work-gets-done

At the highest level is the “value chain” or the most general level of processes.

In my work I use a slightly simpler layered model. Depending on the client, it is different, but basically the frame is very similar.

My model consists of 4 layers, which I call levels:

  • level N – business areas or the top-level business process (ArchiMate notation), eg: Sales
  • level N-1 – business processes that represent a minimum one aggregate and usually many processes that provide a specific value, eg: Handling of complaints (ArchiMate)
  • level N-2 – a set of activities leading to a specific result, eg: acceptance of a telephone complaint (BPMN)
  • level N-3 – a set of activities leading to a specific result described using an information system, eg: acceptance of a telephone complaint in the CallCenter system

N-2 and N-3 levels very rarely occur together, but it happens. The N-1 level can only be used in the BPMN by means of a package.

The example below at the N level is large business areas such as Sales, Production, Debt Collection. Each of them can represent and process the sale and a certain business area of ​​the company.

Sales include processes such as product complaint, transaction processing, order acceptance and logistics. These are N-1 level processes. In the diagram below, ordinary aggregation can be used instead of the composition.

These processes from the N-1 level can be refined by BPMN processes from the N-2 level. And so the order acceptance can be made by the website, merchant, partner shop, etc. There are many solutions. Here is an example of the decomposition:

The BPMN processes identified are N-2 or N-3. In this example, I decomposed the complaint process (quite simple and general). The N-2 level does not contain information about the systems.

Below the process in the variant from the N-3 level – already with systems (for simplicity, I use lane instead of pool)

The business process architecture constructed in this way is just an example of the decomposition of the complex world of business.

The world in your organization can be more or less complex. Usually more 🙂

In the software development process, each of these layers  can be used appropriately.

Models at the N and N-1 level usually, together with application services and systems, are useful for describing the solution concept. Levels N-2 and N-3 are concept solutions, specification of business requirements or system requirements.

As you can see from the above, depending on the level of business process modeling, we provide a different scope of information. Thanks to the appropriate architecture of business processes, it is easier to create new and modify existing software.

More from my site

  • Drawing Diagrams – Best Practices One of the aims of modeling is to present complex issues at such a level of abstraction that will allow us to understand a given aspect of the problem. When in the organization models are […]
  • Enterprise Architecture – Modeling Tool When thinking about modeling enterprise architecture, the choice of a modeling tool is very often considered. One of the natural candidates is Enterprise Architect. The […]
  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Requirements Documentation Based on Use Cases Use cases are used to document the functionality of the system and are based on two commonly used concepts: Use case diagramsSpecifications of use cases Objects Use case: The use […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top