Enterprise Architecture Management in Business Networks

In my last blog post, I wrote about multi-cloud scenarios for enterprise applications focusing on enterprise applications of one company distributed over several different cloud providers. This blog post will be about enterprise applications connecting data, processes and the organization of different companies within business networks. Particularly complex scenarios with a high competition and margins, such as third party logistics (3PL) require a sophisticated approach ensuring and extending competitive advantages. We will see challenges when applying reference models, such as EDIFACT, ASC X12 or SCOR. Nevertheless, I see reference models – or more particularly their combination – as key success factors for business networks, since they represent best practices, common understanding and can significantly improve on-boarding as well as continuous education of new business network members. Hence, I will discuss how enterprise architecture and portfolio management can support the application and combination of different reference models in business networks. Finally, I present how the emerging concept of virtual software containers can support this approach from a technology perspective.

Types of Business Networks

One interesting question is what constitutes a business network [1]. Of course, it can be predefined and agreed upon, but there are a lot of business networks, where there are undefined and informal relations between two companies that have also (in-)dependent relations with other companies. The whole network of relations is called a business network. This is very similar to social networks where there are two related human beings that have independent relations to other human beings. However, all types of business networks have different forms of implicit or explicit governance, i.e. decision-making structures. Implicit governance refers to the fact that the chosen governance model has not been defined or agreed on by all involved parties in a business network. Explicit governance refers to an awareness and definition of governance arrangements by all parties in a business network.

The following generic modes of governance can exist in a business network (see next figure):

  • One inherits most / all types of decision-making roles and the others have merely an execution role

  • A group inherits most / all types of decision-making roles and a majority has only a execution role

  • Several large groups with decision-making roles related to different aspects and a majority has only execution role

  • Everybody has every role


Additionally, business networks may expose a different degree of awareness and intensity of relations. On the one hand you may have a very structured business network, such as supply chains and on the other hand there is the free market where two parties directly interact without considering other parties in their interaction. Both extremes are unlikely and we will find companies on the whole spectrum. For instance, within a larger supply chain, one company may know only the direct predecessor and the direct successor company. It may just agree on the specification of the product to be delivered, but may not include any data or impose any processes on how the product should be manufactured. This means there is a limited degree of awareness and the intensity is less strong, because they do not really know how something is achieved by the other organizations in a business network.


It can be observed that business networks become more complex, because new types of business networks emerge, such as contract logistics or third party logistics, where your business partners directly integrate dynamically in your manufacturing plant or point of sale as well as corresponding business processes. Hence, you need to work out best practices and stay ahead of the competition. An example can be seen in the previous figure, where the third party logistics provider has a packaging business process deployed at “Manufacturing Plant A”. This business process leverages applications and other resources within the sphere of “Manufacturing Plant A”. Besides delivery, the third party logistics provider integrates similarly in “Manufacturing Plant B”, where it does pre-assembly of the delivered parts from “Manufacturing Plant A”.

Applying Reference Models for Business Networks

Reference models exist since several decades in the area of business information systems, management and software engineering. Some are driven by academia and others are driven by industry. Usually both have been validated scientifically and in practice.

Reference models represent best industry practices for business processes derived from experts and organizations. They can cover the process, organization/governance, product, data and/or IT application perspective within a given business domain. Hence, they can also be viewed as standards. Examples for reference models are EDIFACT, SCOR, Prince2 or TOGAF. These are rather generic models, but there are also industry specific ones, such as the one existing for humanitarian supply chain operations [2] or retailing [3].

The main benefits of reference models with respect to business networks are:

  • Support your Enterprise Architecture Management (e.g. by reduced modeling efforts, transparency or common language)

  • Benchmark against industry

  • Evaluation of applications for enabling business networks

  • Business network integration by integrating available applications in a business network

There some issues involved when using reference models:

  • They are “just” models. Having them is like having a book on a shelf – pretty useless

  • Some of them are very generic applying to any business case/network and others are very specific

  • Some focus on business processes (e.g. SCOR), some on business data (e.g. EDIFACT, ASC X12), nearly none on organizational/governance aspects, others on material or money flows and others combine only some of the aspects (e.g. ARIS)

  • Some do provide key performance indicators for benchmarking your performance against the reference model, but most do not

  • It is unclear how different reference models can be combined and tailored to enable business networks

  • Tools supporting definition, viewing, visualizing, expertise provisioning, publishing or adaptation of these models are not standardized and a wide variety exists

  • Tools supporting monitoring the implementation of reference models in information systems consisting of technology and humans do not really exist

There exist already reference models for business networks, such as EDIFACT, and they are used successfully in practice. However, in order to gain benefit from reference models in a business network, you will need to have an integrated approach addressing the aforementioned issues as I will present in the next section.

Enterprise Architecture Management in Business Networks

Reference models are needed for superior business performance to deal with the increasing complexity of business networks. You will never have a perfect world by using only one reference model. Hence, you will need an enterprise architecture management approach for business networks to efficiently and effectively address the issues of one single reference model by combining several reference models (see next figure). Traditionally, enterprise architecture management focused only on the single enterprise and not business networks, but given the growing complexity of business networks and disrupting societal changes, it is mandatory to consider the business network dimension.


Establishing an enterprise architecture management approach depends on the type of business network as I have explained before. For example, you may have one organization selecting and managing your reference model portfolio and application landscape for the whole business network. You may have also no one responsible, but you need to align and be aware of each other’s portfolio. For instance, you can create a steering board for this. Additionally, you will need to establish key performance indicators and benchmarking processes with respect to the business network’s reference model portfolio.

Once you have your enterprise architecture management approach leveraging combined and tailored reference models, you will have to address the aforementioned dynamics as well as tight integration between business partners in the business network’s information systems. Traditional ERP, CRM and SCM software packages will face difficulties, because even if all partners would use the same systems, there would be a huge variety of configurations to reflect the different internal business processes of members of a business network. Additionally, you will have to manage access and provisioning over the Internet.

Cloud-based solutions address these challenges already partially. They help you to understand how to manage access, governance and provide clearly defined interfaces via the emerging concept of API Management. However, these approaches do not reach far enough. You cannot move dynamically business processes and corresponding applications and data between organizations as a package to integrate it at your business partners’ premise. Furthermore, business processes may change quickly and you want to reuse as well as leverage the change in many different organizations using corresponding applications. This may facilitate a lot of scenarios, such as “bring your own digital business process” in third party logistics. Hence, there is still a need for further technology innovation and research.

Conclusion: Software Containers for “Bring your own Digital Business Process”

We have seen that new complex scenarios in business networks, such as third party logistics, as well as the high competition, tight network integration and dynamics impose new challenges. Instant business network adaptation as well as tight integration between business partners will be a key differentiator between business networks and ultimately decide about their success. Reference models representing industry best practice need to be combined and tailored on the business network level to achieve its future goals. However, no silver bullet exists, so you will also need to enable enterprise architecture management at the business network level. Finally, you need tools to enable dynamic movement of business processes as well as applications between different organizations in a business network. A coherent and reusable approach should be used.

Unfortunately, these tools do not exist at the moment, but there are some first approaches, which you should investigate in this context. Docker can create containers consisting of digital business process artifacts, applications, databases and many more. These containers can be sent over the business network and easily be integrated with containers existing in other organizations. Hence, the vision of instant dynamic business network adaption might not be as far-fetched as we think. The next figure illustrates this idea: The third party logistics provider sends the containers “Packaging” and “Pre-Assembly” to its business partners. These containers consists of applications supporting the corresponding business process. They are executed in the business partners’ clouds and they integrate with the existing business processes and applications there (e.g. the ERP system). Employees of the third party logistics provider use them at the side of the business partner. The containers are executed at the business partner side, because the business process takes anyway place there and thus it makes sense to let it also digitally happen there, before we send a lot of data and information to the network back and forth or having a lack of application integration.



[1] Harland, C.M.: Supply Chain Management: Relationships, Chains and Networks, British Journal of Management, Volume 7, Issue Supplement s1, p . 63-680, 1996.

[2] Franke, Jörn; Widera, Adam; Charoy, François; Hellingrath, Bernd; Ulmer, Cédric: Reference Process Models and Systems for Inter-Organizational Ad-Hoc Coordination – Supply Chain Management in Humanitarian Operations, 8th International Conference on Information Systems for Crisis Response and Management (ISCRAM’2011), Lisbon, Portugal, 8-11 May, 2011.

[3] Becker, Jörg; Schütte, Reinhard: A Reference Model for Retail Enterprise, Reference Modeling for Business Systems Analyses, (eds.) Fettke, Peter; Loos, Peter, pp. 182-205, 2007.

[4] Verwijmeren, Martin: Software component architecture in supply chain management, Computers in Industry, 53, p. 165-178, 2004.

[5] Themistocleous, Marinos; Irani, Zahir; Love, Peter E.D.: Evaluating the integration of supply chain information systems: a case study”, European Journal of Operational Research, 159, p. 393-405, 2004.

Revisiting Risk Management for Business Process Management/Workflow Systems

Risk management and is a very important topic in the world after the financial crisis and dozens of recent natural hazards. I see risk management as a broad concept that does not only apply to the financial domain, but to any process of any organization. Two years ago, I worked briefly on the topic of integrating risk management into information systems. More particularly, on combining risk management and business process management/workflow systems. The goal of this blog entry is to revisit this topic and see the progress by others.

What is risk management?

In order to answer the question what risk management is, we need to define what risk is. There are a variety of definitions related to risks from a business, public safety, military, medical or personal perspective. We are interested here in business risks. ISO 31000 defines risk as the “effect of uncertainty on objectives”. It can be positive or negative.

Although business risks are not only related to risk associated with financial investment products, we assume that the impact of risk can somehow be calculated as well as quantitative probabilities for risks can be given. Most project managers and others know that impact and probability cannot always be provided as numbers. For instance, they may define that the impact of losing customer X because of product feature Y is high with a low probability. Supporting these kinds of scenarios is another problem not addressed in this blog.

Risk can be calculated by the following basic equation:

Impact * Probability = Risk

One example would be that the impact of losing customer X because of product feature Y is 100.000 Euro with a probability of 10%. The risk can be calculated as follows:

100.000 Euro * 10% = 10.000 Euro

Obviously, we can do more sophisticated calculations by using more advanced statistical methods.

Risk management is about identifying, assessing, monitoring and mitigating risks. In order to identify and assess risks you need to talk with stakeholders of business processes (suppliers, customers, employees etc.). Monitoring risks can be done on an automated or manual basis. Mitigating risks is about reducing the impact and/or probability of a negative risks as well as increasing the impact and/or probability of positive risks. Various measures can be used, such as transferring the risk by insuring against it. It is important that risks have owners that ensure that proper risk management is in place for a given risk. Otherwise we may manage risks that do not exist anymore or we may not address current risks.

We should not only consider big risks that are very unlikely, but we should also think about small risks (e.g. wrong data entries). We face many small risks in an enterprise and summing them all up will probably lead to larger risks than a single big one.

What are Business Process Management/Workflow systems?

Business Process Management Systems (BPMS), also known as workflow systems, allow modeling a process composed of (alternative) sequences of (human or automated) activities, their resource needs (mostly human resources) and the data that is processed. Furthermore, they can coordinate the process by keeping track of its execution state, starting new activities/applications, assigning resources to them and providing the required data.

Most of the business applications you use today contain implicitly a business process or business logic. However, if the process is described in a workflow system then it is made explicit and transparent. In addition, it is much easier to monitor, improve or change it.

Why combining them?

Our initial motivation for combining risk management and business process management system was the following:

  • Each business process has risks associated with it
  • Managing these risks more effectively will reduce the impact or probability of negative risks or can increase the impact or probability of positive risks. Thus, more business value is created
  • A workflow system makes a process explicit and this allows (1) easier identification and assessment of risks (2) monitoring and initiating mitigation processes related to risks

Our early approach

A longer description of our approach can be found here. At the time we did research on this topic, not many approaches were known aiming at the integration of risk management and workflow systems. Only few fragmented ones existed addressing mainly modeling of risks in business processes without further functionality such as monitoring and managing risks during process execution controlled by a workflow system. Our approach can thus be seen as one of the first attempts to address this problem.

The blog entry containing our approach raised a lot of questions. Some were related with the integration of existing (SAP) technologies where risks are described and identified. In fact, this is an important topic, because we do not want to have several independent risk databases, possibly with different impact and probabilities for the same risks. Others raised concerns about defining the probabilities, because we sketched several possibilities, but without any answers how to select the correct method for calculating probabilities and impact. This also depends on your enterprise, the methods you use and risk culture. Clearly, normative or well-tested methods by experts would be helpful. I think the area of reference models for various industries could help to address this problem.

Furthermore, the lack of interest by industry research groups, such as Gartner or Forrester has been criticized. This has not changed so much, but at least Gartner sees a need in their report on “Hype Cycle for Business Process Management 2011”, where they describe the integration of meta data repositories for compliance, risk and governance. Nevertheless, integrating risk management and business process management systems is not yet on the radar of the BPM hype cycle by Gartner.

Finally, others criticized that models in general are not always perfect and may be wrong. This is true, but I believe with continuous review and open exchanges between risk experts in various departments of the company this problem can be addressed.

New approaches

Unfortunately, in the last months the situation has not changed much. We could not continue to work on the topic due to new priorities. However, recently, Conforti et al. proposed their approach for integrating risk management and workflow systems. In fact, they describe many ideas we provided in more detail. Interestingly, they were looking for Pareto-optimal solutions, i.e. solutions where no party can increasing its outcome without reducing the outcome of another one. This may not always be beneficial for the goals of the companies, because it only considers individual goals of the stakeholders.

Nevertheless, they describe in another paper how the risk probabilities can be calculated by using real-time sensor information. This seems to address partly some criticism of our approach, namely that models can change based on changes in the real world and this needs to be taken into account in the information systems reasoning on the models.


I believe that the topic is still important and should be explored in more detail. This is why I decided to create this blog. Luckily, there has been at least some progress. I see also further extensions to new approaches for managing dynamic less predictable business processes. For example, the case management process modeling standard by the OMG could address the problem of risk management in this context. Furthermore, we need to think about how we can integrate qualitative risk assessment into the solution and how we keep the important stakeholders as well as risk owners informed.

I am looking forward to your comments!