Like most senior technical people, I wear a lot of hats, but most recently I've been heavily involved in some very wide-reaching initiatives around business processes. My company is in the middle of a program that involves a lot of what used to be called business process re-engineering. My department, which looks after the business systems piece of our global information systems, was charged with looking at a Business Process Management Suite of software. For those who aren't familiar, BPMS looks a bit like workflow on the surface, but includes tools for monitoring and improving processes as well.
Of course, soon after we started looking at BPMS, we realized that our integration technology was getting long in the tooth (or, in some cases, was completely toothless). Enter an project to come up with a new architecture. Of course, you can't say integration these days without pronouncing it SOA, and that's not a bad thing because BPMS and SOA are "complementary technologies".
So that was fine, until we discovered that some people were (quite innocently) doing stuff that looked a bit like enterprise architecture, and that too was good because EA models make nice feeds into BPMS work and help put everything into context.
Now, as every Zachman fan knows, EA doesn't just involve process -- there's lots of other stuff, too, like data. And it just so happens that SOA and BPMS follow the garbage in, garbage out law just like the rest of the known universe. So, clearly we need some data governance to ensure that the system is garbage-free.
So, my hats now include BPMS, SOA, EA, and DG. Very soon someone will realize that the real value in all of this lies in business intelligence...
A bit more seriously, this gets me thinking about how well these technologies, which fit together very well conceptually, are really presented and used both in terms of software and in terms of methodology. One of the first issues I've identified is where to draw the lines between technologies. Should I put my process logic in a service, to be consumed by a workflow? Or should the logic reside entirely within the BPMS? Should data governance be implemented via a distinct DG tool, or should services take care of that, too, with DG just being a kind of philosophy? Should workflows begin in the lower levels of EA, or should they being in BPMS? And that BI thing that's on the horizon...should it be a separate piece, or should it be fed through integration? And speaking of integration, is that a service thing or a BPM thing?
What's needed is a holistic approach, or at least a 50,000 foot view of the whole thing. Time for a new discipline? But first I'll need to come up with a shorter acronym.