Is there room for architects and architecture in BPM?
With much of the early development in the Business Process Management (BPM) market being driven by technology vendors selling products for one-off departmental projects to line-of-business heads, and with IT stakeholders often being brought in only after the deal is done, lately we've been wondering - now that there's no doubt that BPM is becoming more mainstream - what's the role of IT architects, and IT architecture, in today's BPM initiatives? There's a lot of talk in the BPM technology vendor community about enabling customers to "scale up" their BPM initiatives - and it seems to us that IT architect involvement is likely to be a key factor in shaping how that happens in practice.
Behind the scenes we've recently built a great relationship with the not-for-profit International Association of Software Architects (
IASA), and so we asked them if they'd help us explore this question. We've worked together to carry out a web-based survey - and although all IASA members have now been invited to take part, I wanted to make sure that you had a chance to take a look and offer your thoughts, too. If you're in an IT architecture role, or know someone who is, we'd be delighted to have your involvement:
you can find the online survey here.
Once the survey is complete, we'll create an in-depth report drilling into the survey findings and correlating them with findings from our other BPM research work. Everyone taking part in this survey will be eligible to receive a free copy of the report. We'll also create an IASA-only webinar, based on the survey results and adding other best-practice insights. All IASA members will be able to access this webinar free of charge.
So - if you're an IT architect or know someone who is - we'd
love to hear from you! And if you're interested in the IASA webinar we're creating -
it's easy to become an IASA member...
Labels: architecture, BPM, IASA, survey, webinar
Why we need ALM: industry's dangerous flirtation with software quality
Yesterday I spent the evening at a dinner in London as a stand-in for my colleague Bola Rotibi, talking about Application Lifecycle Management (ALM) and governing software delivery to a group of around 20 senior IT leaders. Due to my own disorganisation I'd not realised that this was a stand-up talk with no visuals or projection, and I'd created a slide deck for the talk. So, on the train to the event, I was frantically reverse-engineering my slides into a set of brief stand-up notes. Although it was a pain, it ended up being fortuitous because the act of having to reinterpret my slides made me see a couple of points worth making that I hadn't spotted before.
The point I was making is that today's industry interest in ALM represents an interest in delivering high-quality outcomes from software delivery work, but that's hardly a new thing. However the need for ALM today is made more pressing by industry's historic failure to consistently address quality as a concern. It's what I called "industry's dangerous flirtation with software quality" - kind of a perpetual "get away, come closer" posture that has by and large failed us. Although there's now 50+ years of racial memory somewhere out there in industry about why software quality is important and how to achieve it, the problem is that fundamentally, the IT industry is a fashion industry - and each new fashion wave brings a new set of devotees, few of whom are particularly interested in taking notice of what the devotees of previous waves learned.
Let's look at a picture.
What I'm trying to show here is how disruptions in technology platforms and architecture patterns typically lead to the baby being thrown out with the bathwater. As any given approach starts to have mainstream applications and matures, the importance of quality becomes more visible. Then, though, a new platform arrives and we start all over again. Think about how, in the client-server era, we started with hacking in PowerBuilder and VB; then, "second-generation" client-server tools took more CASE-like approaches and helped organisations deliver more scalable, robust apps more quickly. Then came the web, and it seemed that we suffered from a mass "memory wipe" before grabbing hold of the nearest Java IDE and hacking again.
We've been through this cycle at least three times: from mainframe to client-server; from client-server to first-generation web; and from first-generation web (simple consolidated server deployment; simple web-based client deployment) to where we are now (I'm desperately trying to avoid typing the web-two-dot-oh thing, but I'm referring to web-based services with multi-channel front ends, mashups in the mix, back-end web-based integration, etc).
Of course, so far I've really said nothing you probably hadn't thought about already. But what also struck me yesterday was how each "turn" around the cycle has added more complications to the process of software delivery. There are three parts to this.
Firstly, consider that each time we've turned through the cycle, the overall IT environment has become more complicated. This has happened in two ways. Each new platform/architecture has brought more distribution, federation (moving parts) to the equation; and nothing ever dies - mainframes, client-server systems, and first-generation web systems still abound. They're part of the operational and integration environment.
Secondly, each time we've turned through the cycle, there's been a decreasing scarcity of "hard" resource - that meant that we naturally had less innate desire to control effort and quality than previously. Back in the early days of mainframe development, CPU cycles were expensive and access to those cycles was exclusive; it was absolutely obvious that the cost of the assets employed was so high that you had to get things right first time.
Today, for the price of a sandwich, I can get some tools, rent some server capacity, and build and deploy an application that might end up playing at least a bit part in the way a business works.
The kicker is that although the cost of "doing stuff" is rapidly tending towards zero, the cost of software failure is at least as high as it's always been - but the tendency in industry to perpetuate the artificial "wall" between software development and IT operations means that we can easily forget about the cost of failure - and the overall risk to software delivery outcomes - until it's too late.
Thirdly, each time we've turned through the cycle, the distinction between "software" and "service" has become more and more blurred, as business services have come to depend increasingly on software automation internally, and be delivered to consumers through software-based interfaces externally.
These three factors all point to the desperate need for organisations to be able to better link activities across the whole of the software delivery lifecycle - from upstream activities like portfolio management, demand management and change management right through development, test and build all the way downstream to IT operations.
We need to turn software delivery into a business-driven service - and that means ensuring that business priorities are reflected in
*what* work gets done; ensuring that business priorities are reflected in
*how* work gets done; and ensuring that individual projects are carried out in the context of a "big picture" of business service delivery. That's what ALM is all about.
If you'd like to read more about Bola's thoughts on this subject, check out
The dilemma of "good enough" in software quality.
Labels: ALM, architecture, development, Software Quality
Cloud computing, SaaS and SOA - the universal service network
Something that's been sloshing gently around in my head for a little while came into focus the other day on reading a post by Brenda Michelson:
Unintentional Cloud Watching >> Cloud Computing for Enterprise Architects. Namely, that the link between cloud computing and SOA has multiple angles.
It's becoming clearer that, true to
Tim O'Reilly's initial Web 2.0 noodling, by providing open infrastructure services and APIs, the poster children of the Web 2.0 era - Amazon, Salesforce, Zoho, and so on - are now treading the path that companies like
StrikeIron started out on in 2002.
As a result, as other commentators have noted, it looks like the bulk of the service-oriented IT that many organisations will interact with will be "stuff from outside" (commercially provided services) rather than "stuff from inside" (internally developed services). And it's not just hosted SaaS providers who are playing here of course: there's the issue of newer versions of on-premise commercial packaged application software products and integrations between them - SOA is coming in by the back door there, too (see
SAP's ESOA,
Oracle's Fusion Architecture). In fact, perhaps unsurprisingly, there are strong parallels here with the component-based development (CBD) hype-wave of the 1990s - a lot of the initial hype was around tools and development for enterprise IT groups, but ultimately the vast bulk of development was actually carried out by commercial software vendors, for consumption by enterprise IT teams. What we're seeing here is a repeat of "
componentware" market development, with a 21st Century twist.
Regardless of where services come from (and indeed because they will come from multiple places, creating cross-enterprise service networks), it's increasingly the case that in order to deliver effective IT capabilities in the 21st Century, you need to understand SOA principles and build technology and management structures that really support the principles of service orientation. Much has been written about the "consumerisation of IT" and how new generations of people entering the workplace are asking difficult questions about why enterprise IT applications are so unintuitive to use. But what happens when business teams that are using SaaS-based offerings learn about the infrastructure side of the story - how easy they can be to customise, extend, and integrate with - and ask why internally-developed systems don't exhibit the same qualities? Another slab of SOA pressure, that's what.
Back in 2006 I was doing some research for an event that we were considering running on "IT Sourcing in the 21st Century". As part of trying to work out what might be in scope and what might be out of scope, I drew this picture:
As the picture attempts to show, from a technology architecture point of view, the software-as-a-service (SaaS) model relates to the prior Application Service Provider (ASP) model in much the same way as SOA relates to monolithic on-premise applications - to deliver value, both SaaS and SOA need to "crack the box open" and enable IT capabilities to be customised, composed and remixed while also being shareable/reusable. There's much I disagreed with about
Anne Thomas Manes' recent "SOA is dead" post (see
Schrodinger's SOA), but she nailed this parallel between SaaS and SOA pretty well I think.
With the increasing visibility of cloud-based infrastructure and application services in mind, anyone seriously pursuing SOA should be looking to the world of SaaS for insight, or at least inspiration. In the IT industry's rush to SOA, many of the nuances and implications of SOA have often been condensed into simplistic advice targeted at software developers (something that's been written about a great deal,
not least by us). One of the themes we've returned to again and again in our SOA advice is that the concept of a "service" isn't primarily about something you build - it's about something you experience. If you're going to deliver business value from your SOA efforts, you have to grasp the implications of this and make the necessary changes - not only in terms of tools and technologies, but also (crucially) in terms of your governance approach. One of the most popular posts from arch-architect Todd Biske, on
ITIL and SOA, digs nicely into how it's crucial to consider the full service lifecycle when you do SOA, and drive governance to ensure that you can deliver "real service" - not just code wrapped in XML-based interfaces.
The providers of cloud-based services should have this idea etched on their brains - and there are plenty of examples of this principle in action for any eager student of SOA. Witness the grumbles that echo
when Twitter barfs, for example, or see the
grumpy users trying to get to grips with Zoho's CRM API in the face of almost non-existent documentation. These are great examples of situations where the provider's idea of service doesn't match the consumer's expectation.
The rise of cloud computing and SaaS should entice us to revisit our development-centred assumptions about SOA and search for a "bigger picture" that focuses on consumer expectation and value first. The pressure to deliver business value from IT capabilities, and the increasingly diverse mix of IT capability sources, demands that we do so.
Labels: architecture, cloud computing, ITSM, SaaS, service, SOA
Schrödinger's SOA
I've spent a couple of days wavering over whether to jump into an ongoing blogosphere debate over the "Death of SOA". For those who haven't yet read any of the debate online, here's the catalyst:
SOA is Dead; Long Live Services - a fictional obituary of SOA by Anne Thomas Manes of the Burton Group. On one hand I wanted to avoid adding another voice to a growing crescendo of opinion and counter-opinion and the risk of not really shedding any extra light: but on the other hand I thought that some people might expect MWD to have something to say! Particularly given past blog posts like
SOA 2.0? Stop the madness,
Little SOA vs Big SOA,
More big vs small thinking: SOA vs BPM,
The pointless search for SOA ROI, and
On SOA governance: for SOA, read CPOA?.
In the end, I couldn't help myself. Call it New Year exuberance. So what's our take? Is SOA
dead or alive? Should anyone care?
I think there are a couple of key points to consider. First, what's wrong with SOA today? And second, what should we do about it? I agree with Anne on the first; but I think I really disagree on the second.
When I look at Anne's post in detail I believe she's making 4 basic points:
- The majority of SOA projects have failed to deliver what they promised.
- Business people are disillusioned with SOA.
- "SOA projects" will be killed by today's difficult economic conditions.
- Despite all this, the requirement for SOA is greater than ever.
I'll happily back two of those points up - the first (
UPDATE: to a degree - I have anecdotal evidence that suggests many organisations struggle with SOA, but that's not quite the same)and the fourth. There's one section towards the end of Anne's post I'm particularly in agreement with:
SOA is not simply a matter of deploying new technology and building service interfaces to existing applications...it requires a massive shift in the way IT operates. ... The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.
This is pretty much what we've been saying about SOA for some time (see
Little SOA vs Big SOA from April 2007). In short: SOA won't succeed if you take an overly technical, product-based view of it (and indeed we're far from alone in this -
ZapThink bangs this drum a lot, too, for example).
So we agree that not all is well in the State of SOA: but where I diverge with Anne's post is in the prognosis for SOA and the treatment for the illness.
Anne's prognosis/suggested treatment is that SOA (or at least the term) is (or will soon be) dead. Her view appears to be that because its death is inevitable, we should accept it and move on - stopping talking about SOA and starting talking about other things instead. This appears to be bound up with her observations that "business people are disillusioned with SOA" and "SOA projects will be killed by the economic downturn".
Before I move on - I don't know about you, but I think that if any IT group has been trying to sell SOA directly to business people, they deserve everything they get. Regardless of economic conditions. No, no, no! You don't sell methodologies and architectural patterns: you sell outcomes. Argh! And here's a hint: if you work for an IT group that used to try to sell SOA to business people, and is thinking about now trying to sell "mashups", "cloud computing", or similar things - don't bother, you'll get the same result. Sell the outcome and the benefits, not the mechanism or the technology. Double Argh!
There's another risk with changing the way we speak about what
Miko Matsumura jokingly now calls
"The Artist Formerly Known as SOA": by doing so, we continue to spread the perception that the IT industry is a fashion industry unable to kick its habit of (re)inventing terms to reinvigorate markets when earlier promises go unfulfilled. Whether she knew it or not when she wrote the post, by referring to a change in terminology (away from SOA and towards "services", "mashups", "cloud computing", etc) as an active and influential commentator, Anne is contributing to the fall from grace of the term.
Well, as I said
here when I railed against SOA 2.0,
I sincerely believe that analysts should be good stewards of the influence they have - educating, clarifying, abstracting, comparing, acting independently, being measured, etc. It's about filtering out hype and trying to provide practical, independent advice and insight.
Just because SOA is difficult to do, we shouldn't start calling it something else in the hope that we can start over without anyone noticing. And it's no surprise that SOA is tough to sell to business people - I don't believe that was ever up for debate, and it shouldn't be seen as any kind of broader indicator.
Let's acknowledge that we all have more work and education to do - but let's not
jump the shark on this. "SOA is Dead" is a headline that no-one needs.
Labels: architecture, hype, SOA
The death of middleware
I've been spending a fair bit of time this week talking to a journalist I've known for years,
Danny Bradbury, for a series of features he's writing on the middleware strategies of some of the big enterprise software vendors.
After our first chat, something suddenly struck me (probably very belatedly): when
middleware is talked about and sold today, what is being discussed is completely different to the stuff I first learned and wrote about in the mid 1990s. The difference is all to do with the meaning of the word "middle".
In the mid 1990s, "middle" meant "the gaps between applications and software components". Middleware was technology you turned to in order to try to build distributed systems: we were faced with transaction processing middleware, database middleware, object middleware, and so on - all different forms of middleware optimised for supporting different kinds of distributed software development paradigms. Middleware was a technological concept.
But with the birth of the
application server concept in the late 1990s, which consolidated a lot of the popular distributed computing patterns of the time, together with the rise of web protocols and open-source alternatives to commercial web infrastructure, the idea of "middleware" changed fundamentally.
Now, when you see most of the talk about "middleware", "middle" means "the gap in a technology stack between an operating system and packaged applications". Middleware is now defined largely by vendors from a software product marketing perspective, rather than by customers from a technology perspective. Consider the portfolios of IBM, TIBCO, SAP, Oracle: they all talk about "middleware stacks", but these things include process management, content management, master data management, and business intelligence tools - and sometimes even DBMSs. [As a side-note, Microsoft is interesting because to an extent, it's gone in the opposite direction - building more and more "traditional middleware" capability and avoiding talking up the big stack.]
Why is the changing nature of middleware conversations important? Because, as I've mentioned before, the people and organisations that influence the language we use to describe things often end up in the best position to control what gets bought, by whom. By redefining "middleware" as being about ever-growing portfolios of infrastructure software, the biggest software vendors we have end up crowding out the propositions of smaller specialists.
So - should we reclaim "middleware", or should we just let it die a natural death?
Labels: architecture, industry, middleware
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
