My preferred business architecture model is shown in the schematic. The model reinforces that people/process/technology are intertwined and it is impossible to develop a true understanding of any individual element in the model in isolation of the context provided by at least one other of the nine points.

This document is going to focus on the three primary elements of People, Process and Technology. 

The remaining business concepts such as culture, rules etc, will be addressed in separate documents.

Each of the three elements is summarised below and then discussed in more detail.

People

There are three elements:

1. Names: refers to specific individuals. It is the name of employees, suppliers and/or partners in the extended architecture.
2. Positions: refers to the formal position the individual holds in the business
3. Roles: refers to the role/s the position can fill in the day to day operations on the business.

Process

There are three elements:

1. Flows: refers to the transactional flow of activity within the business. Typically these flows are called process maps, but for a business architecture model this term is too generic, as there are two other processes that need to be described as part of the architecture. The transactional flow is a better term. This is process 1 of 3.
2. Management: refers to the active management of a specific process. In this case management is a defined process (This is process 2 of 3)  and comprises of specific steps as shown

      3. Organisational structure: refers to the aggregation of the individual management processes to form the organisational structure.

Technology

There are three elements:

1. Service Points: refers to those points in the process where information needs to present itself.
2. Information: refers to the specific information or information set that must be presented at the service point. This is process 3 of 3.
3. Applications: refers to the specific application or application set/s that will provide the information.

People

The most basic People element is the people themselves, the employee. They can be represented by a list of names on a page. By itself, it is just a list and of limited value. When associated with positions and/or roles its value increases significantly. This relationship is typically established with a RACI table. A RACI table describes who is Responsible, Accountable, Contributes, and is Informed by the process.

In the matrix, column A represents all the processes that make up the accounts payable function and the process steps of each process. This is the basic building block for job descriptions, training materials, user access security models etc.

A key consideration when using this approach is to decide upfront if you will use job titles/positions, or role descriptions as you map the processes. This distinction is important, as staff will frequently perform a role that is not traditionally associated with their position or title. Often this is the case when managers intermittently stop managing the process and start working in the process. For example: a finance manager may decide to perform an invoice run or pay a supplier. Both of these actions would normally be completed by an accounts receivable or payable clerk. When the manager performs these tasks, then they are taking on the role of the clerk.

In some cases there is no issue; in other cases the manager may not have the authority to access the system as they may also inadvertently receive the means to see privileged information such as the payroll. Therefore best practice is to map the business using roles, and then determine which position is entitled to play which role.

An alternate view is a comprehensive job description that relates the role to specific processes and process steps. This will substantially assist training and recruitment. The following is a simple example of such a job description could include:

 

Process

Understanding business process starts with establishing the hierarchy of processes. Decomposing the business from a macro enterprise process view to a detailed process view is fundamental to understanding ‘lines of business’, silos and the ‘hand off’ between processes.

Traditionally business analysts will talk of process level ‘X’, where X is normally 1 to 5. Detailed process flows are typically level 4 and procedures or work instructions are level 5. Levels 1 to 3 represent how the business aggregates the detailed processes into functions and departments.

When mapping a business or transactional process there are a few guidelines that can improve the quality of the activity:

• Use a consistent template. If you map one process using the swimlane format, then map all process the same way. Experience shows that business analysts tend to prefer the swimlane layout and end users and trainees prefer role based process flows.

• Use roles not positions wherever possible
• Describe the process step using a verb-noun combination. Always try to start the process step description with a verb.
• There are three types of automation; manual processing, computer assisted manual and fully automated. Only fully automated steps should receive their own swim lane if your methodology is to show technology as a role. Computer assisted manual should be shown as part of the process step.
• A process map should be 8 to 12 steps.
• Keep system process maps related but separate from business process maps.
• Define the trigger process/es and the hand over process/es.
• Ensure you keep the unit of measure (UOM) in mind at all times. The UOM is what triggers a process. For example, an application form. This will be particularly important when the time comes to calculate process volumes, standard costs and staffing needs.
• Identify any reports produced.
• Identify all control points in the process. There may different control points for different compliance needs in the business.

 Management Process

The management process is a separate process from the transactional process. The management process is represented by the collection of control documents the manager uses to control the processes in their portfolio. The term ‘manager’ includes everyone from Team Leader to Chief Executive Officer. Control documents include everything from white boards on the wall, clip boards, volume counts, electronic light boards, to detailed print outs from the ERP system.

The fundamental principle is that these documents represent the controls the manager uses to work ‘on’ the process, not ‘in’ the process.

The management process has two halves.

The transactional process separates the two halves of the management process.

The first half comprises those controls that manage demand for the process. They tell the manager the hourly/daily/weekly/monthly, etc volume for the process and the resource requirements needed to meet that volume.

The second half comprises the control documents that the manager uses to measure and control the process through KPIs etc.

The following schematic is an illustration of a simple scorecard in MS Excel:

Each process has its management. This is founded on the principle that you can have process without management, but you cannot have management without process.

As many management processes are combined, so is the organisation structure is established.

 

Technology

The third major element is technology. And the key sub element is information, as it is information that glues the business together.

There are two types of information. Information within a process and information used to manage the process.

When modelling information, it is important to take into account the attributes and characteristics of information. Of particular relevance are the physical and quality attributes of information as they define what information will be presented at a service or control point and how it will be presented.

Defining each attribute requires that the information architect consider information sets and fields. Many fields make up a set. An example of a field is First Name. Surname would be a different field. Grouping common or related fields creates a set. A set can be what is displayed on a screen, a report or a printed document. The boundaries of a set are defined by the quality attributes.

Once the architect has defined what information is required and where, then they can model how the information will be gathered by defining the detail behind the physical attributes.

The following is a simple example of this can manifest itself. The report represents the information set. The fields are shown as are their source application.

An alternative view of information sets and fields could look as follows. In either view, the attributes of both the sets and the fields would require further definition – for example, the alphanumeric, decimal places, arrays, etc.

Information within a process can also be readily summarised in a matrix that aligns the information requirements in the form of rules or functionality sets, to the business processes.

Information to manage a process introduces the concept of management views or frameworks. A framework is an alternative way to see the business. Popular frameworks include eTom for Telecommunications, ITIL for IT, APQC for business analysts and Sarbanes Oxley for Finance. The business architect should be aware of the frameworks being used by the business and model the information flows according to the needs each framework.

This concept is illustrated as follows. There is one business and in this example, four different ways of looking at the business.

These views do not corrupt the message. Rather they focus it to remove ‘noise’ and other irrelevant data. Frameworks guide the manager as to what should be considered when transacting the business process, and which parts of the processes need to be controlled to ensure that the business is adhering to its internal policies and applicable external regulations, legislations etc.

Frequently the same process step is a control point for different frameworks.

The difference is that each framework demands different information from the process step according to the risk being managed. When this is aligned to roles the extended model looks as follows.

In summary, the relationship between the Management, Transactional and Information processes is depicted as follows:

These three processes need to be treated as separate but related processes, and whether they are defined or not, all three will always exist.