Archive for the ‘architecture’ Category

« Older Entries

Running IT as a business: don’t be daft

Thursday, January 21st, 2010

In the past couple of days I’ve read a couple of articles (”IT can’t be a service provider and a partner too” and “Run IT as a business – why that’s a train wreck waiting to happen“) that riff on the same theme: that the exhortation to “run IT as a business” leads you down a road to organisational exile.

Put briefly, the thinking seems to be: if you set an IT organisation up to run as a business, you create a supplier-customer relationship with other parts of your wider organisation – and this relegates you to being a simple order taker. You’ll have to implement the requirements you’re given, and often these will be out of whack with what the organisation will really need and will raise IT costs over the long term, making an internal IT operation even less attractive and making you more likely to be outsourced.

In my experience this analysis is plain wrong, and comes from simplistic thinking about what the phrase “run X as a business” might mean. Being more business-focused has multiple facets to it, and blindly interpreting the idea leads you to daft, simplistic conclusions. Applying similar thinking to cooking would lead to the advice “don’t use sharp knives; if you do that it’ll only be a matter of time before you chop a hand off”.

To be clear: my experience and advice diverges with these other opinions not because I disagree about the risks of IT becoming a “simple order-taker”; but rather because I disagree that running IT as a business means you have to become a simple order-taker and everything else is excluded. There’s much more to it than that. The key is to see the relationship between IT and other areas of a business as having three key layers.

When I look at IT leaders who have really become strategic players at board level (and I’ve been talking to them ever since my work on The Technology Garden), it’s not the case that their organisations have stopped becoming service-focused and focus wholly on hanging out with senior business managers. If anything their organisations are more service-focused than the norm.

In the best-performing organisations, the “run IT as a business” idea is primarily about an inward-looking perspective. It’s about putting repeatable processes in place, creating a service culture, figuring out the actual costs of delivering IT services through IT processes, and looking for ways to increase IT process efficiency and effectiveness.

In high-performing IT organisations, when it comes to the outward-looking perspective (the relationship between the IT organisation and other parts of a business) the relationship has at least three layers:

  1. As a foundation, IT teams have to deliver reliable operational services in line with clear promises and in the context of defined cost expectations and budgets.
  2. When it comes to using IT to enable business in new ways the relationship works at a higher level, using different teams, reporting structures, skills and incentives within multidisciplinary joint IT-business teams.
  3. The top layer acts to mitigate the risks of individual business units driving change that is counterproductive to the organisation as a whole, typically through some kind of IT governance structure that helps to ensure that significant IT investments are considered in their proper strategic context and that the costs and risks are properly understood by all.

That’s three layers: IT operation/service delivery; IT-business engagement; and governance/strategy. You can be focused on service provision and also on partnering. As long as you understand the bigger picture.

Posted in alignment, architecture, governance, inside-out IT, outsourcing | 2 Comments »

Interview on IASA, the value of architecture, and Cloud Computing

Monday, November 2nd, 2009

While I was at IASA’s ITARC NYC the other week, Matt Deacon (day job: developer/architect evangelist for Microsoft in the UK; evening job: UK Chapter President of IASA) interviewed me about my thoughts on the value of architecture, the role of IASA and also about the talk I gave at the event.

The talk I gave was on a recent survey we completed in association with IASA – focused on architects’ experiences of, and views on, Cloud Computing. In the second half of the interview Matt talks to me about some of the early findings from that survey.

The video interview with Matt and me is about 21 minutes long, and it’s published on Microsoft’s Channel 9. I think the discussion turned out pretty well, though I say so myself… Matt has also published an interview with the SEI’s Len Bass from the same conference btw, and that’s worth a look, definitely.

The full survey findings will be published as part of our new Software Delivery advisory service, which we’ll be launching this month. If you’re an enterprise IT practitioner and you’d like to find out more about the service here’s something for you; if you work for an IT vendor organisation, here’s some information for you.

I’d love to get feedback from you if you have time to sit through the interview… what did you think?

Posted in IASA, architecture, cloud computing | No Comments »

IASA: making architecture work

Monday, October 19th, 2009

Last week I spent three days in Manhattan, attending the International Association of Software Architects (IASA)’s IT Architecture Regional Conference (ITARC) in NY. That’s a long time for me to be anywhere – so why did I do it?

The first answer is the speaker lineup – there were keynotes from Len Bass of Carnegie-Mellon’s SEI; Grady Booch (IBM Fellow and self-styled “Free Radical”); John Zachman (yes, that one); Eric Evans (the champion of Domain Driven Design); and Angela Yochem (one of IASA’s Fellows – perhaps not as widely-known, but certainly just as important as the others – see here). I thought I might pick up some interesting tidbits..

The second answer is that I was scheduled to present the findings of MWD’s recent survey conducted in partnership with the IASA – looking at how IT architects are approaching the subject of Cloud Computing (we’ll publish a report detailing the findings in November). Here, I thought I might be able to share some interesting tidbits…

Having let what I heard and saw at the ITARC event sink in for a few days, I have a lot I want to write – much of it will have to wait for future blog posts. Here, I’d like to concentrate on my overall feelings about IASA, after spending 3 days pretty deeply “embedded” with many of its leaders.

1. IASA has a big ambition – to create a global professional body for IT architects. There’s still a lot of work to do, but the level of drive and momentum within the body is very very impressive. Being able to get the above people to hang around a conference for 3 days is a difficult task: the fact they did so is a fantastic validation of IASA’s vision and passion.

2. The issue that kept popping up in hallway conversations and during breaks, as well as in many of the sessions, was how to demonstrate the value of IT architecture to other stakeholders (business sponsors of IT investments, other parts of IT organisations, and so on). What was interesting to me was that although a number of the speakers touched on various aspects of this issue and how to address it, there’s no “place to go” to find a coherent body of advice to those struggling with it. Or if there is, no-one seemed to know about it. There obviously is an answer (or at least, a set of working principles) – I saw a lot of good advice being presented – but curating this body of knowledge and crystallising it is something that IASA needs to make a priority.

3. There’s still a lot of uncertainty in architecture circles about the “right” relationship between enterprise architecture and software/solutions/system architecture. Are the two disciplines actually two parts of the same discipline? Are there any connections between them? Where do they overlap? What can each group learn from the other? Despite very definite views from some of the IASA leaders, it’s clear that other senior figures have other views – my feeling is that this one still isn’t resolved.

I always suspected that IASA was an important industry organisation – and following the event, I feel doubly sure about that. It’s easy to malign IT architecture as a discipline that’s overly introspective and navel-gazing, and to deride IT architects as uber-geeks with more interest in tools and techniques than delivering business value. There are certainly examples of this behaviour that we can all probably recount. But it’s clear to me that IASA is determined to help IT architecture professionalise, and maximise the value that architects deliver to internal and external customers.

I heard a lot of really great stories at ITARC NY about how IT architecture, done right, can deliver real value. Now more than ever, as organisations become saturated with IT, architecture practice is vital if organisations are to minimise the cost and risk associated with change, and maximise business flexibility. Nevertheless, as IASA’s CEO Paul Preiss pointed out in his update talk focusing on the IASA’s new certification programme, “today, my hairdresser needs to have more in the way of certification than an IT architect typically does”. That’s a sobering thought.

IASA is on a journey and there’s a way to go – but if you’re an IT or enterprise architect, or would like to find out more about what they think and do, then I would urge you to explore what they’re up to.

Posted in EA, IASA, Uncategorized, architecture, business value | No Comments »

What are IT architects’ experiences of Cloud Computing?

Friday, September 11th, 2009

We all know that the general level of industry interest in Cloud Computing is high – but how much is Cloud Computing being actively considered and pursued by “enterprise IT” organisations, as opposed to software-as-a-service startups and professional ISVs moving to the SaaS model?

To help support the launch of our new Software Delivery advisory service – which at launch will feature several advisory reports focused on the potential impact of Cloud Computing – we decided to ask the members of the IASA what they’re thinking and doing about Cloud Computing.

As I’ve mentioned before we have an ongoing research relationship with this not-for-profit global association of IT Architects (which today has around 25,000 members across a variety of industries). As in our summer BPM study, we’ve worked together with IASA 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 Cloud Computing 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…

Lastly – if you’re interested in finding out more about the new Software Delivery service we’re readying for launch, please take a look at the brochures featured on our home page.

Posted in IASA, architecture, cloud computing, survey, webinar | No Comments »

Is there room for architects and architecture in BPM?

Thursday, April 9th, 2009

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…

Posted in BPM, IASA, architecture, survey, webinar | 1 Comment »

Why we need ALM: industry's dangerous flirtation with software quality

Friday, March 20th, 2009

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.

Posted in ALM, Software Quality, architecture, development | No Comments »

Cloud computing, SaaS and SOA – the universal service network

Monday, February 23rd, 2009

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.

Posted in ITSM, SOA, SaaS, architecture, cloud computing, service | No Comments »

Schrödinger's SOA

Thursday, January 8th, 2009

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:

  1. The majority of SOA projects have failed to deliver what they promised.
  2. Business people are disillusioned with SOA.
  3. “SOA projects” will be killed by today’s difficult economic conditions.
  4. 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.

Posted in SOA, architecture, hype | 4 Comments »

The death of middleware

Thursday, November 6th, 2008

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?

Posted in architecture, industry, middleware | 2 Comments »

More big vs small thinking: SOA vs BPM

Thursday, July 26th, 2007

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.”

Posted in BPM, Pegasystems, SOA, architecture | 2 Comments »

« Older Entries