The last speaker at the CASCON workshop is Sebastian Carbajales of the IBM Toronto Software Lab (on the WebSphere BPM team), on the interaction between a technical business analyst using WebSphere Business Modeler and an IT developer using WebSphere Integration Developer, particularly how changes made to the business-level model in WBM are reflected in WID. The business view is quite different from the IT view, and doesn’t necessarily directly represent the IT view; this is a common theme at this conference, and in general for vendors who don’t use a shared model approach but rely on some sort of model transformation. Given that there are two different models, then, how do business and IT collaborate in order to keep the models in sync?
They first looked at maintaining a separation of concerns between business and IT that would to minimize the need for changes by IT in response to a business change. This comes down to separating the business logic and rules from the implementation, and the separation of artifacts with well-defined logic from those with undefined logic. I’m not sure that I really get the distinction between the well-defined and undefined logic artifacts, or the benefits of separating them, although my instinct would be to externalize much of the business logic into a rules environment that the business analyst and/or business manager could manipulate directly.
They also looked at tool-assisted model merging to allow models to be compared in the specific user’s domain, then selectively apply and merge the changes into existing models. This would speed development as well as improve the model quality by reducing translation errors. There are some very similar concepts to those discussed in the previous paper on model change management, although with the added complexity of multiple modeling environments. A key goal is to improve the accuracy of model change detection, both to identify the objects in each model type as well as the relationships across the business-IT model transformation, and they used a traceability mechanism to do this. They generate a traceability map when the business to IT model transformation is originally done, capturing the identify of and the relationship between each object in the models, which allows traceability of changes on either model type.
He walked through a typical scenario, where the BA creates a process model in WBM, then exports/publishes it, where it is then imported by IT into WID and enhanced with implementation artifacts. When a change is made by the BA to the original model, and re-exported, that modified model is compared to enhanced WID model to create a new, merged WID model. Then, the change report is exported from WID, and any business-level changes are compared and merged back into the WBM model. Yikes.
Having a traceability map allows an IT developer to filter changes based on the business or IT artifacts, do visual comparisons and selective merging of the models. On the return trip, the BA can view updates to the process model, business services and business service objects that might impact the business logic, and select to apply them to the business-level models. The traceability is the key to model governance when multiple model types undergo transformations as part of the modeling and implementation lifecycle.
Following Carbajales’ presentation, we had a round-table discussion on the two process modeling themes of collaboration and consistency management to finish up the workshop. Some good ideas on the reality of business-IT collaboration in process modeling.
Dear Sandy,
thanks for this post too. I appreciate your work, I think it’s big value for the BPM community.
I think traceability is crucial, but may not be enough. What we really need is coherency and alignment of models. The complexity of modern enterprise applications requires several models to describe all the relevant aspects. Design tools should be aware of this and *grant* alignment by construction.
This could be fairly easy for models that deal with the same level of abstraction, while it could be much more difficult when alignment is needed between business and IT models of course.
Furthermore (maybe even more crucial), alignment should be granted between models and implementation.
In my experience, all this can be achieved only through well engineered model-driven development (MDD) approaches.
Marco, I agree. The key problem with traceability in this situation seems to be that the two tools used were developed without any specific knowledge that they would be used together. Whether you use a single tool for complete model-driven development, or multiple tools that make use of model transformations, they clearly need to be much better integrated than what we saw in this IBM example in order to achieve traceability and alignment.