BPMS that an enterprise architect can embrace
August 26th, 2009 by Mark Taber
As an enterprise architect, you have a tough job. Business people do not want to be “governed.” They see no need to use the infrastructure that you have carefully put in place. The more rigid you are, the more likely they will find a way to circumvent. Even if you find out they have ignored your policies, you are frequently not empowered to make them use the infrastructure. Further, while you know that building standards-based/service-oriented applications is clearly the best practice, SOA is probably not an “official” direction. Business users can still complain to their vice presidents that middleware is an impediment. Every day you are either awarded a medal or put in front of a firing squad.
The trend towards “the business” developing and running business process management systems is reflective of this destructive mindset of going around IT. We all know that they can be successful with “happy path” workflow modeling. But do we really want business users, with their own servers, managing and changing mission critical applications? Of course not. Islands of BPMS that exist outside of IT will eventually fail because of all the necessary exception handling, the effort required to get the data and deployment right, system-to-system integration and the lack of rigor around the software development life cycle.
The answer is a BPMS that lets the developer stay in their current tools, lifecycle, etc. It is a given that, as vendors, we must lower the level of pre-requisites to allow non-programmers to do serious modeling, as well as build, test, deploy and optimize processes. Further, we must use collaboration diagrams to work with the more technical of business analysts so that they can sketch out requirements, modify/edit forms and storyboard. A portion of these analysts may even be able to adapt a process making quick changes to application templates.
As an enterprise architect, start thinking about creating a “federated” BPMS or orchestration layer in your architecture that facilitates the creation of business services. ESBs may be useful but are frequently not necessary and certainly should not be mandated. A BPMS should be able to run anywhere without infrastructure dependencies. The standards are there and becoming well established: BPMN for modeling, BPEL for executing business processes, WSDL for SOA services, WS-HumanTask for task management and XSD for data representation.
Business Process Management and SOA are not precise games. There will always be a balancing act to deliver the benefits. Don’t try to boil the ocean. Pragmatic adoption will allow you to both keep the business happy and support the long term goals of your CIO. ActiveVOS makes it easy. You can download a free, 30-day trial. We have a rich set of content on our website that will quickly get you started but if you need help, our technical support people are standing by.
Don’t wake up a year or two from now only to find the company’s core applications running under desks in every fifth office. You will never get them out!
Tags: ActiveVOS, BPM, BPMS, enterprise architect, SOA
