TIBCO is holding a series of seminars in various cities, and today they’re in Toronto, where I happen to be at home for a few weeks. Amazingly, there’s free wifi in the Park Hyatt meeting rooms, something that I never expected
We had a welcome from the regional VP, Craig Byar, and an overview by Rourke McNamara of SOA product marketing, but the key speaker was Paul Brown from the Global Architecture group. Actually, McNamara made a great point in his short presentation: organizations with an identified BPM center of excellence (CoE) reported five times greater ROI over those with no CoE or dedicated process team.
Today’s business processes involve many systems, and we’ve used EAI and ETL in the past in order to tie these systems together, but we’ve created a fragile mess of our systems and lost the focus on the business process. It’s hard to . SOA and BPM refine the traditional 3-tier layer of presentation, business logic and data by splitting the business logic layer into processes and services: effectively, BPM and SOA. The service layer can further be split into service operations (the actual functionality of the service) and service access mediation (finding the right service and authenticating access). He also splits the process layer can be split into hard-wired processes (the processes in legacy systems that can’t be changed, or unchangeable high-volume processes such as credit card processing), orchestrated processes (integration-centric processes facilitated by BPEL) and managed processes (BPM), although I’m not sure that I agree on the distinction between the latter two.
We need to separate processes from presentation; too often in the past we’ve embedded processes right in the presentation layer, and since we deliver functionality now through multiple presentation channels (web, desktop application, mobile, web service), the process needs to be in the layer below presentation so that a consistent business process is executed regardless of the presentation channel.
We have a disconnect between business and IT when it comes to developing new systems, and we need to first focus on business processes — the source of business value — to see how they bind together people and systems. There’s an expectation that systems will be developed faster, and this type of splitting of presentation, processes and services helps to facilitate that. However, there needs to be overall architectural guidance and governance for any development project so that things fit together: an architectural review of bot the business process and the systems somewhere between initial requirements and development. The challenge that I see in this model, however, is not to fall back into old-style waterfall development: instituting a requirements-architectural review-development cycle can tend to make the development process less iterative and agile.
There are three key leadership roles in any BPM project, immediately below the business executive sponsor: the project manager, the business process analyst/architect, and the systems architect. I have to say this is true of any business-facing development project, although the business process analyst/architect will be replaced with the particular application-specific analyst/architect role. Brown equates the CoE for a specific technology or application such as BPM, and an overall enterprise architecture team in terms of the mentoring and governance role that they provide. He had a number of case studies of BPM and SOA projects that showed significant ROI, with a BPM/SOA CoE being a key part of each of them.
We all ended up with a copy of Brown’s first book, Succeeding with SOA, and apparently I’ll be getting a copy of his hot-off-the-press second book, Implementing SOA, at TUCON later this month.
We had a quick demo of TIBCO’s process modeling environment, showing the different usages by a business analyst versus IT.