BPM.com

Executable Architecture of Software-Defined Enterprises

This article describes a machine-executable (further just executable) architecture of software-defined enterprises. The architecture is based on the fundamental model of activity thus enabling the creation of architectures of various enterprises, and the management of an enterprise or a network of enterprises as a system.

A list of advantages and drawbacks of the executable architecture is given, and limitations in its use and examples of its realisation are discussed.

INTRODUCTION

In recent years, despite significant progress in the IT-architectures of enterprises (use of mobile devices, social networking, blockchain technology 1, etc.), the "zoos" of IT-solutions are still present; the development of IT-solutions does not keep pace with the changing business architectures and the total cost of ownership of IT-systems for enterprises is high. These problems cannot be solved unless we change the approach to the design and use of business architecture.

Good modern practices for the development of enterprise management systems position the business architecture 2 as the basis for determining the IT-architecture. However, historically, business architectures use their own models while IT-architectures and IT-solutions use completely different models, and the transformation of some models into others is carried out manually. It is quite clear that this is a dead-end approach that will never be able to solve the above-mentioned problems.

The approach presented in this article is based on a model which describes enterprise activities and their outcomes, and which can be used directly in both business architectures and IT-solutions.

DESCRIPTIVE ARCHITECTURE OF AN ENTERPRISE

The architecture of an enterprise, as a socio-technical system, consists of its business architecture and IT-architecture. In brief, it is possible to say that a business architecture is an architecture viewpoint of an enterprise as a social system which creates value (products and / or services) for achieving one or more specific purposes. An IT-architecture is an architecture viewpoint of an enterprise as a technical system, which IT-solutions, practices and technologies, as well as various equipment, used for the collection, processing and presentation of information in digital form 3. To implement an Enterprise Management System (EMS), firstly the business architecture is designed, secondly the IT-architecture is derived from the business architecture and thirdly existing or new IT-solutions are provided.

In the initial stage of EMS implementation no problems arise – an armada of IT-analysts manually transforms some models of the business architecture into some models of the IT-architecture and IT-solutions. Problems arise when, under pressure of external and internal factors, it is necessary to change the business architecture of an enterprise (e.g. its organisational structure, functional structure, process diagrams, etc.). It happens frequently that an EMS that has not yet been deployed has to be changed because it does not meet the realities of the business architecture.

Our experience shows that the natural acceleration in the rate of change in business architecture results in a considerable and, sometimes, unavoidable gap between the business architecture, the (lagging) IT-architecture, the IT-solutions and the EMS. This happens for the following reason: today the tools for constructing business architecture and those for constructing IT-solutions are actually independent both on the level of models and on the level of model repositories.

EXECUTABLE ARCHITECTURE OF AN ENTERPRISE

An executable (actually, machine-executable) architecture of an enterprise is an architecture that can be holistically changed to reflect modifications within and beyond the enterprise 4. Executable architectures use a fundamental model of activity 5 in the tools for constructing the enterprise architecture and in the IT-solutions which automate the enterprise activities.

This means that IT-solutions for human resources management shall be able:

  • to define and change an organigramme;
  • to assign employers to divisions;
  • to define performance indicators for various divisions,
  • etc.

IT-solutions for process management should be able:

  • to define functional structure of the enterprise;
  • to define process diagrams;
  • to interact with external and internal services,
  • etc.

IT-solutions for project management should be able to use:

  • IT-solutions for process management;
  • IT-solutions for human resource management;
  • IT-solutions for procurement management,
  • etc.

Thus, an executable enterprise architecture has the following characteristics.

  • The business architecture and the EMS use a fundamental model of activity 5.
  • The separation between the tools for automating the enterprise architecture and the IT-solutions blurs since we are moving to common tools for the modelling of the business and the management of the business by means of its model.
  • A fundamental model of activity creates a unified data architecture, i.e. a scheme of tables and relationships of the unified database.

Executable enterprise architecture potentially allows an EMS to be built by creating visual primitives, which reduces considerably the amount of programming in IT-solutions. In the near future, it will enable an EMS to be created with minimal efforts in programming and with maximum use of its business architecture.

Business architecture of a software-defined enterprise

In 7 it was shown that an executable enterprise architecture essentially leads to a software-defined enterprise. The key features of the business architecture of a software-defined enterprise are the following.

  • The business architecture defines several model which define an enterprise.
  • It provides relevant information to the top-management and other stakeholders about the current and future state of the enterprise.
  • Microservices to automate various functions can be easily added, shared and re-used.
  • As soon as data are captured, they can be accessed from anywhere in the EMS, and from any level of control.

The business architecture of any software-defined enterprise is implemented within a framework (see fig. 1) which is based on the fundamental model of activity 5.

Figure 1
Fig. 1 Framework for implementing executable business architectures.

One of the conclusions of the fundamental model of activity is a well-known statement that any activity can be presented and managed as a process 6.

In our case, an activity is a chain of actions (elementary processes) which are interconnected by commitments. In contrast to the traditional understanding of a process, in which an activity is connected by inputs and outputs, we use commitments. Commitments are plans to deliver certain objects (performance outcomes) from one elementary process to another. Our commitments are very similar to smart contracts 7. This means that with the framework it is possible to build both traditional (functional, project, process and matrix management) and decentralised enterprises 8.

Each object of a commitment may have a complex structure, a hierarchy and a life cycle. Higher levels of the fundamental model (tasks, projects, business domains) are essentially ways of grouping some elementary processes.

IT-architecture of a software-defined enterprise

Traditionally the IT-architecture of an enterprise contains the following elements:

  • a data architecture;
  • a IT-solutions architecture;
  • a technical architecture.

Data architecture

As mentioned above, the data architecture of an EMS for software-defined enterprises is the same for different types of organisation. Similar to a framework, it is universal.

It should be noted that during practical use over 15 years of the approach described, data architecture has not changed.

IT-solutions architecture

So far, a microservice architecture is the best option to create, deploy, and use IT-solutions for the EMS for a software-defined enterprise.

A microservice architecture is a logical evolution of the traditional service architecture to decrease the deployment size of services. A microservice is understood as an IT-solution designed a) to automate a simple process (function), b) to operate in its own computing process and c) to be deployable autonomously 3. Our experience shows that the vast majority of microservices can be developed by one programmer in one day.

Typically, a microservice automates one or more related functions. Each copy of a microservice operates in its individual copy of a specialised container, which provides some adapters for microservices and their unified management.

The microservice functioning within this specialised container is controlled by several parameters, which can be static or dynamic. Static parameters are set at the time of registration of a microservice and the corresponding functions. Dynamic parameter values are set in the process, in actions and cases prior to the execution of a function which is automated by the microservice.

Microservices are located in a single management environment; they share messages (which can carry various objects) and "talk" the same language. Essentially, we create a multi-agent environment, where microservices are intelligent agents 9. Other microservices can be coordinators in this environment.

Technical architecture

The technical architecture of the EMS for a software-defined enterprise is actually an IT-platform which can be placed in the cloud, and has:

  • an Application Platform as a Service (APaaS) model;
  • an ability to build a network of enterprises through the use of the same framework;
  • libraries of microservices which can be deployed on different servers in the cloud and in different clouds;
  • the convenience of using a common database for the network of enterprises.

FEATURES OF THE APPROACH

The architecture of a software-defined enterprise is not the result of evolution of an executable architecture, but the result of using a systematic approach to constructing a common model of a network of enterprises (including business-to-business, business-to-customer and business-to-social audiences) to manage them together as a system.

There is no longer any gap between the business architecture, the IT-architecture, the IT-solutions and the EMS – there is a Corporate Unified Business Execution (CUBE) platform 10, and its outcomes are the goods and services of the company, the results of management activities (tasks, plans, projects, decisions taken, etc.), new elements of the architecture itself, etc. This platform improves itself in accordance with changes within and beyond the enterprise.

Certain conditions (actually, current limitations) must be met in order to make a software-defined enterprise work.

  • All actions performed by people and machines must be performed or recorded in a single IT-system.
  • To implement a library of functional services it is necessary to use more than one software development technology. For example, for low-frequency processes web technologies can be effectively used, while for high-frequency processes it is more efficient to use local servers.
  • It is ineffective to execute certain types of activity as a chain of elementary actions and to automate them by functional microservices. Such activities will need to be automated by monolithic IT-solutions.

CONCLUSION

The platform is successfully used in several organisation for enterprise-wide automation.11

Experience with several real projects has shown that the fundamental model of activity is universal. This allows to build a framework for modelling of the business architecture of any enterprise and execute those models in a single IT-platform. Thus the whole enterprise can be defined in software.

REFERENCES

2http://www.businessstudio.ru/conference/2014 A. Samarin “Business architecture from the enterprise architect point of view”, Conference “Business architecture design 2014”, 20-21 November 2014, Moscow

4O. Zakharchuk “An approach for design of an architecture of a real-time enterprise as executable architecture”, Conference “Enterprise Engineering and Knowledge Management”, 21-24 April 2015, Moscow

5O. Zakharchuk “A fundamental model for description of socio-technical systems”, Conference “Active systems theory”17-19 November 2014, Moscow

6ISO 9001:2008 Quality management systems – Requirements

9O. Zakharchuk. “A new approach for automation of management of multi-agent systems” Conference “High technologies in industry and economics” 24-26 May 2012, St. Petersburg.

All URLs given were valid on 2016-09-30)

Oleg Zaharchuk
Author: Oleg Zaharchuk

He worked in aerospace industry as a chief engineer.. Since 1998, he is the chief architect of information management systems for knowledge-based projects and systems.

 

Dr Alexander Samarin
Author: Dr Alexander SamarinWebsite: http://www.improving-BPM-systems.com
Independent Consultant
Dr Alexander Samarin is a seasoned and successful IT professional with more than 35 years experience in the provisioning of IT services. In recent years, he has specialized in the architecting and delivery of enterprise solutions utilizing BPM, SOA, ECM, EA and IT governance. He is the author of the recently published book Improving Enterprise Business Process Management Systems. Since August 2013, Dr Samarin works as an independent consultant.

blog comments powered by Disqus