Bernard Wheeler's Weblog

SOA Essentials - Part 2

The first element I shall cover of the six I have dubbed “SOA Essentials” is the Common Data Model. I'm aware that I could spark some disagreement here, but I'm stepping forward willingly...

One of the key benefits of SOA in my view is flexibility, so hold that thought...

In a SOA implementation there's a possibility, if not a racing certainty, that there will be a collection of disparate systems on heterogeneous platforms. Each of these systems on their own would most likely not even acknowledge each other's existence, let alone converse. But converse is exactly what they are required to do, so some common ground for the transfer of information between these systems is needed - and this is where the Common Data Model fits.

The purpose of this model is simply to have a consistent, platform-neutral way to represent key information so that it can be passed between participating systems throughout the SOA. By having the model in a platform neutral form, you reap a number of benefits including:

* for each new system/service added into the architecture, there is only one set of data translations/transformations that needs to be developed – from the “native” form of the new system into the Common Model and back.

* you avoid acquiring “spaghetti by stealth”, whereby unintended hard dependencies between services are created through the use of underlying “native” data representations from one or more of those systems/services. This helps yield that oh-so-important flexibility.

* if any of these services are eventually exposed to external organizations (e.g. partners, consortium members), you aren't also needlessly exposing information about the underlying platforms that might make them more at risk from malicious attack

* you don't need domain-expertise for each of the individual underlying platforms beyond creating (and extending) the original service capabilities and their “private” data translation pieces: once those components are created, you can combine and choreograph their interactions free from any requirement for specialist expertise of data types, formats, value limits, etc.

So where do you start?

Firstly, don't try to boil the ocean: you don't need to create a data model for the whole of your organization before you can do anything else. Be pragmatic and bear in mind Pareto's 80:20 rule. It's also unlikely that you'll be passing round every type of data entity within your organisation – and this model is for passing stuff around.

Also the data model isn't necessarily where you'd start your design efforts, but it'll be pretty early in your implementation task list. That's not unusual: most buildings are not designed from the foundations up – you start from creating the overall appearance given the context of its intended location and purpose and then go into the details of what rooms will go on what floor, where the boundaries of those rooms are, how things can pass between the various rooms and between floors and what common facilities are required where throughout the building. From there you can focus on the detail of the materials of construction of the various parts and then ensure that you have the appropriate underlying foundations designed to actually support the new edifice. Building order is different – typically (due to that thing called “gravity”) from the ground up. I have seen one building where the roof was put in place before the walls (it was held up with temporary scaffolding), but this was because of a) some peculiar attributes of the building site and access to it and b) some peculiar attributes of the builder!

The reason why I'm using the data model as my starting point here is because it pervades all the other essential elements, so it's best to describe it first for later clarity.

When starting to build such a model there is a spectrum of approaches, from the highly formal “let's build a full ontology”, to the highly pragmatic “let's examine the minimum that we need”. My advice here is that few organizations have either made or saved vast sums of money by having a fully complete, wall-to-wall data model or ontology in place. They are typically hideously expensive and contentious to set up, are unwieldy and can quickly fall out of date, and thence into disrepute and out of use. However, having a corporate-wide agreement on things like the representation of an address (number of lines, what goes on what line, line length, formatting, etc.) can yield very significant benefits in terms of data cleanliness, single-view-of-customer and ease of integration. So I prefer a mixture of minimalism and anticipation: do what you need now, but be aware of what you can reasonably expect to need in the future.

A thing to note here: as I indicated near the beginning of this piece, there is likely to be a mix of disparate systems in use within the complete architecture. They will be on different platforms and are likely to not all be object-aware. So I'm not saying build an object model. What I'm suggesting is what Martin Fowler calls an Anemic Domain Model – and he describes it as an anti-pattern – something to be avoided at all costs. But this view (I feel) is from a purely OO standpoint – and the whole world is not OO. So trying to attach 'behaviour' to the data extracted from a screen-scraper accessing a mainframe systems (so making it non-anemic) is to my mind an exercise in futility driven by a wish to ignore the realities of inter-system integration.

A word of warning: don't think that you will be able to finish your data model yet – even if you have a good grasp of your business activities and processes. It will need to be extended to cover operational (non-functional) aspects of the system, to which we will return at a later time.

There's also an argument that you need to develop (or at least use) two data models: one internally and one where services and capabilities are exposed externally. At the moment most people are simply focusing on trying to 'join the dots' and actually get a working SOA implementation rather than considering from the outset all the grown-up aspects like security and deliberate obfuscation. If you favour this approach (and I do by preference), then trying to settle on some industry-wide data model (if one exists) for your external view is probably going to be the best approach in the long run. That way, if you need to work in some kind of partnership, consortium or virtual organisation, there should be fewer politics over who's 'right' about the representation of a 'customer' when the various IT infrastructures need to be joined up.

SOA Essentials - Part 1

The various definitions of SOA and the discussions of the various benefits are not always tremendously helpful or illuminating when it comes to answer the question of “so what do I need to put in place to achieve one”. So that's what I've decided to start to cover over the coming days.

The usual disclaimer applies: this is my set of opinions, and there will be other opinions expressed elsewhere. However, they are based on 20+ years in the software industry, both on the supplier and consumer side, with multi-tier, distributed systems being a focus for just over 10 of those years (and counting).

There's a graphic that has becoming almost a de facto standard in SOA presentations. It shows a four-layer model, those four layers being (starting at the bottom) Data Layer, Service Layer, Process Layer and Presentation Layer, something like this:

Now having a layered model is nothing startling and it's been with us for years: 'monolithic', host-based computing fitted a single layer; client/server extended that into two layers, largely in conjunction with the advent of a 'standardised' way to access data – SQL; then there followed a wider push to three layers – data, business logic and presentation, driven originally by technologies such as DCE, CORBA, DCOM and the maturing of development disciplines around OO, patterns and the like.

So SOA introduces a couple of distinctions:

1. The “business logic” layer is further categorised into 'processes' (the sequencing and orchestration of actions to achieve something of measurable value) and 'services' (the encapsulation of business functionality into components that can be accessed in a consistent way). This separation of processes and services leads to the second distinction.

2. The layers should not stop at application boundaries: any and all applications ('processes') that wish to access a specific set of functionality should do so by using the same, shareable service

Examining the impact of the second distinction shows that the translation of functionality into services must also include aspects of security and self-protection, since the service cannot determine ahead of time who is attempting an access, and whether they are attempting to do so in a well-behaved manner. This is a point that I'll return to some time later.

Whilst I consider this four-layer model a reasonable start, I think it is still too simplistic and can actually encourage problems later.

To illustrate this, let's take the Data Layer. What goes into it? Is it just the actual corporate data itself? Is it an object Domain Model, so that the there's some functionality encapsulated in there? Or is it the same content that was in the three-layer model, such as object-relational mapping, Java Entity beans and their alternatives, etc.? And how are those those things accessed? Where do you draw the boundary between the Data Layer and the Service layer that's the next one up? And if you're using some external functionality, such as a credit rating service, does that fit in the Data Layer (because you're retrieving credit rating data), or in the Service Layer (because it's a “service”).

Therefore, when speaking with people about SOA I introduce this picture, but then I change some of the names (you'll see why) and I supplement it with two 'vertical' elements that interact with each of those four 'horizontal' layers, those two elements being:

1. A common, system- and platform-independent model for representing data that is transferred between and within the layers. By using this approach, each different source and sink of data, functionality and events that is added to the environment need only have one set of data translation functionality developed, i.e. from its 'native' form into the common model. This eliminates any inter-system dependencies based on data formats.

2. A common set of 'framework' services that will underpin the operation of the functionality in all of the layers, those framework services to include such things as auditing, exception/violation reporting, the collection of performance data and other operational metrics, the management of operational events and configuration parameters, etc.

So my picture looks like this:

So what I intend to do, is go through each of these six pieces in turn to outline what I consider to be some of the defining characteristics of each and why I consider them essential to the formation of a successful implementation of a service-oriented architecture.

But as a teaser, I shall explain that my Technical Platform layer is the layer that wraps all systems where there is an element of integration work to be performed, such as data transformation, connection into external and/or legacy systems, etc. So the access to a database and the access to a credit rating service would both go in the Technical Platform layer.

As it happens, SeeBeyond has a similar view of the SOA world, so I'm not alone here.

There's more to come – soon, I promise!

Just to brighten things up...

A picture of some daffodils from the garden:

In praise of the 1GB MiniDisk

Last year I bought my third Sony MiniDisk player, a MZ-NH700. A third? Well the first was a straight MD-LP (4 CDs on a single disk) Walkman, which led me to get a non-portable one to attach to my Bose setup at home (my wife didn't want “big black speakers messing up the decor” and since the Bose has small, white, ceiling-mountable speakers, it was an easy decision...).

The third came about because although my first MD Walkman had a PC connection, transfers were done in real-time. So putting 5 hours of music onto a disk would take 5 hours. Which was highly frustrating, because various bits of software (Real, the Sony SonicStage stuff, etc.) could rip CDs onto my PC a lot faster. So the PC connection wasn't really that useful in the end (since I haven't ventured into the iTunes^TM world yet and only listen to stuff I have on CD or vinyl).

The new MD is a lot smarter. For a start, it can cope with Sony's 1GB disks and secondly it actually has a useful USB connection and transfers are basically like putting stuff onto a flash drive (and the PC sees the 1GB disk as an additional drive if you want to transfer data/pictures and not just use it as a music device). And since the 1GB disks are now available through Amazon at 5 pounds a time, it's not an expensive option either.

Sony claim that you can put 45 CDs onto a single disk. Well, to test this out – and what the music quality is like at that level of compression, I've actually put 48 CDs and 2 CD singles on a disk. Admittedly, the disk lengths range from 33 minutes (Getz/Gilberto) to just under 1 hour 15 minutes (Bach: The Well-Tempered Clavier, Book II - 24 Preludes And Fugues, Disc 2), but that's still an impressive amount of music to fit on 5 pounds-worth of small, pretty rugged, portable media.

And the music quality? I listen using Sony's MDR-EX71 headphones and on the compression/sample rate to get that amount of music on the disk (48kbps ATRAC3plus) it's quite frankly astounding – bearing in mind that I'm getting towards the age when my hearing's not what it was and I'm not pretending to have 'professional reviewer quality audio' abilities, but I defy anyone to have a serious complaint about the sound that comes out of this portable device.

Another thing that really appeals – and steered me away from the iPod/MP3 player route is the battery life (60+ hours) and the fact that the player I (deliberately) chose takes standard 'AA' size batteries. So I don't have to cart around a charging cradle, power adapter, etc. when I'm travelling – I just take one spare battery and know that wherever I am in the world I'll be able to get some more in the nearest drugstore or supermarket.

So if you're in the “iPod or another approach” situation, I can highly recommend the Sony NetMD technology - even at the highest compression/lowest sample rates.

So what have I put on that disk (and I have others to fill too...)? Well I shan't list the full 50, but here's a selection of titles I can highly recommend:

• apart from the Getz/Gilberto, there's also Jazz Samba and Jazz Samba Encore, both Getz collaborations in the same vein

• Miles Davis' absolutely classic Kind of Blue and Birth of the Cool

• both of the books (4 CDs) of Bach's ground-breaking Well Tempered Clavier – originally written to prove that the newly invented piano could handle tunes in any key – its main innovation at the time over the tuning of keyboard instruments used until that point (and the first piece in the first book is possibly the most beautiful piece of music ever written). The recordings I have are performed by Jeno Jando

• Ludovico Einaudi's Le Onde – very soothing

• Lemonjelly's lemonjelly.ky and Lost Horizons – both obviously recent favourites in the BBC's factual programming section, as they feature repeatedly as backing music

• Massive Attack's 100^th Window – sadly overlooked in awards, but nevertheless superb

• the 'usual' fare of Keane's Hopes and Tears, and Coldplay's Parachutes and A Rush of Blood to the Head – 'usual' not meaning ordinary

• Zero7's When It Falls, and also their compilation for the AnotherLateNight series (there's also Fila Brazillia's similar offering on the disk)

• Radiohead's The Bends – I think their best work

• Muse's Absolution – just wonderful

That's it for now, although I may return to music topics at a later date, just to report on what I'm listening to as the days pass.

Using the RIGHT services in SOA

I was in an interesting discussion with Warren Buckley, CTO from PolarLake yesterday. He was going though an update on their technology and positioning with me and a few colleagues in one of Sun's London offices. What he said prompted a number of trains of thought about SOA implementations and some potential pitfalls that are so glaringly obvious as to be easily overlooked.

One of the repeating themes in discussions about 'effective SOA' is the matter of granularity of services: make it too fine-grained and you (or rather, the business) will have a hard time threading all the many bits together in the right sequence without forgetting to add in all the key steps; make it to coarse-grained and you'll find yourself creating a new set of services for each new application variation, because the services you have are too specific to enable re-use.

But we touched on something that I don't believe has had a sufficient airtime to date.

It is generally agreed among those that participate in such conversations that the services exposed to orchestration – and therefore the main 'components' used to build up composite applications are themselves going to be composite pieces of functionality. All well and good, but what paradigm do you use for the construction of those composite services? If the answer is that you want to employ re-usable services for that too, then there's a question that needs to be asked: what mechanism are you going to use to enforce the orchestration piece not to be able to use your lower-level services and only use the composite ones that you originally intended?

I'll use an example loosely based on a real situation: a finance organisation has built up to its current size by both organic growth and a number of acquisitions. As a result, some of its business units still effectively act as autonomous units IT-wise (and financial legislation dictates that to some extent this must remain so), but the institution as a whole wants to enable its customers to see and manage their overall portfolio through a single view. To handle this situation, the institution has rolled out the concept of service 'domains', where functionality available from a business unit is formally described at its boundaries and the internal workings of how that is achieved is at the discretion of each business unit. This matches the profile of a SOA approach, so it's so far, so good. Now the Home Loan group publishes a service at this boundary point for “get loan balance”, but they also have an “internal” service (say, “get loan balance from mainframe”) that actually goes to the specific system that holds the home loan data - in the “Data” layer, rather than the “Service” layer of the typical 4-layer SOA model. A developer has been transferred out of the Home Loan group into the main corporate group and thinks he'll use the service that minimises “service-hops” and goes straight for the data-layer service. Now that may not be what's intended, but after all, it's published as a service, and who's going to spot it?

Now in the OO world (to which SOA is often likened), there are distinctions of public, protected and private. And there are things called packages that may be equated onto the service 'domain' concept that the finance institution has implemented. But at the moment, equating is all that we can do. There is currently no mechanism to enforce this model. (There are many, many other qualifiers that can be used in OO and may have a useful equivalent in SOA, but that's not the topic of today's ramblings.)

I wondered (during the aforementioned discussion) whether this is something that will eventually work its way into the policy-related specs and technologies, but these still seem to be a little way off in terms of widespread consistent adoption and implementation. And on reflection, a better way to implement this kind of control is to (again) follow the lead and place the qualifier in the declaration – which in the case of a SOA implementation based on web services would mean putting it in the WSDL for each web service. But in my (admittedly far from encyclopedic) knowledge of WSDL, I don't recall equivalents of private, public and protected. And it's not a run-time permissions thing (so it's not WS-Security, SAML, or the like), it's a define/design-time 'exposure' thing...

So since WSDL doesn't help here, a way to achieve this (in my opinion) necessary enforcement, would be to start segmenting your service 'domains' so that they each had a separate registry with different look-up coverage. But that introduces the likelihood of data duplication of service definitions in more than one look-up registry, something that would be really nice to avoid. But at the moment this is likely to be the only realistic way of managing external access to services by third-party organisations (although PolarLake discussed a case where they have essentially implemented a reverse proxy for service access which would also be effective, and possibly more heavyweight).

So SOA – even a highly standards-based implementation – has the capability for creating just as much of a 'service spaghetti' as any other kind of software construction – and doesn't currently have several of the mechanisms found elsewhere to try to encourage and enforce good discipline. Exposing data-level, platform-specific functionality as services may follow the intent of SOA to the letter and will probably allow greater flexibility, isolation and 'agility' in being able to upgrade, replace or consolidate back-end systems without affecting your shiny new composite apps. But there needs to be a mechanism or procedure that checks and enforces that these lower-level services are not being called inappropriately, causing unforeseen 'hard wired' cross-links to appear where you thought they couldn't. But there isn't (to my knowledge) any such kind of automatic mechanism or procedure.

Which means that there's likely to be some very expensive almighty mess-ups made if the right level of discipline and forethought isn't consistently applied by the design and implementation teams. But it was always thus, and as has been said about SOA before: “the rules of physics still apply”.

Are we all missing an easy win here?

What's the clearest distinction between managers and leaders? This has been a topic of debate for many years, involving many people more learned than I in this subject area. However, having been in the workplace for over 20 years, I think I'm qualified to make some observations based on personal experience.

A piece of that experience that brought one of the key differences into stark relief for me was the recent CEC 2005 internal Sun conference, held in San Francisco at the end of February. This is where thousands of Sun 'technical' staff are brought together (pre-sales, proserve, tech support, engineering, technical marketing). It's an incredibly valuable part of Sun's cultural physiology, enabling people to a) feel that their value is noticed, b) get a broad picture of the “shape” of Sun and its internal emphasis on hardware vs. software vs. other innovation in the quest to solve customer problems, and c) listen to and exchange ideas, experiences, etc. with other like-minded enthusiasts.

One of the features of these conferences is that we get keynotes from various SVPs that are driving the key big sections of Sun. We also get “State of the Union” sessions from the people that are spearheading each person's particular technical community (the only time such a separation into "communities" is made). It was this collection of sessions that made the clearest distinction between managers and leaders only too visible.

That distinction? Inspiration.

As you'd expect (and I'd be worried if it weren't the case), Jonathan, Scott and Greg P all passed the test. They (individually and collectively) inspired a) faith in their ability to spearhead where Sun's going, b) confidence that we've got the right vision for where we're headed and c) enthusiasm to continue “doing the right stuff” because we're making great progress towards that vision.

However, some (but not all) of the other people in “leadership” positions (SVPs) would have scored poorly in an 'Inspiration Quotient' test. Now let me make two things clear:

1. I am in no way questioning anyone's ability to manage efficiently , to delegate, carry authority, or any such quality. I'm only talking about answering the question “Was I inspired by that?”

2. Sun is in no way unique in this profile. Most of the companies I have worked for would have a similar scorecard. (But that doesn't make it right.)

It's not just at conferences when this is visible: in a company such as Sun, where computing technology is a large part of its DNA, we get quite a lot of e-communications from the various leadership levels on a regular basis. And whilst they're typically concise and informative, “inspirational” is not a word that would normally spring to mind.

And this is where I think Sun (together with all those other companies) is missing a HUGE easy win.

Let's face reality: Sun (and a lot of the industry) is still in recovery mode following the burst of the dot-com bubble - but at least we're still here recovering. In my opinion it is exactly at this time when an inspired workforce can have a massive advantage over one that's ambivalent.

And they say that success is “1% inspiration, 99% perspiration”. My experience is that without the 1%, you're highly unlikely to get the full 99%. The question is: who's ensuring that the inspiration happens?

For Scott and Jonathan it happens as a matter of course – and to my mind it's no coincidence that they have their current roles. Others may have to focus a bit more to make it happen, but it's worth the extra work. What I'd like to see is for the next 6 months every communication out from VP level (at least SVP) and higher are checked before sending for their 'inspiration quotient' – the answer to the question “would this inspire me if I read/heard/saw it?”. If it fails, that communication needs to be re-thought and re-presented.

But why stop at VPs? (Well, they should all be doing it, because they're getting paid to perform leadership roles.) People in customer-facing roles (especially sales and pre-sales) would also do well to check whether they're inspiring their customers. You'll probably find that there's quite a link between the level to which they're inspired and how happy they are.

And why stop at 6 months? Well, we needn't stop then. But 6 months of just ensuring that inspiration is being spread daily, weekly, should see a marked difference. And if not, what's been lost – how much will it have cost? Less than a free puppy, that's for sure.

So if you ever catch yourself wondering whether you're doing the best that you can for your company (or your family for that matter), go inspire someone. You'll probably find it working on yourself too.

SOA = BOA ?
We all know the potential for something of value to be lost beneath hype, hype-backlash, bandwagon-hijacking, "not invented here" syndrome and the like. This applies as much here in the UK as anywhere else world-wide and I have a growing concern that some of the key points of potential value for SOA are starting to get obscured under some of these effects.

First things first: what do I mean by SOA. Well, the best analogy I've seen (and to my mind it is superb) was put forward by a fellow Sun employee, Thomas Limanek (who, as it happens, contributed to some of the ebXML specs).

Tom's analogy in a nutshell and extended here by my own whim is this (and apologies to Tom for any misrepresentations):

• the traditional relationship between business and IT is like having a personal chef: you (the business) can dictate what you want to eat, or take menu recommendations, but your chef (the IT department) only buys supplies according to the pre-agreed menu. You play no part in how the food is bought, cooked, etc., but you pay the whole cost for the chef, cooking fuel, food and all the waste from each meal. In addition, if you suddenly change your mind about what you want to eat, there's unlikely to be an alternative meal ready in a short time - apart from re-cooked leftovers.
  
  
• using commodity-off-the-shelf (COTS) software is more like eating in a restaurant: there's typically less flexibility available to you in the actual make-up of the dishes and the more customisation you want, the more it'll cost. But you share the costs of the chef, facilities, etc. among other restaurant-goers - reaping some benefits from the 'economies of scale' of the restaurant. Furthermore, if you change your mind about what you want just before ordering (e.g. pizza vs. pasta), there's probably a reasonable alternative that can be available in an acceptable amount of time. But if you want to include a totally different culture or flavour (e.g. vegetable tempura as a starter), you may have to visit more than one 'restaurant' and figure out for yourself the logistics of how the 'meal' as a whole is going to be achieved. Also, there's nothing to stop the restaurant from suddenly hiking up their prices, radically changing their menu, or being bought out by a bigger chain who then 'trashes' your preferred meal.
  
  
• SOA is like eating at a buffet: the chef (either private or shared) prepares a range of dishes from which you build your own meal. The meal you choose does not require the whole ensemble to be put together 'in the kitchen': rather, the chef focuses solely on ensuring that there is an appropriate range of dishes provided in the buffet to keep most people happy for most of the time, based on market demand, season (and other prevailing conditions), consumer feedback/requests/suggestions, etc. And if the cost of any item changes dramatically (or there's an ingredient shortage, "food scare", or some other reason to change a menu choice), you don't have to change your whole meal, just that one piece of it (although granted, it may be the centrepiece of the meal).
  
  

Hence the title of this piece (BOA = 'Buffet Oriented Architecture'). I think this is an excellent analogy, because amongst other things it helps to illustrate that:

1. a main thrust of SOA is business agility (consumer able to make their own selections) as opposed to IT agility (ability to respond to requests more quickly).
   
   
2. IT agility is important too - business won't want to wait as long for just one new component (dish, service) to be produced as they did for the whole 'meal' before - and their impatience will only grow.
   
   
3. there is a responsibility upon IT to offer a palatable and useful range of services, including 'staple items' that will be included in almost every selection.
   
   
4. some of the initial difficulties in migrating to SOA: if you just serve up the same stuff (food, services), but in a different form (buffet vs. a la carte, SOA vs. stove-pipe), the customer will wonder why the heck you bothered with the transformation. They just get the same end result, but they have to put more effort in too.
   
   
5. if you're exposing stuff into a "public space" there are various security, hygiene, monitoring, etc. considerations that you need to consider. Otherwise you'll get someone in off the street carrying a bowl, taking all of the olive, tomato and basil pasta, sneezing on the rest of the buffet and then walking out without paying. And you can't expect the consumers to choose or enforce these as options.
   
   
6. there is a need for appropriate granularity: you want to avoid the smallest portion size being a whole roast chicken.
   
   
7. for the more popular 'dishes', you'll need more capacity not only in production quantity, but also in the ability for people to access them.
   
   
8. if you want people to always have a specific item, you'd better mix it into each menu option you give, pre-load the buffet bowls/plates, or move to a "we serve you" buffet model (a 'halfway-house model, which means that you will need to factor in the hiring of serving staff, their cost, their throughput capabilities, etc.)
   
   
9. each dish can more easily be put under scrutiny - independent of all others - to isolate the efficiencies and difficulties of provision - is the volume such that outsourcing makes sense, does it take an inordinate amount of resource for the popularity and benefit it gives?
   
   
10. you cannot implement this without participation on both sides: if the business just (metaphorically) sits at the table demanding food and refuses to step up to the buffet, you're going to have an unhappy business (and frustrated culinary staff)
    
    

I think I could spend hours extending and exploring this analogy, but I think I've covered enough of the main points for today.

So what do I think is getting obscured? Well, the main issue is that people are routinely confusing business agility and IT agility. Sure, they're coupled, but potentially loosely so: you still need IT agility to create the new services in a timely manner, but if the business decides to change its selection list and create a new 'combo-special', its ability to do so need not be restricted by IT's ability to join all the stuff together - especially if you can achieve serve-yourself as opposed to we-serve-you.

And yes, I know I'm talking about 'utopia' here, but when else other than at the start of a paradigm shift is a better time to consider ultimate possibilities?

Another aspect that gets hidden is the fact that unless something measurably beneficial for the business is planned for and delivered along with the move to SOA, they will be supremely 'underwhelmed' by the achievement. "Same food, different delivery" is not going to cut it on its own.

So is SOA for everyone? Well, if the business is only ever going to order the same menu, you'd better find some pretty good reasons for selling the idea of a buffet rather than the 'served at your table' set-up.

I think that's enough for one day of blogging. And I'm starting to get hungry...