Architecture and Engineering in Business Engineering

AlignmentIt 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

6 Comments Added

Join Discussion
  1. Alan October 28, 2009 | Reply

    Hi Johan,
    Great points made, but it does seem to indicate that Master Data is the sole domain of complex tools and “big brother” rules – have a look at the link below, I hope you will change your mind and see that what I have done is make it simple for anyone outside IT to use

  2. Johan den Haan October 28, 2009 | Reply

    Hi Alan,
    Thanks for your pointer. You have a nice tool to document business processes. However, what about execution? And if you execute it, what about the other aspects of an IT system (e.g. GUI, data, rules, integration, reporting)?
    My point is that we need executable models covering all system aspect thereby elevating software engineering to business engineering. No need for additional tools, steps, or manual coding.

  3. Keith Duddy October 29, 2009 | Reply

    Hi Johan,
    I always read your blog with interest… you put so much work into each article, and I have found good explanations of many concepts with which I’m familiar, and some understandable introductions to concepts that I didn’t know so well.
    However, I think you are fudging some concepts above. There is no conceptual difference in “generating code” from a model, and writing an interpreter for a model from my point of view. This is an age old tradeoff that has been made in programming language execution ever since we stopped flicking the binary switches on front of the computer console. The problem is one of understanding (and providing execution support for) the concepts that are represented in the model. With a semantically rich modelling language, such as UML, that includes concepts of objects and methods, processes and data, state machines etc, the “model” for the business application can make use of these concepts, and then choose to generate code for some parts (e.g. objects and their modifiers), and interpret other parts (e.g. workflow execution). The other end of the spectrum is language like MOF, EMF, etc where there are small number of concept modelling constructs, and a domain is modelled in terms of these.
    You call the languages supported by Mendix “Business Object DSL”, “Rich Internet Forms DSL”, etc. But this is using the term DSL in a different sense from what most modellers mean. The “D” is for domain, and “Internet Forms” or “Business Objects” are not domains in this sense – “Car Manufacturing” or “Suppy Chain & Logistics” or “Mobile Phone Retail” are the kinds of domains that people mean when talking about DSLs. What you really have is a framework of code that can interpret (or code generate for) a number of generic business IT Languages for expressing aspects of systems, and this is a different space from what a general purpose DSL toolbench offers.

  4. Johan den Haan October 29, 2009 | Reply

    Hi Keith,
    Thanks for your kind words. I’ll try to keep the same level in the future 🙂
    >There is no conceptual difference in “generating code” from a model, and writing an interpreter for a model from my point of view.
    From a technical perspective I totally agree. However, from a user perspective I do see differences. For example, while debugging the resulting software system. If you generate code, you will need to debug that code. Most interpreters give you the opportunity to debug/step through the model. Conceptually your point is still valid… you can accomplish the same way of debugging by generating support for it in the source code. However, with an interpreter you can just switch debug behaviour at runtime, without ‘re-generating’.
    >But this is using the term DSL in a different sense from what most modellers mean.
    The term DSL is mostly used in two different ways: problem domain DSLs vs. solution domain DSLs (see This difference is sometimes also called vertical DSLs vs. horizontal DSLs.
    In general, the problem with DSLs vs GPLs is that there is no clear difference. A language is domain-specific for a certain degree. At what point is the domain small enough to justify the term DSL?
    Anyway, thanks for adding these well-considered thoughts. I think this is useful food-for-thought after reading this article.

  5. Andriy Levytskyy November 7, 2009 | Reply

    Hi Johan,
    I am not familiar with the term Business Engineering, but the goal behind it (bridge the gap between problem and solution) is well recognized in MDA (see MDA Manifesto) and especially in DSM and Domain Driven Development (DDD).
    To me it appears that MDA, DSM, DDD, Business Engineering all agree about the "what", but may differ in "How". Each of their "How" has its merits, which warrant their existence. That’s why I think it is a bit limiting view to focus on the interpretive approach only (even though it is my favorite as well). (To add to your discussion with Keith, I would like to mention that good MDE tools make it possible to debug/step through the model in generative approaches as well – just check MetaEdit+ by MetaCase.)
    As for the "what" part, I cannot agree more with you that we need a more structured and formal way to capture the business domain. It would be great to share ideas on the best ways to capture business. I am more familiar with the DSM and MDA approaches and found the following to work well: First capture the essence of the business through domain engineering and using ER/Class diagrams. Then I would derive Use Cases and requirements models, and depending on the solution domain further refine the initial domain model to create DSLs or abstract architectures.

  6. Johan den Haan November 9, 2009 | Reply

    Hi Andriy,
    Regarding ways to capture the business as a starting point for model-driven approaches: I have recently looked at DEMO. See for an overview of my research focusing on using DEMO to model an organization and using these models as input for a model driven software development approach.

Leave a Reply