SO - What IS SOA, anyway? (part 2)
Having now stated that SOA is an architecture, it is time to consider what makes SOA unique and interesting, compared to the way we do things already.It is time to consider the concept of "the service".
This is the point where many are led astray when talking about SOA. This is the point where people claim to have been using "services" for ages and that SOA is nothing new. This is the point, where a lot of people think that "services" means "web services", and that SOA is an enterprise integration project and all about component based development.
Vendors are pushing Service Oriented Architecture on the promise of extended reuse of services,.resulting in reduced development time (and cost). Wait - that sounds remarkably familiar to the Object Oriented paradigm of the early 90's. We tried that and are doing that on a regular basis with technologies like J2EE and .NET ... Nothing new in that??!! And by the way - we didn't get too much of the promised reuse back then, so why should we believe it now??
We shouldn't. Simple as that! Don't believe the promises of reuse as a result of SOA. In theory, the concept is brilliant - as it was/is with object orientation. But in reality, the reuse of services will face the exact same challenges as the reuse of objects. It is very, VERY difficult to create services (or objects) that are generic enough for massive reuse. More often than not, the context in which the service is intended to be reused, is different from the context to which the service was built. What is needed is not the existing service, but a slight variation of the existing service - hence a new service is made, or the existing service is wrapped in a service-extension that adds functionality to the existing service. Alongs comes the third iteration, and here, more new functionality is added, while some existing functionality is discarded.
Before we know it, our generic services has spawned numerous variations used in very different ways. And sure - in theory - there might well be a tiny bit of code being reused somewhere deep in the core of the service, but the value of that reuse is eaten up by the added complexity and need for strict governance to avoid messing things up for each other.
Don't think of SOA in terms of reuse. Don't think of SOA as an expansion of OO. SOA is not about doing CORBA or DCOM better. SOA is about the business.
A common misconception of SOA is in the analogy of LEGO™ bricks being put together to form some complex construction. What that analogy is interesting from an interface point of view (we might get back to that), it is really poor from a service point of view. A "service" implies "serving" - the performance of some sort of value bringing function. In itself, a LEGO™ brick on its own performes no function. Only when connected to others can it fulfill a purpose. Not so with a service.
A service is a self contained unit of functionality that on its own delivers value to its user. It fulfills a purpose in itself, but coupled with other services, it can fulfill an even greater purpose.
I like to imagine SOA like a walk-in closet. It holds a huge number of items, each fulfilling a purpose. There are pants, socks, shirts, sweaters, shoes, scarfs, gloves, hats, belts, ties etc.etc. - each with a purpose of their own. You can mix and match in a collosal number of unique ways, and put your "services" together to form ensembles, serving the greater good of keeping you warm, comfortable and looking sharp.
Speaking of ensembles - another interesting analogy would be that of musicians. Each are capable of playing music on their own, but put them together in a band and they can complement each other and make music together that they could never have made on their own.
Both in music and in fashion, there are rules, however. In fashion, colours match or clash, and you just don't wear brown shoes with a grey suit! Brown shoes don't make it!
In order for music to really work, the musicians have to play in the same key and tempo. You must follow these rules - these standards!
You must also follow the agreed principles of composition and adhere to certain rules - or policies - to produce what is known as harmony., and make the music sound good (or at least, bearable).
Another thing fashion and music have in common is composition. Both in putting an outfit together and in writing a piece of music, you compose.
In SOA, you compose as well. You compose your business processes. And if you do it right, the elements you use to compose your business processes is the services mentioned above. You put the pieces together in the right order to suit the purpose of your business.
That is where the real value proposition of SOA lies. That is where the famed reuse is in play. Not in reusing single services for multiple business processes, but in reusing the existing business processes elements when creating new processes or adapting existing processes to changes in the business objectives.
It is when your architecture allows you to reuse existing implementations, and only change the services that represents the changing parts of the process. That is where the value lies.
SO ... What is S O A ?
SOA is the collection of standards, principles, policies and composition that enables companies to change and extend their business processes - and the strict control and management of said collection.
It is not the code, not the infrastructure, not the platform, not the technology.
It's the architecture. The rules, standards, principles and the composition.
0 Comments
January 5th, 2008