SOA and process designers

A post last week on the problem of the economics of process change by Christopher Koch at CIO.com states the problem succinctly:

IT is in a mess because we have business processes that are locked into source code that is difficult to change or modify?that?s the real issue underlying the argument. That makes customization a dirty, expensive word.

Although he admits to possibly being “drunk on the Service Oriented Architecture Kool-Aid” that’s around, he sees SOA as a potential solution to the problem:

There needs to be a separate layer in the architecture for integration and business process change and coordination. Though web services aren?t always at the core of the layer, the concept of services is.

“Services” as a concept is interesting in this context, although I believe that SOA is just the flavour of the month in terms of naming. We did things like this years ago through appropriate encapsulation of functionality, and although our tools were a bit cruder than what is available now, we were essentially building services — when we did it correctly. Web services, WSDL and UDDI certainly make it easier to share these services, and I completely advocate their use for services to be shared within or between organizations.

The basic issue is that process designers shouldn’t need to understand the internals of the applications that they are orchestrating: they need to see applications such as ERP as a set of properly encapsulated, business-oriented functions that they can call at any point in a process. That means that the relevant functions within “legacy” applications (for lack of a better word) need to be exposed as discrete operations, and that an appropriate process orchestration tool be used to tie them all together.

And in another article of Mr. Koch’s that he links to from the above-mentioned post, he wraps the whole issue together with enterprise architecture, a concept that I also mentioned in a post last week. As more companies recognize the flexibility and business alignment that EA brings, process orchestration will take a more central role since it allows the IT assets that are enumerated through EA to be combined in new ways to serve the business needs.

BPTrends Report on Enterprise Architecture, Process Modeling & Simulation Tools

BPTrends today released The 2005 Enterprise Architecture, Process Modeling & Simulation Tools Report, downloadable for free. They review 10 products:

  • SIMPROCESS from CACI (although I admit to laughing at their overly gung-ho corporate tagline: “Technology that Supports America’s Future”…not something that I’d take forward to one of my non-American customers)
  • Holocentric Modeler from Holocentric
  • ARIS from IDS Scheer
  • iGrafx from iGrafx
  • MEGA Suite from MEGA, an independent business unit of Corel Corporation
  • System Architect from Popkin Software, which was acquired last week by Telelogic
  • ProcessWizard from Process Wizard Ltd.
  • ProVision from Proforma Corporation
  • Process Simulator from ProModel Solutions, although I don’t recommend visiting their site unless you’re into cheesy Flash with music and beeping sound effects
  • xBPM Innovation from xBML Innovations

Like their 2005 BPM Suites Report that I reviewed here, it’s a bit of a mixed bag. The first 26 pages contain some great background information including their view of the business process software market (a reasonable representation), plus detailed definitions of enterprise architecture, process modeling and simulation tools, whereas the product sections appear to be technical marketing info provided by vendors. As with the BPM suites report, a caveat at the beginning states that the vendors paid to be part of the report, and that BPTrends did no independent product testing: my same assessment holds true that the product sections, although well organized and well written, don’t provide anything that you couldn’t get from the vendors’ websites.

What I find really interesting about this report is the categorization of enterprise architecture (EA) tools together with process modeling and simulation:

This report focuses on tools that companies use to analyze and modify business processes. The core tool for this task is a tool that lets business managers or analysts create a diagram or model of a business process and then change that diagram to explore how the process could be improved or redesigned.

Tools that provide support for organization analysis and modeling are, today, usually termed Enterprise Architecture tools. Tools that focus entirely on simulation are termed Simulation Tools. Increasingly, however, companies are using business process modeling tools that also incorporate support for enterprise modeling and simulation. Thus, we decided to include all the tools that can be used for Enterprise Architecture, Business Process Modeling, and Process Simulation in the same report.

I have spent a good part of the last few years talking to customers about how EA and process fit together, but a lot of people are still hung up on limiting EA either to content (that is, Zachman’s column 1, Data) or to what I sometimes jokingly refer to as “implementation details” (that is, Zachman’s rows 4 and 5, Technology Model and Detailed Representations). By grouping EA together with process modeling and simulation, BPTrends has highlighted the fact that processes are critical to the enterprise, and any EA exercise had better include processes. Unlike content, which is restricted to the Data column, processes in an enterprise impact several of Zachman’s columns: Function, Network, People and Time. And, unlike the focus of many IT departments, processes in an enterprise are most effectively modeled in the top three of Zachman’s rows: the Scope, Business Model and System Model.

Lots more to write but no time due to a looming deadline and yesterday’s failed router that put my network out of commission for most of the day — just one of the joys of working for myself. Read the report (or at least the first 26 pages) and talk amongst yourselves.