Which comes first: process or service? Part 1
Over the years I've been helping to run MWD I've been to quite a few events, talked to many enterprise IT folks and talked to many tech vendors, too - and one of the topics that comes up most often is the relationship between BPM and SOA. There's been a bit of a run on the topic in the blogosphere lately. First, I was alerted to
this post on CIO.com via the EDS fellows' blog in a post called
SOA is a Business Process Architecture. At around the same time, I read
The Problem with Process by Nick Malik (always good to read).
Too often, in presentations and papers, I see diagrams that replicate the old three-tier architecture of the '90s, but with a twist: instead of user interface, business logic and data access layers, now I keep seeing portal, BPM and SOA layers. Portals provide user interaction, and invoke processes; processes invoke services. Job done.
Looking at BPM and SOA purely in this way is short-sighted, disingenuous and dangerous. It looks at both initiatives through a very focused lens, and essentially says "BPM and SOA are about building and integrating applications". Not your father's applications I'll grant, but applications nonetheless - things with hard boundaries that have little awareness of other systems or resources that might exist, and little conceptual relationship to broader architectural or business considerations.
The first, and most obvious, point to make that blows this kind of picture apart is that it's mind-numbingly straightforward to wrap a process (or at least the initial invocation of a process) as a service. So *now* what's "on top" - process or service? This realisation has led to more enlightened commentators advocating that organisations consider processes and services more like a lasagne, with alternating layers of the two concepts. Services expose processes, processes call services, etc etc ad infinitum.
However even here we're only part way to the real answer, because this view also stems from seeing both BPM and SOA primarily from a "bottom up", software development- and integration-centric perspective. Of course, many people refute a view like this, and point out that "BPM is a business management approach, and SOA is a technology architecture approach - you can't lump them together so easily". In other (very simplistic) words BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative.
The two articles I've linked to above are great because they start to take a deeper look at the architectural and conceptual relationship between service and process. Both EDS Fellow Fred Cummins and Nick Malik start to pick away at the simplistic views that seem to hold sway in the minds of many at the moment.
Neither quite take the argument as far as they might, though. Through our industry research (for
our book as well as our various
free reports and consulting gigs), we've come to see that the value of both BPM and SOA comes from considering them neither purely as bottom-up initiatives focused on improving the development / integration of applications and resources, nor as top-down initiatives focused on exploring and elaborating business architecture. We already have a champion in the case of "top-down SOA" - the
OASIS SOA Adoption Blueprints team. The real insights come, I think, when you see how top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture.
I'll expand on what such a view entails in a Part 2 of this post, in the next few days.
Labels: BPM, EA, SOA
The Mysterious Oracle
As part of my research into all things collaboration, not least through my development of our forthcoming continuous advisory service, I have regular briefings with software vendors to find out what they are doing. Usually vendors are more than pleased to brief us analysts - anything to build the profile of their company or products within the marketplace. It is odd, then, when a vendor refuses to brief you on something. That is the current position I find myself in with Oracle.
Oracle has had a stake in the ground in the collaboration market since 2003 with its Collaboration Suite, the latest version (which was released in 2005) including products for email and calendaring, instant messaging, team workspaces, web conferencing, unified messaging and discussions. It's also true that Oracle has a fair job on its hands integrating the Stellent content management software (which it acquired in November 2006) with its own technology. But with all the general hype around Enterprise 2.0 and collaboration in the market at the moment, combined with the high profile that its major competitors in this space - IBM and Microsoft - are maintaining, it is intriguing that Oracle (which does not usually shy away from PR opportunities) is keeping such a low profile.
Oracle is far from being a major competitor in this space, but with an existing offering on the table, it should be making more of an effort to catch up. Perhaps all this secrecy belies some imminent great announcement that will shake the market. But right now, all it is doing is lowering the market's confidence in its ability to deliver on the collaboration promise. Oracle needs to get its act together in collaboration, or it will miss the boat entirely.
Labels: collaboration, enterprise 2.0, Oracle
An identity management OTR
Today we published
another On The Radar report. This one looks at The Dot Net Factory which has taken its purpose-built workflow management platform (based on Microsoft's Windows Workflow Foundation) to create EmpowerID, a role-based identity and entitlement suite.
As the name of the company and the technology foundation of its offerings suggest, The Dot Net Factory should be of particular interest to organisations looking to bolster their provisioning and access management capabilities in a Microsoft environment.
Labels: MWD
Linux: innovation platform or commoditising force?
A few days ago Matt Asay wrote a piece on
Linux's use on Wall Street in his "Open Road"
blog. He recounted how one of the MDs from Bank of New York Mellon saw "open source as the foundation of choice for their innovation". He goes on to say that this runs counter to prevailing opinion, which positions Linux (and open-source software technology in general) as a commoditising force.
It's not as straightforward as he makes out, though: in truth, Linux is BOTH a platform for innovation, and a commoditising force. It's always, in fact, been this way: there's one community that is most attracted to the fact that Linux code can be tweaked and reconfigured in extreme ways (you just have to look to
Google's widely-cited work here to see what I mean). And there's another community, less vocal but much larger in number, which is much more attracted to the fact that open-source software tends to be "free" (of charge) than it is to the ability to mess with the source code.
So Linux (like many other open-source software technologies) has two markets and two demand curves associated with it: one is populated by companies with leading edge technology use requirements; and the other is populated by companies who want to align their technology expenditure much more with the business value they receive from it, and see the lack of an up-front license fee associated with open-source software as a perfect route to do this.
When looking at technologies like this and commenting on their role in industry, we need to be careful which market we're really referring to.
Labels: industry, innovation, Linux, open source
Another On The Radar report
Those of you interested in application development and agile methodologies might want to take a look at
our latest On The Radar report, which looks at Portugal's OutSystems.
As well as offering a comprehensive set of application development and management capabilities, the company provides customers with a choice of on-premise or hosted deployment (with plans for hosted development too).
Labels: MWD
