Today, I'd like to tell you about an interesting customer project handled by IDS Scheer, in which an MDA approach based on ARIS was used to generate an SOA specification in a top-down manner.
A model-driven architecture (MDA) is an OMG framework for software design. The framework contains several layers, each of which models the different aspects of software design. At the highest level, the model contains the business description only (i.e., without any technical details), while the lowest level is the executable description. The models on the different levels are obtained by model transformations. The aim was to perform these transformations between the highest and lowest level in several steps by automated conversion. Each transformation generates a new model containing more technical details than the previous one.
This idea was developed in one of our customer projects that comprised two phases, the objective being to obtain a service-oriented architecture (SOA) specification that can be subsequently used for implementation. The first phase was a conventional BPM project, in which we defined the business processes at different layers of abstraction. These layers are the business levels of an MDA approach. In the second phase of the project, we defined the technical levels needed to create a technical description for implementation purposes.
The procedure of the first phase will be familiar to anyone involved in BPM, so I'll restrict myself to explaining the second phase in more detail. Here, we added technical details to the processes mapped in the first phase. This entailed modeling a data description containing all data used in the processes in an entity-relationship model (ERM) and designing services to support the different process steps of the business processes. We also defined user interface (UI) models for each process step, which was performed manually (human task). All in all, this produced a very detailed specification of the software to be built.
Based on the above models, we executed an automated transformation. This transformation converts the models defined in the ARIS Platform to the XML specifications required to build an SOA. From the data model, we generated an XSD (XML schema), which is used with the WSDL generated from the service model to obtain a specification for Web service implementation. The UI models are used to generate Extensible Application Markup Language (XAML), which is a Microsoft standard. The XAML description can be either displayed in a browser or directly used as a UI description for implementation (see next figure).
The advantage of this approach is that you obtain a business and a technical specification in one step. This helps to save costs and automatically aligns the business specification with the technical specifications. It also ensures that the business requirements defined in the business processes are actually implemented, which makes the users happy.
This is an interesting approach. Two questions:
1. The first figure shows a transformation between the business description and the mixed description. Is this actual some kind of automatic transformation (as it is in the second step like eERM to XSD etc.) or is it just adding the technical descriptions.
2. Is a typical business description actually suitable for this approach or did you need to rework it? From my experience, business descriptions are often simplified in order to make the diagrams more comprehensible. In this case it would not be enough to add technical details, but also a lot of business level detail, especially all kinds of exceptions that need to be handled in a process.
Hello Thomas,
to answere your questions:
1 - There is no automatic trasnsformation. We are adding in the workshop as much details as needed to the EPC so we can transfer the EPC afterwards manually to BPMN. We are adding the details in EPC so that it is easier to understand for the workshop members and becuase the business EPC differs from the technical BPMN process.
2. You are right the business description is not always suitable to the technical description. That’s why we are having the mentioned manual step from EPC to BPMN. So EPC is the business description and BPMN is the technical description which contains exceptions and session, …
Greets Tobias
Hi Tobias, it sounds very interesting and very similar to what we're trying to achieve with our BPM implementation and using the IBM IAA reference architecture. I have developed a service specification that gets generated from the following ARIS model types:
1. UML use case diagram: describes the overall operation (service) in business terms
2. Access diagram: defines the collaboration between the various components and intefaces to realize the service
3. Program flow chart: to descrobe detailed message flow from source application to destination application
4. UML class diagram: defining the data structure of the service
5. Screen navigation: (if required)
6. Screen design: Detail UI design
IF possible, could you mail me an example of how you have used the Access diagram to define the service?
Regards
Eienne
Hello,
sorry for answering that late - but i was on vacation.
We are using the Access Diagram (as you can see in the picture below) to Model the service with its "Functions" (which are reflecting the port types) and its in- and outgoing Data (Messages).
.jpg)
