Chatting about SOA

Well thanks to those awfuly nice people at Sun I've done my first VODcast on SOA, tools and what technologies are hot. Unlike the people on the West Coast I had to do it via a webcam link (cheers to Simon Cook for the help there).

In quite a busy month there is also an interesting article in information age about SOA "who plays, who pays" where I put some of my oar into the debate, but the interesting bit comes from Chris who puts it all in a consistent context. Its a key question on SOA, how do we change the current funding model to make IT more accountable and more successful.

Technorati Tags: SOA, Service Architecture

Shooting the myths of SOA

Over on the Yahoo SOA group list there is some discussion going on including my bug-bear of REST v SOAP. In this, and in some other conversations recently I realised how often certain elements are stated as being the accepted wisdom or an absolute rule. Its not the first list out there, but hell its my own.

1 - SOA = WS, or the broader SOA = Technology

SOA is about architecture this means thinking about the problem and planning. Working out what the services should be and then worrying about the implementation technology. This doesn't mean prancing about doing powerpoint, but it does mean that technology is NOT about the architecture. Technology is about implementation or delivery, Service Oriented Delivery of IT = Technology, so in an SOA world "technology = SOD IT".

2 - Services should be stateless

No they ruddy well shouldn't be. Lets be clear here just because the executable code is stateless doesn't mean the service is. If you store information in a database then the service has state, the consumer of the service doesn't give a monkeys whether you store it in memory, a database, flat files or using the collective unconscious as long as when they call again they know that the service has remembered what they did last time.

3 - Services should be loosely coupled

Again this isn't a sensible blanket goal for an SOA, because sometimes its smarter and more agile to assume that certain services are highly cohesive as they work together to achieve a common goal. Services should be sensibly coupled, but if you are calling a service and using their interface then you are coupled to that interface and will have issues if it changes.

4 - SOA is about reuse

Nope its about use and there is a big difference between the two concepts.

5 - SOA is something I buy

SOA doesn't come in a box, it isn't about technology and you can't just download it or buy it off the internet. SOA is about changing the way you think, its about working differently and thinking of systems in a different way, and most importantly thinking about the business.

6 - SOA is about IT

If SOA is about IT then lets all go home now. We've tried to keep in our little boxes and pretend that the outside world doesn't matter, the whole principle of SOA is that its about the services to be delivered rather than the delivery of those services. SOA is about the business, not about IT.

7 - I've been doing SOA for years

No you haven't, well to be honest there is a possibility that you have been but the reality is that odds are you haven't. SOA isn't just EAI using XML, despite what the old EAI vendors say, and its not just client server either no matter what the analysts might say. Its true that some people have been doing SOA for a while, but the majority haven't. What we are seeing is a collective rewriting of history, which was nicely summed up by Miko in his Defensive SOA anti-pattern. So be honest about it, if you really did think in terms of business services and capabilities then good on you, but if you are saying SOA because you are using technology that came in a box with SOA on it and doing the same thing you did five years ago then it isn't SOA.

8 - Services are atomic

Again no they aren't, first of all they've got capabilities and second of all they might contain other services. So a high level "Sales" Services will contain all of the services related to sales, it might provide a couple of high-level capabilities as well but most of the functionality is going to be delivered by the services that are within it. Services being atomic means that they are at the lowest level of granularity all the time, that just doesn't make sense when you think about how organisations work, Procurement is in Finance, Training is in HR, etc. Services aren't atomic and having this as a goal is dumb.

9 - Services implementation must be hidden from the users

Now generally this is a good idea, but its not a golden rule. Take for instance ordering a product and having it delivered. Hiding everything would mean that you'd see the order go in and then wait. Most decent companies now however enable you to watch the execution of the process through their supply chain so you know exactly what is going on and when things will happen.

So its an okay general rule, but don't think its absolute.

10 - Services are separate from processes

One of the technology created ones, mainly because no products out there enable you to design your service architecture properly, and no process tools enable you to assemble multiple processes behind a single interface. This doesn't mean that service is separate from process, it means the tools are currently rubbish at doing SOA.

Don't start with process, start with service. All process does is provide you with another implementation language for your services.

11 - SOA is heavyweight

There is no denying that some of the sledgehammer to crack a nut technologies out there come under the heavyweight banner and have become associated with SOA. But as SOA is about changing the way we think about systems to make it easier to make the right choices and to separate the different services out so we can deliver them using the right method and the right technology then SOA should in fact be considered as a lightweight approach. It really shouldn't take that long to determine what the services are, and if you can't its a pretty good idea that you don't have a Scooby Doo what you are doing.

12 - Reducing implementation costs reduces TCO

This isn't specific to SOA but its a beguiling myth out there in IT. It says that anything that gets something delivered a little bit quicker means that its cheaper to do. This approach says that if something was scheduled to take 40 days but by doing X you can do it in 30 days that its always good to do X. This misses a fundamental point, and its something that is critical to building a successful SOA, once the service goes live there will be more money spent changing, enchancing, fixing and supporting the service than was ever spent developing it.

If X makes support and modification easier then its a good thing, if it doesn't then you are just storing up problems for the future.

Technorati Tags: SOA, Service Architecture

Why Service Interface != implementation

One of the assumptions that some people make is that if the interface and contract are the same then the implementations must behave in the same way. Sometimes this is manifest in an idea that a service implements one and only interface, other times its just an assumption people make when doing testing or an upgrade.

So here are three examples from Google Maps, the AA and Multimap of exactly the same route request from Trafalgar Square, Westminster, Greater London, SW1 to Trafalgar Square, Gosport, Hampshire, PO12. No particular reason it just seemed like a reasonable test. So the interface for these two is exactly the same when viewed as a service. We have two input parameters and in return we get a list of directions and a Map. Our preconditions (that the places exist) and post conditions (the route is possible) are the same so from any service consumers perspective these two elements are identical. Ignoring the formatting differences of the pages there are a couple of things to note

1. Google Maps is clearly US developed, it uses street names far more than its UK based cousins which focus on the route number (e.g. A4)
2. All produce different distances and times
3. All go via slightly different routes

So from a consumers perspective they meet the post-condition but the ability of the consumer to follow the process may vary based on how the process (route) has been described. Here for instance Google Maps produces a set of directions that are a bugger to use around London as you don't want to be looking for the names of the streets when there is a great big "A4" sign at the junction.

So Service Implementation can definitely differ for a single interface, and regional differences between services shouldn't be under estimated. So when you are looking at that global logistics planning service do remember that people in different countries navigate the roads differently, simply meeting the post-condition might not meet the required business objective. This is one of the reasons that I like to capture business priorities and drivers against actions, so a driver here wouldn't just want "fastest route" they'd want "simple to follow" as well.

Google Maps also demonstrates another rule for SOA, one service implementation can expose multiple interfaces to the world. So as well as routes you can find out who in London is doing service architecture and the stunning revelation that there is no beer in Sydney (tough luck on the aussies today in many ways).

So:

• Same interface != Same implementation
• interface can have more than one implementation
• an implementation can implement more than one interface
• Regionalisation is important, even when you meet all your semantic and functional contracts.
• Services don't have to have WSDL interfaces
  

Technorati Tags: SOA, Service Architecture

Gartner Analyst reveals ignorance

One of the truly scary things about SOA is when people boldly stand up, open their mouths, and make themselves look very silly indeed. Massimo Pezzini, vice president and distinguished analyst at Gartner Inc. sets new levels for this however. Beating out the previous winners who said that "SOA = WS" Massimo goes for the jugular of bad description with the phrase

"the secret few SOA gurus want to let out of the bag: SOA is an update of classic client/server."

AAAARRRRGGGGGHHHHHHHHHHH GNNNURRRRGGGK

Its couched around that "people were doing SOA in the 90s" bit, claiming he was pushing SOA in 1996 and preaching to the converted, but people didn't call them services. I worked on a project in the early 90s where we used the term services, it was 100% not client server as that term meant very little in an environment where event the bit that did the UI was also considered to be a server, indeed everything was both client and server. So yup SOA isn't new (just like OO wasn't new in the 90s), but that doesn't mean everyone was doing it, just in the same way as all the C programmers claiming they did OO was rubbish, so is the statement that client/server = SOA.

SOA is not an update of client server, at least not in my world. SOA is about changing the way you think about systems and having that change the way you implement them.

The good news for Massimo is that he clearly is part of the crowd over at Gartner

"Advanced SOA" might be the term for future SOA implementations moving beyond request and reply.
-- Jeff Schulman, group vice president for Gartner

Advanced or just plumb obvious? That system in the 90s I worked on (or the ones I worked on in the late 90s and in 2000) all mixed RPC with events, throwing in a bit of pub/sub when required and even fire and forget. Not just doing request/reply doesn't make something "advanced" it makes it sensible.

The biggest problem here is that this is what drives the product vendors to get onto the magic quadrants, which in turn drives quite a bit of IT procurement out there. And if people flogging old client/server as "SOA" are now included into the mix then we really aren't going to address the fundamental problem.

The only benefit here is that this underlines the point that if SOA is to succeed it can't be about the technology. These analysts are talking about ideas that have repeatedly failed to deliver on their promises as being the thing to do. This can't be what SOA is about otherwise it will go the same way as all these other technology, and analyst, led pushes... into ignominious failure. SOA is about changing the way you architect your solutions, this means thinking differently and then having that thinking impact delivery. Technology is the thing you add after you've done your service architecture.

Gartner have dropped into the SOD IT trap, confusing technology delivery with architecture. Someone throw them a rope.

Technorati Tags: SOA, Service Architecture, SOD IT, Gartner

Web Service Best Practice made simple

Now while I like to stress that SOA isn't about the technologies and it doesn't have to use Web Services, lets face it the odds are that when you get to the technology its liable to involve them somewhere. There are some good, long, articles out there around all of the challenges and what you should do. But I've used a few simple rules to help me

1. Don’t expose functionality directly, always use a façade
1. Depending on the technology you can then log inside the face, error reporting etc. Some tools have these elements done for you.
   
2. WS-I compliance is a must if you have heterogeneous clients
3. If you are doing transformations, use a mediation approach (i.e. something between you can the caller and the consumer)
4. Publishing is a “phase 2” element for most organisations, don't worry about it
   
5. End points wise, if you are using “standard” J2EE then JAX-RPC (and now JAX-WS) are pretty well tooled up, if coding then AXIS 2 is worth a look.
6. If you are using something other than HTTP be aware that currently both end-points have to be using the same technology stacks
7. Remember that Point to Point WS is still Point to Point, if you are going to be doing quite a few of these then put in the patterns (e.g. mediation and a facade) that make lobbing in indirection simpler
   

Other good practice elements are to define the schema separate to the WSDL so your type definitions are independent (can cause versioning challenges though).

The biggest recommendation is to use a decent IDE with good WS support. In terms of documentation what I've done is design the WSDL and the data structure, then cut and paste the images from the tools of these things into the document. For each method on the WSDL I'd. define (in the doc) the pre-conditions, post-conditions and sometimes the invariant, brief overview of what the service is for and if there are any interaction patterns (call X before Y) then state them if simple (as pre-conditions) or if complex diagram the process. Then the WSDL is an appendix along with the Schemas.

Its not rocket science and from experience it doesn't need to be complex and if you are using REST I'd say that everything but 2 and 5 still apply.

The most important by a mile is the facade rule, it will save you a huge amount of pain over right-click exposing something internal.

Technorati Tags: SOA, WS, WSDL, Web Service

SOA 2.0 what next?

Okay I've been a little quiet on this one, but fair play to the folks over at Macehiter Ward-Dutton they've got some momentum behind the anti-SOA 2.0 bandwagon with their petition, I liked it so much I voted twice (or to be honest I pressed the back button then say "yes" to the POSTDATA dialog). Now personally I'd say that SOA already includes Event Driven elements as that is just one communication style that is completely independent of the basic idea of SOA which is thinking about services and particularly business services.

However one question is why we should worry about a branding slogan, well I think we should not just because when you look at "Web 2.0" people are talking about doing research into collaborative technologies... then it turns out they mean looking at Wikis (imagine being commissioned to do that, researching a wiki... how long would you spend on the beach?). But also because if we start now we'll have a major revision everytime we add something new.

There are two clear worlds here, the one (like the OASIS SOA RM) which talks about SOA as a concept and an architectural element, and predominately focused on changing the way people think about systems. This world considers SOA to be as much about the business as it is about IT.

The second is the vendor world, this is about flogging product, which means shiny buzzwords and a constant desire to feel new. I don't blame Oracle for claiming SOA 2.0, if they hadn't one of their competitors would have. But all of these pronouncements needs to be married to the fact that they are about selling product. "Yes last years product was SOA, but this years is SOA 2.0", hell its even a full number jump so the upgrade will be harder. SOA column inches are currently dominated by this deliberate miscommunication so people need to understand the motivation behind it.

Being rude the challenge I see is this...

SOA by vendors = RPC

EDA by vendors = messaging

SOA by sentient human beings = Business service architectures, structure and thinking differently.

So vendor SOA and vendor EDA are just two communication patterns when using proper SOA.


Why do I say that SOA is about thinking different? Because I have to deliver projects, and if we don't think differently then its the same old crap that failed last year. Why do vendors attach products to buzzwords and generate more buzzwords? Because they want people to buy their next product which needs to appear sufficiently different and important in relation to the last. I want to deliver a project, they want to deliver a product, understand the motivations and you understand the messaging. Why should you take the SOA as thinking message over SOA as product? Well if you want to build a product you shouldn't. If you want to deliver a project however then we are sitting in the same boat.

If we allow SOA 2.0 then we'll get the following

• SOA 1.0 = RPC
• SOA 2.0 = RPC + EDA
• SOA 3.0 = RPC + EDA + ERP
  
• SOA 4.0 = RPC + EDA + ERP + "Semantic"
• SOA 5.0 = RPC + EDA + ERP + "Semantic" + Agents
• SOA 6.0 = RPC + EDA + ERP + "Semantic" + Agents + Business Service Modelling (I hope to god this bit arrives earlier)
• SOA 6.0 = RPC + EDA + ERP + "Semantic" + Agents + BSM + Service Portfolio Management

Now I might be wrong on the list, but you get the idea. With things like Netweaver and Fusion already looking to put ERP into the mix and the rise of the term Semantic we risk descending into a continual stream of updates on what is fundamentally a conceptualisation challenge.

So SOA 2.0? No thanks, not until the technology allows me to create a proper business service architecture and then drive that through my projects and organisation, that really would be something worthy of a full revision number.

Technorati Tags: SOA,SOA 2.0, Service Architecture