1 Introduction

Frequent changes in business environments through disruptive market force also business plans to frequent adjustments of corporate strategic roadmaps. There are no specific patterns that characterize these changes. Currently, business decision making is based on data analytics and support documentation which can lead to a more informed decision making process. The human factor is minimized but not inexistent is such processes. Corporate executives are still required to evaluate and finalize a decision without full knowledge of methodologies, frameworks and best practices [27]. Consequently, models lacking semantics offer limited value to the business.

Informalities introduced in models out of ill-defined decision making processes can lead to informal models and can require training-intensive modelling sessions for modellers to resolve the introduced inconsistencies. As a consequence, the recorded information of models will no longer be valid for the business and will remain unused for future purposes of decision making. “Often, the modellers themselves have disappeared, and any knowledge that wasn’t captured in the specialised models is inaccessible, forgotten, or written off” [9]. Knowledge reuse is one of the key stepping stones for every organization before achieving higher efficiencies in its decision making process.

The model driven architecture (MDA) community has paved the roadmap towards a higher formality of produced models for the software development community. The four abstraction layers that characterize MDA are the computational independent model (CIM), Platform Independent Model (PIM), Platform Specific Model (PSM) and generated source code e.g., Java. Model transformation can occur between these layers to accommodate higher model formality. These transformations can be horizontal or vertical. A meta-model is actually a model which explains the associated semantics of its corresponding model (meta-model is data about data). For example, a model describing source code is positioned at PIM level and therefore is the metamodel of code. A model describing a metamodel at PSM level is known as a meta-metamodel. Each higher layer keeps only the level specific model details to help make it as reusable as possible in such a way that it can be actually applied to different domains such as project management and service management. No severe restrictions apply, because in an MDA transformation any model can potentially participate if it has a corresponding meta-model.

The use of MDA concepts and applications to the business domain is part of the authors’ attempts to solve business problems with a model-driven approach that is similar to the practices used by the MDA community to solve software engineering problems. The authors propose a new framework called model driven business engineering (MDBE) which attempts to solve business problems from an MDA-led viewpoint. Contributions of the MDA community stress several benefits that can be established. Some of these include higher productivity and associated reliability via automated generation of business related documentation. Other contributions are reduced time-to-market solution, richer model semantics and models with higher formality [5, 6, 8, 10, 20, 22, 25].

The proposed framework can be capable of generating decisions, business documents (such as risk analysis charts) and activities (perform a list of tasks, e.g., automatically place an order) defined as corporate solutions [29]. The aim of MDBE can articulate a solution generation tool which provides reusable artefacts, metamodels or transformations to modellers in order to produce a more accurate business solution for corporate executives. In effect, MDBE can also become a valuable tool in maintaining expected productivity levels for organisations with high employee attrition levels whereby modelled business templates can readily guide newcomers to get accustomed with activities of the various corporate teams.

MDBE aims to gain a similar insight to MDA in regard to the ability to make changes at a high abstraction layer, for instance, a change of an environment factor could affect some Business Artefact. MDBE can implement this through a series of transformation executions with minimal human intervention.

The paper is organised with Sect. 2 providing a model definition in the context of MDBE. Moreover, Sect. 3 covers on aspects of model driven architecture whereas Sect. 4 extrapolates on the MDBE layers. Research conclusions are discussed in Sect. 5 and future work in Sect. 6.

2 Modelling issues

As an approach, model driven architecture (MDA) is driven by developing software which has been developed by OMG [23]. The primary approach behind the model driven architecture is the distinction between three abstraction layers of models. The processes and requirements of business of the CIM layer are mapped to PIMs. Then they transposed to platform independent models (PIM) and after that they are transformed into platform specific models (PSM) which are result into real development code such as Java, etc. “MDA is potentially advantageous because it shifts complexity away from developers and into the tool chain” [14].

The software engineering community can indeed gain advantages more from the MDA discipline compared to other disciplines [7]. In a similar pattern, business engineering could potentially benefit from models since MDBE uses MDA as its model transformation engine. The current problem with models as pointed out by Anneke [1] is that the majority of models describe what is required at a given-time at a very specific layer.

3 Model driven architecture

It is essential to understand the methods the MDA community used to solve modelling issues presented in the previous section. When there is human intervention in the production of models it means that changes made at a specific abstraction layer e.g., PSM, can be carried over to other layers as well e.g., PIM. If there is no track of these changes in other layers then inconsistencies are introduced between modeling layers. MDA transformation tools maintain the integrity of models in all layers thus minimizing errors caused by human intervention. MDA has potential advantages because it removes complexity away from developers and into the tool chain and, hence, the PIM-to-PSM transformation [28]. MDA uses the unified modelling language (UML), OMG’s main modelling standard. Other tools include but are not limited to. UML-RSDS [15], ATL, QVT-R, GrGen.NET, Epsilon [14], Kermeta/A comparative analysis of these transformation tools is available in [16].

4 Model driven business engineering

MDBE attempts to address and formalise real business problems by operating at a higher level than model driven engineering (MDE), closer to model business engineering (MBE) and helps project and service managers and other stakeholders to generate daily corporate documentation. There exists evidence of UML activity diagrams to BPMN 2.0 in e-Government systems [11, 13] and vice versa [17]. On the contrary, empirical research in the areas of project and service management frameworks for PRINCE2® and ITIL® is inexistent.

Model driven business engineering (MDBE) can be characterised as ‘a structured approach to automated generation of modelled artefacts in the context of business disciplines, that can form the basis of decisions, business documents and/or business activities.’

MDBE reaches its end result through three abstraction or conceptual layers; environment model, project specific model and business solution. The end result can be decisions and/or documentation and/or a set of actions that may or may not be automatically performed by the system. MDBE encourages efficient use of business models in the business development process and it supports reuse of best practices when creating families of business solutions. MDBE can become a way to organise and manage business environments supported by tools and services for both, model definition and facilitation of transformations between different model types.

The environment or project-independent model (EM) is the first MDBE layer, see Fig. 1, which mainly signifies the environmental boundaries and constraints that provide a formal view of the business environment in which a solution is to be modelled. The environment model also provides ground so that references can be made to business independent frameworks, ISO standards, methodologies, techniques, and a pool of best practices. The project specific model (PSM) makes sure that the corporate solution is produced. Lastly, the real document data would be held in the business solution (BS).

Fig. 1
figure 1

Model driven business engineering

Full size image

Information such as organisation budget belongs to the environment model. The reason for capturing such information even if it appears not to have a direct link with the project is because a reduction to the organisation budget may cause a decrease to our project, if it is not mission-critical. Information such as business policies like no employee is allowed to work more than 8 h, are also important because rules and regulations are placed in the specific environment in which the project or projects are being executed. The corporate solutions includes, PRINCE2®orITIL® produced documentation, processes, roles or even functions which signify an overall modelled business solution, see Fig. 1.

The definition of a Domain is as follows: A Business Discipline, Customer, Company, Contact, Location. In this light, Domain Engineering such as product line engineering, is the whole process of reusing domain knowledge in the production of new software systems [26]. The applicability of MDBE can embrace a number of industry domains such as decision making for procurement processes [19] and business process outsourcing.

MDBE provides a structured way for approaching a business solution and architects utilising the framework should go through the model transformation process of all of its layers. Committed changes at each layer should propagate to the lower abstraction layers. The following sections describe the various MDBE layers.

4.1 Environment model

“Organizational dynamics domain is primarily organizational behavior and development”. Information captured by environment models cannot be affected by the project but affects the project or business solution [21]. As a result organisational teams might not have control over these influential environment factors or models.

One aspect that MDBE attempts to address regards business environments in multinational companies. For example, cross-cultural concerns and issues have the capacity to affect planned or even unplanned changes and schedules in project management frameworks. It is challenging to attain the same level of team performance using similar project frameworks for projects in different global regions. Even if change is one perspective of MDBE, as far as the environment layer is considered, another one might be adaptation or resistance. Thus, the environment model can be defined as:

The MDBE layer where the data captured is in regard to the business domain specific information acting independently of organisational dynamics.

The term ‘business environment’ is defined, but not limited to as the set of factors like political, economic, social and technological forces that influence the behaviour of a business; nevertheless their impact can potentially have either positive or negative meaning. Other factors might be for example the cultural and social business environment, in terms of team orientation, innovation, risk taking, overall management, and manpower.

In case the ‘business cultural environment’ is taken into account, this can be described by basic values, behaviours and preferences which have an effect on stakeholder’s decisions. In many other cases the demographic environment information like for e.g., a country or region, is related to the study of human populations in terms of different attributes like for example size, location, age, sex, race, work-status, and other information. In light of this, cultural differences among different nationalities were rather obvious, when employees of the same organisation were spread over many working locations [4].

In this context MDBE focuses on the provision of business solutions with increased accuracy based on data provided from different sources of the same organisation located at different places in the world. In addition, the ‘economic environment’ might consist of different factors such as wage levels, pricing strategy and possible financial risks.

To this frame, work interaction with stakeholders, for example: colleagues, customers, providers or clients from various and different cultural backgrounds, within different religions, values and norms can frequently lead to associated misunderstandings and problems.

Often, managers’ business behaviour can be directly associated to the country’s culture. It was indicated [24] that business behaviour can be explained in terms of the following ways: “The first has to do with overt actions and second by the collection of the group of ethical attitudes and values”. To give another example, in project management each project, depending on a plethora of factors may require different and complex changes. These changes may be seen in various business aspects like: corporate or individual culture, leadership and conflict management, decision making, norms and directives and effectively in a more generic way of executing and managing projects [3]. Such kind of requirements can be identified and modeled further under the environment model layer.

Taking into account a more structured modeling approach regarding MDBE’s environment model factors analysis; the integration with an existing model, CRAM (change risk assessment model) is proposed.

For the analysis of factors which can influence a business environment, it is of great importance, the determination of the impact that each factor or attribute posses. Consequently, the next steps are related to addressing complex situations, identification of specific criteria and deployment of measurement tools or techniques [2].

The key idea behind CRAM and MDBE integration is that the combined framework will be capable of generating decisions, business documents (such as risk analysis charts) and activities (perform a list of tasks, e.g., automatically place an order) defined as business solutions. Nevertheless, the existence of their corresponding meta-models is a prerequisite.

4.1.1 Change risk assessment model

CRAM as an innovative modelling approach, attempts to take into consideration several business environment change risk factors which have the capacity to influence project success or failure. These factors are modelled (assessed numerically) foresee to close the gap (missing from current literature) of effective change risk management. This gives the power to project managers or other stakeholders to make proper decisions whether to take on or abandon respective project changes. At minimum, they can have a numerical indication and prioritisation of change risks.

One of the CRAM’s benefits is that it is expected to be regarded as a global change(s) risk assessment model and method. Such a modeling approach, can find significant applicability regardless of project size, type or organization capacity. Due to its great modeling flexibility and design, factors can be tailored to specific requirements, taking into account significant environmental change risk factors.

Because not all projects are the same and also not all risks can be identified, CRAM provides the flexibility and capability to the user to add or delete risk attributes accordingly as required. In other words, CRAM is a fully dynamic model that can be changed on demand and moreover, can be implemented in various business sectors. Among other benefits, CRAM can be easily integrated with other project management frameworks such as PMBOK® and PRINCE2®.

Overall, CRAM aims to contribute significantly to the missing formality approach of business models especially in the change risk assessment area. CRAM, as a comprehensive modelling structure is based both quantitative and qualitative criteria analysis in a decision-making process [2]. Even though, the prototypes’ modeling approach was to assesses change risk factors this can be extended to assessing business environment factors.

4.1.2 CRAM processes

Change risk assessment model (CRAM) is consisted of three interrelated processes as depicted in Fig. 2. The aim of CRAM’s processes is to accomplish specific risk objectives (identification, assessment, monitoring and control) which are applied to projects or programs or even to portfolios. Nevertheless, to avoid potential terminology conflict, the model for this paper will be discussed at project level. At a greater extend the model can be applied to business environments with a view of associated risks’ facilitation and control.

Fig. 2
figure 2

CRAM processes

Full size image

More specifically, CRAM attempts to take into consideration various business environment factors which influence the success or failure of the projects’ objectives. Figure 3 shows a more detailed representation of the model (Tree Hierarchy) in terms of the root, parent and child nodes. The original model consists of sixty-one (61) attributes.

Fig. 3
figure 3

Change risk hierarchy tree [2]

Full size image
4.1.2.1 Risk identification

Practically risks can be identified via various methods but, the difficult part in not only to identify but also, to monitor and control them. The aim of Risk Identification process is to identify the threats (negative risks) and opportunities (positive risks). This is not so easy, as there exists an associated uncertainty not only in terms of project estimates but also in terms of assumptions. Specifically, assumptions may affect severely the projects’ objectives and consequently deliverables.

However, irrespective of risk categorization and project complexity, the proposed tools and techniques suggested by CRAM to identify change risks include (but not limited to) the following:

  • SWOT analysis

  • Change/risk surveys

  • RACI diagrams

  • PESTEL analysis

  • Risk breakdown structure (RBS)

  • Interviews

  • Brainstorming sessions

Because of the iterative nature of the processes, potential risks and required actions in terms of reassessment, change responses can be identified throughout projects’ lifecycle. Nevertheless, as a rule of thumb the identification and assessment is better to be performed the soonest the possible. The more risks can be identified during the initiation phase of the project, the better outcome can be expected. Information regarding risks follows as increasing pace in relation to project time. One of the golden rules regarding effective risk management is that: risk(s) cannot be managed if not firstly not identified (Table 1).

Table 1 Indicative project risk categories [2]
Full size table

Depending on the projects’ aim and scope and in relation to the deliverables the more risks are identified and controlled (the earlier the possible) the higher the probability for project success.

Changes and associated risks handling is not static, as it can occur throughout the projects’ life cycle. CRAM is capable enough for the associated identification of internal or external change management dynamics. Such dynamics can be coupled together with contemporary project management frameworks, eliciting also risk cause-and-effect relationships. To this extent, stakeholders can describe problematic situation, assess or reassess the complexity and structure a hierarchy of attributes [3].

4.1.2.2 Risk assessment

Risk assessment as a process refers to risk estimation and evaluation of change risks. Actually, the determination is based on quantitative and qualitative risk estimates of a defined situation (threat or opportunity). However, when change management and risk management are integrated, risk consequences and impacts can be minimised significantly. Since risks can be estimated at the planning stage of a project, in most of the cases there is time for the development of a risk mitigation plan (if not in place earlier) and take all necessary corrective or preventive actions [2, 12].

Quantitative methodologies which are based on probabilistic approaches, carry less ambiguity and imprecision. Effectively, the bias is lesser as the accuracy on results is increased. Such approaches interpret results more formally compared to narrative descriptions or qualitative measurements. On the other hand, qualitative risk approaches (non mathematic) and analysis focuses on the prioritisation or earlier identified risks. This for example, is accomplished with the use of rating scales. Risks are scored based on the probability of occurrence and associated impact on project objectives. Crucial for such kind of assessments is that risks might or might not occur. Nevertheless, the risks’ assessment should be followed strictly for all risks, irrespective if they will occur or not.

Estimation facilitates project risks in regards to the probability of occurrence and impact. In effect, stakeholders can have a clearer picture regarding which risks are more important or urgent than others.

On the other hand, Evaluation assesses the overall effect of all identified risks aggregated together. Specific risks, like for example financial risks, require proper evaluation which can be accomplished only in terms of a numerical approach.

Some of the proposed risk assessment tools and techniques are the following:

  • Probability/impact/proximity assessments

  • Simulations

  • AHP (analytic hierarchy process)

  • Risk maps

  • Bayesian probability and statistics

  • Decision trees

  • Sensitivity analysis

Evaluation activities’ results can be analyzed further by a change manger or other authorized stakeholder by asking questions such as the following:

  • Which is the implementation rate of the non-standard changes?

  • In what level, did the approved changes meet the project’s scope?

  • Any anticipated problems during the implementation of the process which could lead to overall optimization?

  • Does the process result complies with stakeholders’ expectations and conforms to associated requirements?

  • In case of unplanned changes, what were the associated risks?

  • During implementation phase, were projects’ constraints exceeded?

  • Were the detailed results documented in the change risk log/register for future reference?

CRAM uses a change risk survey as a tool extensively, to document and weight the impact of risks. Since there is no risk-free project, at the same time there can be no model that can accommodate the needs of all cases. However, the first step is to develop a conceptual model of risk/change management (tree diagram) and then with the use of quantitative/qualitative analysis, assess the respective risks. CRAM incorporates respondents’ judgments from various sectors in a rational and structured way [3].

4.1.2.3 Risk monitoring and control

The risk monitoring and control as a process focuses specifically on the identification, analysis, planning and tracking of new risks, constant and periodic review of initially identified risks, monitoring and control of existing, secondary and residual ones. Moreover, the process is concerned also with the necessary review of proper risk responses implementation while evaluating their overall effectiveness.

Risk monitoring and control can be implemented with the means of a variety of methods and techniques, like for example:

  • Risk reassessment

  • Variance analysis

  • Trend analysis

  • Risk auditing (internal or external)

  • Technical performance measurements

  • Reserve analysis

As explained earlier, risk processes are iterative in nature. This is because as the project progresses more information is available and the environment factors are likely to change.

Further to the described CRAM’s processes above, organizations frequently seek for experts’ advice and help. For example, an expert can be either an individual (project, change manager, consultant) or a group of people (Project Committee, Change Board) with the authority to influence and advice based on the results’ analysis.

CRAM is not actually in favour of any specific tool or technique for the described risks processes; as it is regarded a structured approach for facilitating change risks effectively and at a greater extent prioritizing factors and evaluating business environments.

Even if no specific project management framework is adopted, CRAM has exactly the same capacity concerning change risk identification, assessment and monitoring and control processes. Hence, expert’s judgment is an ‘advice guide’ that authorized stakeholders may use or propose to use for managing changes and consequently the success of the project [3].

Besides expert’s judgment on testing and reviewing purposes, the use of case studies can help to extend experience, and compare what is known through earlier research. A database of case studies can be created to assist to the overall contextual analysis. Contextual analysis, can enable stakeholders to achieve the desired outcome; for example, completion of activity within budget and on time. Moreover, goal clarity and performance measurement in relation to resources coordination can minimize uncertainty and in effect risks [3].

4.2 Project specific model

A model layer dedicated to the definition of the metamodel of the business solution, see Sect. 4.3, can be called project specific model. The definition provided can be similar to [20] but project specific for this MDBE layer.

Recorded project information relevant and meaningful towards the facilitation of real world business solutions.

The modeler has the ability to select a well established framework-specific model at the PSM layer. Results’ accuracy is heavily depends on the framework selection.

PSM model describes the classes and attributes of the real life business solution and activities. For the scenario described the generated business solution can be a ‘Yes’ or a ‘No’.

4.3 Business solution

A model layer dedicated to the definition of the model of the business solution, can be called Business Solution. The definition provided can be similar to [20] but project specific for this MDBE layer.

The MDBE layer that presents the product of the framework, such as business documents and actions.

The business solution layer, contains the produced business documents. Such kind of outputs can be: business plans, progress reports, status reports, risk analysis documents, time tables, schedules. Overall, more artifacts that can be used for both day to day operation or strategic level information. The ability of MDBE to auto-generate all these documents from live data makes it capable to providing an updated status of the business or project on demand.

Before MDBE can generate these static documents it requires their corresponding meta-models. For instance, there is evidence that the change management process regarding project management can be governed by model generations in UML-RSDS [19].

The generation of sophisticated business solutions in an automated manner is the main aim of the MDBE framework. While it is understood that limitations of the current MDA tools may limit the full capabilities of the proposed MDBE framework, it is the belief of the authors that the benefits of this approach in terms of productivity, accuracy and speed will act as driving force for the MDA community to develop such tools.

The three MDBE layers environment model, project specific model and business solution were defined. However, a closer examination of MDBE in comparison to MDA can form a concrete distinction between the two.

5 Conclusions

The development of a unified method to succeed on the marriage of MDA and domain specific modeling can result in a particularly challenging task. This work proposes the utilisation of a renewed approach towards MBE; model driven business engineering (MDBE) that will be part of a structured facilitation to business models and contribute significantly to increased formality and clarity. The key idea behind MDBE is that it uses models to capture both static and dynamic aspects of the business and MDA transformations to transform business models to other business models and business solutions.

The MDBE proposal includes three layers; the environment that includes models that should signify business oriented environments by taking into account economic stability, socio-cultural or cross-cultural business aspects; the project specific models which involves models of the selected framework that has been chosen to offer the specific business solution and the business solution models, that have the capacity to constitute modelled decisions and formal management guidance documentation.

Project management frameworks in the industry, are mainly based on informal models with reduced clarity, inconsistencies, ambiguous guidance to the managers. Passing from one model to the other is mainly a manual process and can be vulnerable to human errors.

It is therefore clear, that an advantage of MDBE is that it can accommodate any business framework under its abstraction layers. MDA transformations can be utilised to generate models from other business models. In fact, MDBE can be implemented using existing MDA tools hence eliminating the need to build and maintain MDBE specific tools.

MDBE captures actual business models so that the end users need no additional training. The main benefits of MDBE include automation, integration, accuracy, performance and agility in a cost effective but outside the scope of e.g., a project manner. It is the authors’ belief that MDBE will contribute significantly to the missing formality of business models.

6 Future work

Extended research in the area of MDBE should be based on the already established scope of research carried within the MDA community and Model Driven Development. Particular focus should be given in the utilization of OMG published software and systems process engineering meta-model specification (SPEM) to achieve transformations between business-oriented BPMN 2.0 models and model driven development (MDD) models. In terms of future work, other practices outside the MDD practice and provide models which indicate the generation of a Business Requirements Document [18].

The MDA, service management, project management, and business process management communities are strongly encouraging business acumen in the everyday life of modelers and not only. Nevertheless, authors believe that building on the existing knowledge (both research communities), MDBE can form the basis of a different approach, applicable not only to corporate core competencies of software development, service management and IT Project Management but also to business domains operating outside software development.