Actions

Business Process Architecture

Revision as of 19:10, 28 May 2020 by User (talk | contribs)

A Business Process Architecture is the overview of a set of business processes that reveals their inter-relations, which may be extended with guidelines to determine the various relations between business processes. Having a business process architecture in place provides guidance for the actual modeling of the involved business processes.[1]


According to Harmon, "A Business Process Architecture, ... is a description of the organization's business model and strategy, its goals and its performance metrics. ... the value chains and large scale processes used by an organization that shows how processes support organizational strategies and generate performance metrics." In defining a methodology, Harmon specifically means "a comprehensive and specific set of instructions for accomplishing a task - in this case, redesigning or improving a business process." Yet, he differentiates between methodology and algorithm, saying, "no methodology can ever be an algorithm. At best, a methodology provides an overall approach and a collection of heuristics. ... a precise vocabulary, checklists and worksheets, and specific procedures for accomplishing particular tasks that guarantee that trained teams will approach projects in a reasonably consistent manner and usually achieve the same results." In so doing Harmon moves the definition away from commonly heald distinctions such as framework or taxonomy. "The Supply Chain Council’s SCOR, the TeleManagement Forum’s eTOM, and the Value Chain Group’s VCG Framework are all good examples of generic Business Process Architecture frameworks."[2]


Business process architecture not only describes the functional decomposition of an enterprise value chain, but also provides value streams showing chains of cross functional end-to-end business processes in the operation of the enterprise’s strategies. The business process architecture is critical in all business process modeling works, whether the work is for process documentation or process automation.[3]


Business process architecture imposes a top-down bird-eye view of an organization. It renders the landscape view of business processes. Depending on the method adapted, it is sometimes known as the process landscape or a high level process map providing an overall landscape view or map view of the business processes of business operation. A business process architecture shows the collections of related business activities within specific business functions. The categorizations and groupings depend on the business process framework adopted for creating the business process architecture. You can develop business process architecture from scratch through trial-and-error and drain enormous amount of resource. On the other hand adapting an existing business process framework to build up an organization’s business process architecture not only save times but present the potential of adopting better practices and faster identification for areas of attention.[4]


Business Process Architecture Methodology Illustration
Business Process Architecture Methodology
source: [1]


Business Process Architecture Design Approaches[5]
The Eindhoven University of Technology, through a literature stidy, has identified five classes of approaches for business process architecture design Table 1 shows this classification. In each class of approaches, a business process architecture is designed by first designing another structure, e.g. a goal structure. Such a structure should be designed in terms of the concepts and the relations prescribed by the respective approach. A business process architecture is subsequently designed based on that structure. Note that the classes are not mutually exclusive.


Business Process Architecture
source: Eindhoven University of Technology


  • Goal-Based Approach

In goal-based approaches a goal structure, which consists of business goals and relations between those goals, is designed first. Subsequently, a business process architecture is derived from it, based on the definition of a business. process as a collection of related activities to achieve a certain goal.The benefit of using a goal-based approach is that associating goals with processes also helps to determine why certain processes are important or at all needed. The main organizing concept in goal-based approaches is the ‘goal’, but different approaches distinguish different types of goals. Focusing on different types of goals leads to a different goal structure and, therefore, potentially to a different business process architecture. In addition, different types of goals may be translated differently into processes when a business process architecture is constructed. Different goal-based approaches also distinguish different types of relations between goals. Goal-based approaches differ significantly in the way in which a process architecture relates to the goal structure.

  • Action-Based Approach

In action-based approaches an action structure is designed first. An action structure consists of business actions and their relations. A business action is an activity loop in which a provider completes some work for an internal or external customer. Thus, by definition, it is very similar to a business process. The main difference between a business process and a business action lies therein that business action theory assumes that each human action, and therefore also each business action, follows certain standard patterns and phases. This makes business action theory particularly suitable for identifying processes, delimiting those processes (i.e.: determining where one process stops and the other starts) and dividing a process into subprocesses and/or variants. The patterns and phases help determine which (sub-)processes should exist according to a pattern and where a (sub-)process ends and another begins, because of a transition from one phase to another. Once an action structure is designed, a business process architecture can be derived from it, using the strong similarity between business processes and business actions. The main organizing concept in action-based approaches is the ‘action’ and different approaches distinguish different types of actions. Nonetheless, all action based approaches use the idea that each action goes through a number of phases. However, the exact number and definition of these phases differ per approach. Different action-based approaches distinguish different types of relations between actions. Action-based approaches differ strongly in the way in which a process architecture relates to the action structure. First, approaches differ with respect to how the role of the business process concept is perceived. Most approaches use the action-based approach instead of business processes. Only one of the approaches discusses the relation between business processes and actions. Roughly speaking, this approach equates actions to processes such that actions can be used to identify processes. Second, the approaches differ with respect to the scope of the action structure that is designed. Where a business process architecture focuses on structuring all business processes within a certain scope, the scope of an action structure can vary. Case studies are performed for high-level business functions, such as purchasing, or workflow processes, such as hiring new personnel.

  • Object-Based Approach

In object-based approaches, a business object model is designed first, for example in the form of a UML class diagram. Subsequently, a business process architecture is designed by studying the business objects that exist in the organization, as well as their inter-relations. The main organizing concept in object-based approaches is the ‘business object’. Within both of the identified approaches three types of business objects are considered: ‘permanent objects’, ‘case objects’ and ‘other objects’. Permanent objects are business objects that have a relatively long life cycle in the organization, such as the ‘client’ in most organizations. Processes can be identified from permanent objects by determining what can happen to these objects and defining processes to support these actions. For example, a new client can arrive or buy something, thus leading to the need for a process to register new clients and a sales process. Case objects are objects that guide the execution of a business process and thus directly identify a business process. An example of a case object is an ‘order’ or an ‘application’. Object Modeling is a discipline in itself. The many object modeling techniques that exist distinguish many different types of relations between business objects. Some of these relations are of particular interest in the context of designing a process architecture. The relation between permanent objects and case objects can be used to identify a logical group of processes. A relation between states of one or more business objects can be used to delimit or relate business processes. For example, a state-change of an object from ‘ordered’ to ‘shipped’ can be used to delimit and relate the ‘order’ and ‘shipping’ processes. A decomposition relation between objects can be used to identify a decomposition relation between business processes. For example, the decomposition of a ‘mortgage application’ into ‘client details’, ‘mortgage details’, and ‘securities’ can lead to different subprocesses in the mortgage application process. Finally, a generalization relation can be used to identify a logical group of processes. For example, a generalization relation between ‘apply for car insurance’, ‘apply for home insurance’ and ‘apply for insurance’ can be used to identify a logical group of insurance application processes.

  • Function-Based Approach

In a function-based approach a function hierarchy is designed, which represents the decomposition of business functions into more detailed business functions. Thus, the main organizing concept in the function-based approach is the ‘business function’, which is defined as a capability of an organization, such as ‘production’ or ‘procurement’. This relation that is considered is always a decomposition relation. A business process architecture can be subsequently structured according to the function hierarchy. The benefit of using business functions to identify processes is that, compared to business processes, business functions are relatively simple to identify and stable, because they focus on what an organization does rather than how the organization accomplishes that. Consequently, business functions arguably form a good starting point for designing a business process architecture. The duality of business processes and functions is well known and frequently used in business process modeling frameworks. There are roughly two ways in which a function hierarchy can be related to a business process architecture. Firstly, the function hierarchy can be the primary way of organizing the business processes. In that case, functions are decomposed into more detailed functions until a chosen level of decomposition is reached from which the functions are further decomposed into processes. In this case, business processes are organized according to the functions to which they belong. Secondly, functions and processes can both be organized into hierarchical structures through decomposition relations, which should be closely aligned.

  • Reference Model Based Approach

In reference model based approaches, an existing business process architecture; the reference model; is re-used and adapted to design a new business process architecture. To a certain extent, reference model based approaches are orthogonal to other approaches, because the reference model may itself be developed using one of those approaches. Many reference-model based approaches are organized functionally. The major benefit of reference model based approaches is that much time can be saved by starting from an existing model. Also, the reference model is meant to present a set of best practices and may thus lead to better designs. A large number of business process reference models exist. Fettke, Loos and Zwicker published a survey that covers 30 of these. However, the focus of these reference models is on presenting a collection of business process models, not on the business process architecture that structures the collection itself. In most cases, the business process architecture is a by-product of the reference model, although it is sometimes considered and published separately. In the context of business process reference models, the business process architecture is commonly referred to as a business process (architecture) framework and takes the form of a classification. What distinguishes the classifications are the concepts that are used for classification, the relations between elements in the classification, and the specification of abstraction levels in the specification. Fettke, Loos and Zwicker found that the two most-used concepts to classify business processes in a business process architecture are the business function and the industry segment. In addition, a classification can be done based on a predefined classification that is based on consensus rather than a single concept. APQC’s Process Classification Framework defines such a classification. The most prominent relations between business processes in reference models are those of generalization and decomposition.


Benefits of Process-Based Business Architecture[6]

  • Some of the harder benefits to recognize are:
    • Realigned or better aligned performance investment plan with traceability
    • Realigned or better aligned performance metrics
    • Increased performance of your IT investment portfolio
    • Faster decision-making
    • Better investment project scoping
    • Reduced IT investment waste
    • Reduced execution risks for core or strategic programs.
  • The softer benefits are not so soft!
    • Shared meaning and common language among leaders
    • Stronger engagement and ownership
    • Clearer sense of direction
    • Reinforced leadership team
    • Re-framed thinking and visioning
    • Alignment, alignment, alignment
    • Breaking down of silos.


See Also

Business Model
Business Process
Business Process Model
Business Process Management (BPM)
Business Process Modeling Notation (BPMN)
Business Process Modeling


References

  1. Definition - What does Business Process Architecture Mean? Remco Dijkman, Irene Vanderfeesten, Hajo A. Reijers
  2. Defining Business Process Architecture bpcem
  3. What is Business Process Architecture? orbussoftware.com
  4. Explaining Business Process Architecture BPM Professional
  5. Business Process Architecture Design Approaches Eindhoven University of Technology
  6. What are the benefits of Process-Based Business Architecture? Leonardo Consulting


Further Reading