El modelo de Educación deportiva (Sport Education)

The canonical BO model is central for the orchestration of Logistics Mall products (apps) by using business process models, designed and deployed by business people (with minimal IT support). The mechanism allows phase inversion, since it is based on pre-implementations of two kinds of modules:

• Behaviour modules: Activities for offered Logistics Mall products using BO-

based interfaces, as described in Sect. 3.3

• Data modules: standardized product-independent BOs, as described in Sects.3.2

and 2.2

3.4.1 Phase Inversion

Most BPM suites have different tools for process modelling by domain experts (phase 1 in Fig.19, modelling a business process using activitiesA1,A2, etc.) and for the later implementation of these process models by IT personal (phase 2, implementing eachAiby some implementationIi, e.g. by a service call). However, in the Logistics Mall we deploy and execute modelled business processes merely by a click of a button, not involving IT knowledge or IT personal.

This is only possible, if we model with already implemented building blocks with standard interfaces using standardized data formats, since implementation after modelling should be minimized. In this case, we have a phase inversion, also depicted by Fig.19: the application or service provider (i.e. the provider ofI1, I2, etc.) not only provides normal metadata, but also process model-related metadata for his offer (phase 1). This serves as implementations of activities used in process models, since from this metadata, activity descriptions in BPMN 2.0 XML can be generated. Process modelling and modifications of process models are then thenext steps. They have no further influence on activity implementation. The same activity implementation can be used in different process models of the same or of different tenants, and in any new versions of these process models as well. The modelled process can be changed and is always directly executable, since it uses pre- implemented building blocks using standardized pre-implemented data models in its interfaces.

This principle is sometimes called“What You Can Model Is What You Exe- cute”in analogy to the WYSIWYG principle of text editors. Here the wordCanis important, since of course this modelling approach has some restrictions, in analogy to Lego©construction sets.

BPMN 2.0 optimally supports this idea, since it uses the same notation for process modelling and for process model deployment and execution. The latter has additional attributes set in its standardized exchange format BPMN 2.0 XML. Here, the task description with all implementation-relevant attributes of the process-rel- evant service metadata is inserted for the modelled tasks.

Moreover, the idea is also practical in the context of the Logistics Mall, since the scope of its process models is limited to the logistics domain, limited in complexity (if complex logic is seen in the applications) and even stronger limited to only orchestrate concrete applications and services offered via the Logistics Mall or made accessible to the Logistics Mall. Basic services (such as a mail service) will be offered free, to get a critical mass of building blocks. In [30] it is described how top-down modelling can be achieved.

Nicholas Carr [31] wrote “IT Doesn’t Matter”: companies cannot achieve competitive advantage only by IT, since IT is no limited resource and other com- panies may use similar IT (but perhaps not SMEs due to the cost factor of IT). Such benefits only arise because a company does something better than others, con- cerning their business strategies. The approach presented here refutes this argument, since companies may map their respective business peculiarities of various departments directly to IT flexibly and quickly. Any IT, which flexibly allows realizing and changing core business strategies, does matter.

3.4.2 BO Support for Phase Inversion

The logistics business object model BO4L follows the same principle in its two views. There is an abstract domain view defined by UML diagrams, which hides the complex details of the underlying OAGIS Logistics Overlay. The abstract model was constructed based on the technical standard (again some kind of phase inversion) by several logistics experts of Fraunhofer IML and in conjunction with other Leading-Edge Cluster logistics projects, to assert both the refinement relation of the two models and at the same time the understandability by domain experts.

While the technical model is in English only, both the domain model and the application or service metadata and process metadata are multilingual and com- mented (descriptions can be displayed in the process modeller in a selected lan- guage). The domain views are only used during process modelling or service provision, while the technical models are used at runtime.

We call this the double barbell principle [30], since for both, behaviour (the process model) as well as data structure (the business objects), the corresponding domain view and technical views are closely related in advance like a barbell (compare Fig.20). The technical views cannot be constructed as a later refinement (of arbitrary BOs or activities), since IT personal should not be involved. Instead, the barbells are constructed only once by the providers of applications (and the BO

model governance team) and then reused in any process models. The standard BO model is important to avoid complex data mappings, as the standard activity model is to avoid complex implementation. Both are done only once, not for any new process model or model changes. This is especially important in a Cloud envi- ronment, since Web interfaces for the implementation tasks are difficult to develop. Compared to Fig.1in Sect.2.1the GUIs of IT applications or apps are replaced by activities, which may be manual activities implemented by the GUIs or auto- matic activities implemented by the IT systems or apps.

3.4.3 Putting Everything Together

Figure21depicts the resulting architecture with all gap reductions: The upper part is business: process models are used to describe business processes handling business data, indicated by dashed lines in process models. Data flow in process models can be specified, but in principle is bus-like—every BO produced previ- ously in the running process can be accessed (from the process context). The process models together with a common data model, the Logistics BO model, bridge possible business-business gaps, e.g. between cooperating partners.

The bottom part is IT: different apps (i.e., implementations of activities) com- municate via technical BOs in Java or OAGIS XML representation, and here we use the BO Instance Repository as a counterpart to the process contexts of all process instances maintained by the process engine. The process instances only

handle BO-IDs, which are used by the orchestrated apps to access and exchange data. This closes the IT-IT-gap.

The most important part is closing the vertical business-IT gaps for data as well as for each activity. This is done by pre-implemented BOs and pre-implemented activities generated from the Logistics Mall offers and operating on BOs. These connected building blocks composed of a business item and an IT item areflexibly orchestrated by business process models, resulting in a“What YoucanModel is What you Execute”approach.