More big vs small thinking: SOA vs BPM
I was on the way back to the office from a briefing with BPM vendor Pegasystems yesterday, where we'd had an interesting discussion about the relative roles that BPM and SOA can play in business transformation for customers.
We agreed that BPM, done right, is as much of a discipline that organisations can use to transform the way that they do business, as it is a technology (or set of technologies). What's more, we observed that many BPM initiatives revolve around making big changes to the way that organisations deal with customers, partners and suppliers - and creating organisations that are really focused around delivering real service to those other parties.
Let's review that for a second: BPM thinking helps organisations get their houses in order so that they can deliver coherent and quality services (and not just disjointed experiences).
So from a business perspective, it's BPM that delivers service-orientation!
But wait - in IT we're saying that service-orientation comes from something called SOA. And in IT circles, there's a lot of discussion that positions BPM as if it's a layer of technology that sits on top of SOA technology. Kind of like we've just reinvented three-tier application design with BPM instead of business logic, and SOA instead of database access logic.
This "application architecture" lens for BPM and SOA is all wrong. It's another example of
small thinking.
The more profitable way of thinking about the relationship between BPM and SOA is not to think of them as a stack of technologies: it's to think of BPM as being about "how" you do things and service-orientation being about "what" you do. Service definitions are definitions of commitments: they say what you will do, how well you can do it, and (possibly) how much it will cost you to use. Process definitions are definitions of work: they say how commitments will be fulfilled, by whom, and under what conditions.
So, BPM and SOA are interlinked - but not because one adds value to the other or because one sits on top of the other: both ideas are two sides of the same "business and IT transformation" coin.
If you do insist on thinking of the world in terms of stacks of technology tools or stacks of models or assets, think of SOA and BPM as alternating layers of concepts and practices. Services define "what" you will do at a given level; processes define "how" services will be delivered. Processes rely on foundation services to get some work done; those services in turn rely on processes of some kind.
I'm sure not everyone will agree with this, but I do hope there's one thing we can all agree on - as
Sinatra once sang: "this, I tell you brother: you can't have one without the other."
Labels: architecture, BPM, Pegasystems, SOA
IBM to buy Telelogic: Rational, but not inspirational
I know in the blogosphere, waiting a few days to provide comment on an announcement like
this one hardly puts me at the leading edge - but hey. Although I can't claim to be breaking any news, there are a couple of other points about IBM's purchase of Telelogic that I think are worth making.
As many other commentators have explained, in one respect the purchase of Telelogic takes Rational back to its roots as a tools provider to assist with the development of embedded systems. In this respect, the purchase of Telelogic is really all about IBM capturing market share and consolidating the market for engineering tools for complex systems development. This analysis was given extra weight by comments made by Danny Sabbah, the General Manager of IBM's Rational business, when he stressed that investment in Telelogic's tools and capabilities would absolutely continue. If IBM keeps the commitment made by Danny Sabbah, Telelogic customers can breathe a sigh of relief, and so will IBM. Embedded software developers love their tools, and many Telelogic customers will have made an explicit decision in the past not to go with Rational.
When you look at this (the biggest) part of Telelogic's business it's clear that this isn't just the usual story of mature markets consolidating, however. Back in 1999 I spent more months than I care to remember on
this project, which convinced me it was only a matter of time before ubiquitous broadband networking, consumer electronics and the digitisation of content would open up major new markets for tools vendors. The "pervasive computing and content" thing is starting to happen in earnest, in a variety of sectors - including automotive, healthcare, consumer electronics, retail and travel. Where these things come together, consumer-friendly (and that means high-performance, highly-reliable, bulletproof) software is appearing in more places and in more guises. This is new market opportunity, and Telelogic gives IBM the chance to grab more of it.
So far, so Rational.
But what's been more interesting of late, to me at least, is not Rational's heritage but it's future direction. IBM has made it clear that Rational's focus is shifting from being a provider of development tools to being a provider of tools to help manage the process of software delivery - and helping customers
turn IT inside-out. A big gap here has been in the provision of tools that really help customers model above the level of individual systems, and the surprise to me has been that although Telelogic has these (obtained when it bought Popkin back in 2005) IBM's early talk hasn't put much emphasis on their value. To me this is a major missed opportunity as it's a capability that more and more "mainstream" businesses with IT organisations are starting to realise that they need. Enterprise Architecture competency is quite thin on the ground and IBM has a chance to take a significant step forward in guiding customers here.
Assuming IBM does start to think and talk a bit more about Telelogic's enterprise modelling tools (which would seem to make sense, you'd think) my take is that this is one area where the technology would be best served within Rational's own product management structure rather than under Telelogic. As Rational moves its focus more towards managing the process of software development, the Telelogic assets naturally form a specialised sub-piece within the overall picture - but System Architect fits naturally alongside things like
RAM,
RMC,
RPM, and some other stuff I can't talk about yet.
So - I really hope we start to see more from IBM about how the more mainstream capabilities of Telelogic will be taken forward, and if/how it will start to separate those mainstream capabilities from the specialist "complex systems engineering" capabilities.
Labels: acquisition, architecture, EA, ibm, inside-out IT, Telelogic
Little SOA vs Big SOA
During our "off air" preamble with Miko Matsumura prior to recording
our podcast earlier this week, he mentioned that he likes MWD's focus on "Big SOA".
I'd never thought of what we tell customers about SOA in this way before, but it's true that we try and get people thinking about how SOA can help them transform their organisations in the long term by pushing the boundaries of SOA and not sticking with an overly-technical, bottom-up approach that sees SOA as "EAI with standards". So Miko got me thinking about what, precisely, "Big SOA" might be and how it might be different from something that for the sake of argument we might call "little SOA".
So I came up with a picture:
As the picture shows, I think the difference between "little" and "big" SOA comes down to how you look at the "S" and the "A" of SOA.
In "little SOA" (bottom left of the picture), organisations have a software development centric view of what a "service" is. A service is basically a standalone software component with some kind of remotely addressable invocation interface (let's say a WS-* interface for now). In "little SOA" organisations have a similarly narrow view of what "architecture" is - architecture is basically
software design with a corner office.
In "big SOA" (top right of the picture), organisations have a much broader view of what a "service" is. In this broader view a service isn't something you build; it's something that is experienced by a consumer. This view, therefore, is really about realising that delivering a service requires all sorts of IT competencies (design, development, integration, testing, deployment, admin, ops and change management) to be integrated together across the lifecycle of an investment that is packaged up as a service. That's a very different perspective on "service" that is not coincidentally much closer to what a business exec would think of if you asked them what a "service" is. In big SOA organisations also have a broader view of what architecture is about. Architecture isn't an inwardly-focused IT competence that seeks to make global optimisations to portfolios of software development projects. It's an outwardly-focused business-IT communication competence that seeks to further understanding of IT within business, and of business within IT.
I don't have hard quantitative data to back this up, but based on anecdotal evidence of customer conversations my feeling is that the majority of companies considering or starting out with SOA are doing "little SOA".
What do you think?
Labels: architecture, service, SOA
