Why did we invent a BPM governance engine?

Last time I gave you a short overview about the idea of carefully managing BPM governance processes. To do so, we are currently introducing the ARIS Governance Engine. But you might ask how did we come to this idea? Were we sitting in an ivory tower generating some crazy ideas? Definitely not! It was driven by our clients. During the last couple of years, we had been involved in more and more projects where they asked us to implement for example an approval process. "If I change this model (process), it's not just changing a drawing. This will directly impact the way how we work together. Therefore I have to send it to the process owner, and if he agrees we need feedback from the compliance expert, publish it to our shop floor people..." And we programmed something quiet straight forward in Java, or whatever. Not flexible, hard wired single purpose solutions. They were happy – but now they need more flexibility, make their own adoptions without programming. It doesn't scale without our new solution. The importance of models is growing. They are a proven approach in establishing any kind of Governance in an organization. They provide an unambiguous language and transparency. This is not only true for technical models (software engineering, IT architecture management, "the model is the code", MDA, … I could write pages about that) but especially on business level. Just think about the RACI charts in ARIS. Changing a model is not just drawing pictures! Consider a risk management example: you delete in a process model an assigned risk of an activity and the corresponding control. In a worst case this risk occurs nevertheless, but your internal control system that is based on the process descriptions won't detect this anymore. Very unpleasant if you were responsible for that ;-) The targets I set for our R&D was (amongst others ;-))

• Full model driven support of Governance processes
• Real business language like EPC -> hide any kind of unnecessary complexity or need to use BPMN or other technical stuff
• Experienced ARIS users should be able to adopt and deploy the process w/o IT
• High quality governance reference models – to enable users to go live within hours

EPC, Dialog Design, Dataflow description, at design time and a process board (job list & more) during runtime – that's it, pretty much. The cool underlying technology shouldn't play a role for the user. In our interviews with clients to figure out what flexibility do they need, we found that the complexity in terms of process structure (joins, forks, workflow patterns, voting, and so on) was at least on the same level as traditional processes. Therefore, our architecture underneath is a powerful BPMN engine that can invoke standard web services. We have to be able to handle ARIS web services as well as web services from DMS, CMDB, archiving system, etc. But to be very clear: It is not a software engineering workbench for creating services for any kind of application – we are focused on the Governance processes.