Define SOA without S, O or A

I was given a challenge today to define SOA without using the terms "Service" "Oriented" or "Architecture". What I came up with was

Its a way of modelling what a business does, then understanding who it works with and why the business works with those external parties and the different parts of itself.

Now I need to get it shorter and crisper, but I prefer that to "a style of software architecture" which doesn't really help anyone.

Technorati Tags: SOA, Service Architecture

Why Service SLA depends on consumers as much as producers (Sandisk Ultra II v Extreme III)

One of the bits that is often over looked in SOA is the importance of the consumer to an overall SLA for a service (after all the SLA is there to give the consumer assurance). I've been looking for a good example of what I mean and today I found it. I have a Canon EOS 350D, the old entry level digital camera, which is perfect for what I need. I've got 3 different brands of memory cards, all of which publish their performance SLAs. The two that interest me here though are the SanDisk Ultra II and SanDisk Extreme III. The later claims a minimum write speed twice that of the former. However if you lob it into my camera, set it on manual with a 1/4000 shutter speed and then hold down the button for 1 minute you get exactly the same number of shots out. This indicates that the issue isn't with the speed of the memory cards to determine overall performance but the speed of the camera in writing to the memory.

So here we have two services which have identical (one could say "uniform" :) ) interfaces but offer two different SLAs to consumers, these SLAs however place requirements on their consumers in order to be able to deliver the SLAs as advertised.

The point here is that a service cannot offer an SLA that reaches outside of its bounds without also placing direct requirements onto its consumers. Thus a true SLA is not simply something a service describes but is something that is negotiated between the producer and consumer for a given interaction.

Published SLAs are just the tip of the iceberg when it comes to delivering truly effective business SLAs that can be relied upon.

Technorati Tags: SOA, Service Architecture

SOA needs marketing

Communication is "The transmission of information so that the recipient understands what the sender intends." too often people in SOA projects appear to be making the same mistake that HR departments make on a regular basis, namely assuming that lobbing something onto an intranet page and acting surprised when nobody reads it.

Now I talked a while back about Selling SOA to the Business and how it was selling. Well guess what, the think about trying to communicate your SOA strategy, service repository, service or whatever is... a marketing job. You've got to think about it as a core part of your SOA approach and develop an actual marketing plan.

Bleating about people not reading documents on an intranet page (often with a helpful internal page name like /12345ofq.htm) is just dumb and people who expect that publishing an intranet page is enough should be quickly shot for their blind optimism or laziness.

Develop a communication strategy, develop a marketing plan. Work out which people you need to talk to directly and which can be done via email and who will just get a link to an intranet page. Go and speak to your corporate comms team, find out from them what can be done, a section on the intranet, a podcast, posters or inclusion in monthly briefings. Plan the launch as if you are going to market, because that is exactly what you are doing you are going to your market, its internal but that doesn't mean it shouldn't be treated in the same way.

Then once you have done your launch keep it up, its no good to have a big splash if everyone forgets about it in 3 months. Keep on the active communication front, have something on the intranet home page that just says how many services there are, how many users, how much money has been saved or whatever metric will get it noticed. Have a continual update that is easy and interesting for people to engage with.

The more I see companies struggling to communicate and then complaining when people don't come to the limited comms they've put up the more I think that SOA Marketing is becoming more and more important and that people in SOA programmes should start considering allocating marketing budgets as a core part of their operation.

Technorati Tags: SOA, Service Architecture

Why SOA is different

I've often said that if SOA is about technology then its another minor IT improvement that won't deliver a fraction of the benefit that the hype promises.

So why do I think that SOA is different from the way most people architect IT solutions and why do I think it will have an impact?

Because simply put I think that SOA is about changing the way people think, its about making them think about Business Services and being focused on business objectives first, and technology objectives second.

OO was a shift because it changed the way people thought away from procedures (processes) towards objects which had both data and behaviour. SOA is a much bigger change than that as it works at the enterprise and business levels and represents what a business does, who they interact with and why these services interact.

SOA is different because it changes the way people think about ITs place in the Business. If it doesn't then its just another developer inspired Silver Bullet which will crash against the rocks of reality.

Simply put, if you attack problems in the same way with new technologies, be it REST or WS-*, then you are a muppet if you expect a better result.

Technorati Tags: SOA, Service Architecture

Le Tour SOA - why support services are critical, but not important

One of the biggest mistakes that IT makes is confusing "critical" with "important". What I mean by this is that IT often thinks that just because the failure of a service or application has major ramifications for the business that the application is also important to the business.

There are lots of applications and services that fall into this sort of category and the way to understand whether something is "important" or just "critical" is to look at what happens when it goes away

When a critical service fails, or is removed, then it has a massive impact on the operation of other services, work arounds are needed and contingency plans are brought in. People really notice it when it isn't there.

Important services however are noticed when they are there they are the reason that the other services exist. If the Important service goes away then there is no point the other services continuing.

In other words Critical is about operations and Important is about business value.

To take this further I'll use the Tour de France which yesterday popped through the UK as an example of the difference.

About 1-2 hours before the race comes through the village there is the "caravan" these are the sponsors cars which dish out freebies to the crowd and are basically engaged in advertising. These are clearly support services, they aren't important to the race... well except that the sponsors give money and without the money the tour would be a much smaller event. So here we have a certain level of criticality for a support service, it clearly has an impact on the overall system but no-one would argue it is "important".

Next up comes the police, camera men and assorted random cars that must have some support job, but again its only support.

Then came the leading bunch of 5 riders, with a Brit in it, followed 5 minutes later by the pelaton. This is the important bit, without those riders then all of the other services, no matter how important, are pointless. There is no tour de France without the riders.

Following them are the teams with the spare bikes, liquids and the like, clearly these things are essential for any rider who wants to complete, let alone win, the race. If they went away then it would be practically impossible for a rider to compete, these are therefore critical support services. Their failure has a massive detrimental impact on the main business service (the riders).

In business the same applies, the phone system and electricity are "critical" to a modern business, but they are not "important", they are a relied upon commodity whose service level is important but which is not expected to create value. The same can be said of many things, HR, Procurement and often IT, and it is certainly true of IT systems. One of the big SaaS drivers is that these new solutions offer an answer to the "critical" question, while not requiring the costs of "important". Too often internal IT create critical systems whose costs far out weight the costs of truly important business services, indeed often these back-office critical elements suck the vast majority of the IT budget away leaving very little to deliver new innovation.

To really build a business case and deliver value from SOA its essential that IT takes an honest and pragmatic view on its current estate and differentiates the support service from the business services and the critical from the important.

So is that application you have been looking at one of the riders? The team support? Or just the people at the front giving away key-rings?

Technorati Tags: SOA,SaaS, Service Architecture

How not to do SOA

JBI 2.0 has kicked off, and the big debate is how to work with SCA. The first thing to understand about JBI is what it is for. Its all about making sure that different pieces of technology infrastructure can communicate with each other and that you can replace these bits independently of each other and everything will still work.

To me this is why SCA (which should focus on the application side IMO) and JBI should work well together. One group focuses on end-users (SCA) the other focuses on getting the vendors to work together (JBI).

Now down to the title, why is JBI important? Or more abstractly why is it important to have this sort of infrastructure approach? Well thanks to the folks over at Microsoft I've got a nice little example of what happens if you tightly bind things and make assumptions about what else already exists.

In Office 2003 one of the things that I used, a lot, was the "speech to text" converter. I write quite a bit of content as part of my job and I sometimes find it easier to get a first draft down by "presenting" it, then sitting down and editing it to make it shorter and flowing.

In Office 2007 however this functionality has been removed because Vista (an operating system) has voice functionality in it. Hang on, to get the same functionality I need to upgrade BOTH Office and my operating system? Surely some mistake? Nope, its true, in order to "upgrade" Office 2003 to Office 2007 and keep the voice functionality you have to also upgrade the operating system from XP to Vista.

Simply put, that is crap. In a decent SOA system you'd have considered speech to text recognition as a "service" that could be called from anything that needed it. Thus if I have Office 2003 installed I could then have used speech to text in notepad, after all what does a speech service do? It has an input (microphone) and outputs text. Its hard to image something that is easier to design and implement as a service than something like a speech->text converter.

Then when I upgraded to Office 2007 it could have gone "hey look, this is Windows XP, we'd better keep the voice service from Office 2003, after all he has paid for it". In future when I choose to upgrade to Vista (running it in a VM on a Mac.... ummmmm) then it could go "we can now replace that Office 2003 with the one in Vista", hell even let me go out an buy another speech to text piece of software and use that instead.

JBIs job is to provide the standards so that software upgrades can be done incrementally and you can choose to replace products with the bits that you want, when you want.

The thing about JBI is that no end users should ever care about it, its in the magic part of technology, it should just work. But hell you miss it when it isn't there.

Technorati Tags: SOA, Service Architecture

Contracts are for producers and consumers

Jetset Dan Creswell is attending a rather interesting sounding conference in Seattle and put up a post around scalability which talks about a presentation he has been to.

A key part of Amazon’s approach to defining service contracts is SLA’s. Conventional wisdom for SLA’s is that they are a one-way contract but in fact they should be considered as two-way contracts (what the service promises and how it is to be used).

Now saying that "Amazon are spot on" might sound like a fan-boy comment, but this really is one of the major issues with contracts and SLAs as they are currently provided by standards and technology vendors. I wrote a paper back in 2005 for IEEE Software on "Toward an acceptable definition of service" which was pretty much all about how contracts and SLAs are important (and I've since talked more about the need for WS-Contract and WS-SLA).

Again this stuff isn't new. Bertrand Meyer's "Design by Contract" approach went into some detail around the concept of contracts, grouping them into three bits

• Pre-conditions - things that must be true before you call me
• Post-conditions - things I promise will be true after I complete
• Invariants - things I promise won't change

It is very sad indeed that the level of formalism available in Eiffel is not present in today's "modern" technologies. Contracts apply to the interaction between consumer and producer and hence should apply to both parties, and they cover the data, functional and non-functional aspects of the interaction. Most importantly for the future of IT and the sharing of services these contracts need to be formally defined, managed and enforced. Having this information on paper helps only in arbitration after there has been an issue, which helps only lawyers and accountants. By having technical standards for contracts and SLAs we can simplify the process of sharing services and better understand the impacts that using a service will have.

Now can anyone think of a good reason why vendors aren't helping to create contracts?

Technorati Tags: SOA, Service Architecture

How vendors view SOA

I'm picking on this post from MSDN around Where to start with SOA not because its completely wrong (it makes a reasonable point) but because it nicely encapsulates the vendor mindset of SOA. The basic point is that you can't purely have something enforced from the top as it becomes a complex management challenge and that starting from the bottom creates poor SOA is pretty much spot on. His argument that the top should provide the framework and reference and then have it filled out by tactical projects is something I'd really endorse.

The challenge is what the view is of what the "top" does and what constitutes direction.

Middle out - central group provides key elements of the interface, including numbering schemes, message exchange patterns, standard communication mechanisms, and monitoring infrastructure, and encourages the dev teams to use it to build services that can be shared.

Now these are all laudable elements, and things that should indeed be standardised on, but fundamentally they are about the technology and delivery of SOA, and not about its architecture and definition. There is nothing here about understanding the business or laying down the governance approach, its all just about the technology.

This is the big challenge when it comes to talking to any vendor about SOA, because they don't have the challenges of operating in a business environment and are focused purely on the technology delivery side it is practically impossible for them to put their products in a broader context, so they just pretend there is no broader context.

Remember this when you talk to vendors, put out an RFI for SOA or ask for some project delivery help. For a vendor every problem has a technology solution, one that requires license fees, any problem that doesn't have a technology solution will result in them pretending that there is a technology solution or ignoring that problem completely.

The post I've referred to is, as I said, not a bad view of the world from a product and technology perspective, but it is firmly constrained to that domain.

Technorati Tags: SOA, Service Architecture

Defeating software patents using ideas and the internet

There has been much talk in IT about the evils of software patents, most specifically the stark raving obvious patents that abound. Now looking at the US Patent definitions (the worst of the global ones) the key bit that invalidates a patent is of course Prior Art. Where Prior Art is defined as

known or used by others in this country, or was patented or described in a printed publication in this or a foreign country

Now to me it seems that a blog post can be classified in this day and age as the modern equivalent of a "printed publication".

So here is a simple idea, any time you have an idea, just quickly right a blog post on it. Then in later years you will never think "but I thought of that" when you see a patent application that is just an obvious thing with paperwork. Most of the dumb ideas are things that people either implemented, or thought about, and just didn't bother getting them patented because that would be silly, and didn't even publish the information because it was so obvious.

If every idea that is had is blogged about then rapidly all of the obvious ideas will have clear and documented prior art. You think its obvious that you could use a PVR to create targeted ads? Blog about it, use the technorati tag "prior art" and suddenly there is prior art to cite. By publishing it like this you are clearly saying "I'm not going to patent this idea" and you aren't going to get into some silly license argument. The reason to publish your ideas is because you don't like the current patent regime and you want to get rid of silly patents.

Now clearly I'm not a lawyer, but under the definition of the US Patent Office why wouldn't that count?

Technorati Tags: patents, Prior Art