Architecture and Engineering in Business Engineering

It has struck me that many discussions about business-IT alignment and enabling the involvement of the business in software development still only talk about solution domain concepts: SOA, WOA, REST, web services, cloud computing, etc.

I think the question should not be what technology to use, but how we can create an IT landscape truly supporting the business part of an organization. This is not a trivial question; because it is questionable whether enterprises can actually maintain a focused strategy long enough to align their core business processes with IT. The current dynamic business environments do not give enterprises that time.

Article highlights

• We can create more business-IT alignment and agility by moving from software engineering to business engineering.
• Business engineering: software built by people who understand the business and who are able to express that knowledge in formal models.
• Necessary elements for business engineering: MDE with model execution and SOBA.
• Overview of a tool supporting business engineering.
• Future developments: integrating engineering models and architecture models.

Business Engineering

Engineering a software application has two different perspectives: the perspective of the function, or what the application is supposed to do, and the perspective of the construction, or how the application is being made. The first perspective is the one of the user, e.g. the driver of a car. The car driver does not need to know how the engine works, he just needs to know how to handle the car in order to travel; he knows everything about where he wants to go to. The second perspective, however, is the one of the engineer, e.g. the car repairman. He needs to know how to construct or reconstruct a broken car engine. This is quite a fundamental distinction that can be used to define architecture, design, and engineering in a formal way as Jan Dietz has done in a scientifical setting.

Most software is made from a constructional perspective. Software engineering as such can be described as creating a low-level model of a software system, expressed in a programming language (e.g. Java, C#, etc.). In essence, a programmer specifies the construction of an application; he describes how the application should work. He is usually doing that on the basis of a "functional" design which describes the what or function of the application. Functional designs, however, are usually not very precise, do not contain formal models, and leave many functional decisions to the programmer.

The idea of business engineering is to have the business in the lead of application development. Instead of creating models that describe how an application should work, we should create precise and formal models that describe the function of an application. These models should describe what the application should do. The construction should follow logically out of these functional models.

The idea of business engineering is not new. OMG’s Model-Driven Architecture (MDA) also describes models focused on the function of a system without specifying technical details. However, the MDA defines that these models should be transformed / refined into lower level models until a model is produced from which code can be generated. The idea of business engineering is to have engines directly executing the high-level models, without any further refinements. So, the model is the solution. Whereas MDA is automating the model transformation process, Business Engineering automates the interpretation of the functional models.

It is important to note that business engineering leads to a change in roles in the software development process. Software engineers have to switch to working on the tools and platforms to enable business engineering, while business solutions are built by so-called business engineers (i.e. non-programmer domain experts). Business engineers are people who understand the business and who are able to express that knowledge in formal models.

Business engineering has the following advantages:

• Due to the use of declarative models (i.e. models as much as possible focused on the function of a system, for example business rule models), business engineers can be involved in the development process.
• No complex transformation from model to code.
• Models and code cannot be out-of-sync.
• Changing an application is just changing the model.
• Understanding the behavior of an application just asks for reading the models (instead of source code).
• Debugging an application means debugging the models (i.e. debugging in terms of business models instead of source code).

Because of these advantages business engineering can bridge the gap between business and IT: applications can be built faster, applications are easier to check for compliance with requirements, and applications are easier to change.

I hope you understand the advantages of business engineering, but I will not be surprised if you think this is just a nice dream which is not possible in practice.

MDE and SOBA, necessary assets for Business Engineering

The first thing we need to enable business engineering is a Model Driven Software Development approach focusing on model interpretation, i.e. directly executing high-level models. To make models both high-level (i.e. no technical details) and directly executable we need Domain-Specific Languages (DSL).

The idea of a DSL is to have a small language with a limited number of concepts for a specific domain. This domain can be a problem domain (e.g. insurance, healthcare, transportation) or a system aspect (e.g. data, presentation, business logic, workflow). If system aspect DSLs can be made high-level enough, they are also usable by non-programmer domain experts. To make them executable we need engines directly executing models expressed in a DSL.

The second necessary asset for business engineering stems from the need for easy to change applications delivering business services. The definition of ‘application’ is rapidly changing nowadays. As the industry is moving from using an application-centric architecture to a Service-Oriented Architecture (SOA), the focus for building functionality is moving to Service-Oriented Business Applications (SOBA). This means that applications are a set of services and components working together in fulfilling a certain business need. An example of this movement is the upcoming Service Component Architecture (SCA) standard.

With SOBAs you are not only flexible in changing the high-level orchestrations, but also the lower level service orchestration within ‘applications’. Business engineering needs SOBAs because it enables to change applications in an easy way. Services can be changed independent from each other, as long as the interface stays the same. Furthermore, we can define a service type for each DSL. In that way the engines executing the DSLs can be fully separated and can make use of different technologies. For example, a Business Rule DSL can be made executable with a Business Rules Engine, publishing decision services. Another example: a Reporting DSL can be made executable with a Report engine, publishing reporting services. In this way we have the same separation of concerns at runtime (with services) as we have at design time (with DSLs).

Summarizing we can say that for enabling business engineering we need an approach to Model-Driven SOA. Model-Driven SOA enables the creation of an IT landscape truly supporting the business part of an organization. Due to the use of a Model-Driven approach based on model interpretation, this landscape can be changed fast enough to catch up with the current dynamic business environments.

Business Engineering in practice

We of course need tools to support business engineering. In general a separation can be made between DSL tools and Model-Driven Software Factories. DSL tools are used to define the needed domain-specific languages, with which a Model-Driven Software Factory can be constructed. A Model-Driven Software Factory is a complete platform consisting of a set of DSLs to model a business solution and the interpreters needed to execute the models.

Mendix is an example of a Model-Driven Software Factory for creating Service-Oriented Business Applications (SOBAs). This factory consists of a Business Modeler, a Business Server (the runtime environment), and a rich web 2.0 client (providing the user interface). With the Business Modeler non-programmer domain experts can model a SOBA. They can make use of the following system aspect DSLs:

• Business Object DSL
• Rich Internet Forms DSL
• Microflow DSL
• Business Rules DSL
• Report DSL
• Services DSL
• Security DSL
• Mapping DSL
• Internationalization DSL

Because each system aspect is covered by its own DSL, these languages can be very simple, and thus easy to learn. Each DSL is at least readable for non-programmer domain experts. Most of them can also be used by business engineers (i.e. non-programmer domain experts) to model parts of the solution they are building.

The modeling environment guards the consistency of all the models. If the models are consistent they can be deployed to the runtime environment (‘one-click-deploy’). No further refinements or transformations are needed and no code is generated. For more details, including an overview of the architecture and how Mendix fits in an existing application landscape, see the whitepaper "Modeling the Agile Enterprise".

Future Developments

This toolset is a huge first step in the direction of business engineering. However, we need to go further. As Peter Bakker stated in his article on Via Nova Architecture: architects and engineers have to work together to understand complex systems. They both have to use models. As shown in this article the (business) engineering part of software development is possible right now. An open future question is what role (business) architects can (and should) play in business engineering. I think architecture models and engineering models should be put in a central repository, thereby enabling all kind of automatic consistency checking between them. For example, a change impact analysis on implementation models when the process documentation changes. Another possibility would be to define architecture principles in formal way, enabling automatic enforcement of these principles on engineering models.

Mendix and Bizzdesign have started the integration between Bizzdesigner and the Mendix Business Modeler, aimed at bridging the gap between business process documentation and business process implementation. The most important advantages of this integration are the possibility of tracing between process documentation and implementation elements and the possibility to get an automatic change impact analysis, i.e. when the process documentation changes the implementation elements affected by the changes are reported.

To finish, some questions for you:

• What do you think of Business Engineering?
• How do you see the role of the architect in Business Engineering?
• How should the architect be supported with tooling?

Photo by dlemieux