Adopting BPM at Bank of Northeast of Brazil

Next in the workshop was Moises Branco from University of Waterloo; he previously worked with the Bank of Northeast of Brazil (BNB) and discussed his work there as well as his current research that resulted from some of the challenges identified there. Their motivation for BPM came from a revision of their IT processes in 2004 that exposed the inflexibility in the heterogeneous environment; they saw BPM as being important for modeling and optimization, but also for process execution. They graded all of their existing systems on scales of technical quality and functional quality, mapped onto four quadrants of substitute (both low), improve functionality (low functional, high technical), improve architecture (high functional, low technical) and maintain (both high), with a drive to move systems in the two “improve” quadrants into the “maintain” quadrant.

He showed their strategy for execution, which included a business specification in the form of a process model, then an executable process that was a transformation/refinement of that model, and used an ESB to call services layered over their legacy systems. Since they took an enterprise architecture approach, they considered the multiple interrelated artifacts produced, including process models at various levels, use cases, business rules and entity-relationship diagrams. With multiple artifacts, the concerns became traceability, consistency and impact analysis between the models. To complicate things further, some of the development was outsourced, meaning that the collaboration between business and IT that should occur during any model-driven development had to extends beyond the enterprise.

Unfortunately, just as we heard from BofA, much of the model translation and consistency management was manual, as well as the collaboration in terms of version management. They were able to semi-automate the establishment of traceability links and perform basic model consistency checking.

Their current research is on model consistency: defining it via traceability, and automating some of the traceability between models (e.g., business-level and executable) and consistency checking.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.