SOA in Cardiac Arrest, Long Live Services
Blogger Anne Thomas Manes, wrote this excellent post, SOA is Dead; Long Live Services. This post echos, in a slightly different theme my posts, Amazon Simple Queue Service (Amazon SQS) and also, What is SOA, Really…. A Sacred Omnipotent Acronym.
In the Amazon SQS post, I mentioned that it is possible that software companies selling SOA will find they have been “out-serviced” by companies offering services, such as cloud-computing services. Earlier, in SOA - a Scared Omnipotent Acronym, I mentioned how SOA is the art of taking a perfectly good running IT application, breaking it up into its components, and creating a brittle, insecure, unmanageable mess.
SOA is an amazingly effective architectural construct for taking working applications and making them inefficient, insecure and nearly impossible to maintain.
SOA, the patient, is technically not officially dead; SOA is, however, laying on the cold ground in cardiac arrest. Cowering over the dying patient are software sellers and analysts frantically giving CPR, hoping that the heart of SOA will start beating again, or at least resurrect itself after three days pass, since they have so much riding on SOA.
However, SOA will die, regardless of how many shock treatments are buzzed into the patient. SOA is terminal, or at least SOA as we know it. If you want an SOA, go find a service like Amazon SMS or Amazon ECS or S3 and use it in your architecture. Then you will have an SOA.
Let’s all chant with Anne….. Long Live Services! Hip! Hip! Hurray!
Filed under: Cyberstrategics, EAI ESB & SOA, Systems Engineering
I want to comment on the quote from your previous post: “SOA is an amazingly effective architectural construct for taking working applications and making them inefficient, insecure and nearly impossible to maintain.”
This statement exemplifies the problem with the word “SOA”. “SOA” in its true form (i.e., an architectural style governed by a set of design principles) should never produce a system that is inefficient, unsecurable, and nearly impossible to maintain. But very few people really apply SOA principles to their applications architecture. Instead they view “SOA” as a set of middleware technologies that they apply to integration projects using the same poorly design architectural constructs that they’ve been using for the past 20 years.
Hi Anne,
If you think about it, breaking up any application into distributed services will always be less efficient, less secure and very difficult to maintain.
The same is true for your desktop computer. When your computer is self-contained, and you are not sharing the components in a distributed architecture, your computer is much easier to maintain and secure than if you “broke your computer up” into an SOA.
However, take your hard drive and put in the living room and share it with your family, take your memory and do the same, then take every component and create a distributed computer, with components scattered here and there (across the Internet!), you will get less efficient, difficult to maintain and virtually impossible to secure relative to a self-contained application.
It makes no difference, Anne, what the original idea of SOA is, if the idea is to take any application and distribute it across the network into smaller components. The more “spread out” across the network, the more difficult to maintain and secure. This is true for any architecture.
SOA was always envisioned, from Day Zero, to be a distributed architecture of shareable components (as services). Folks have jumped to SOA without understanding the complexity of managing, maintaining and securing cross-organization components, including lifecycle management. Even within an organization, SOA can be very difficult to maintain, secure and manage. This is one reason why SOA ROI, if you consider all the variables, is highly suspect.
Thanks for stopping by and commenting.
Yours faithfully, Tim
Hey Tim,
Think about an application well designed and developed. By definition, it has well defined decoupled components, that could be used in a certain degree of isolation.
Now think about an on demand process of making some of these components/functionalities available as web services. If this process is carried on in a carefully controled and documented fashion, you could confidently reuse these interoperable functionalities in new applications.
The point here, is that the good application design principles, must not be affected by the intention of making some parts of an application exposed as web services. Otherwise, “the tail is shaking the dog”. Unfortunatly, SOA is commonly misunderstood and sold by some middleware vendors, subverting the old, well established design principles. I hope this kind of SOA is dying.
Hi Bruno,
Yes, I agree. On the other hand, regardless of how you package and position it, all the “well defined, carefully controlled” components translate to increased costs.
There is no way anyone can effectively argue that a decoupled architecture is less costly to secure and maintain than a tightly integrated architecture.
“Good design principles” have an associated cost, and the more distributed,and the more complex, the higher the costs.
Yours faithfully, Tim
Hi Tim,
I tend to agree with Anne on this. In my opinion the problem with SOA is it is one of those terms that has been adopted by marketing departments to sell products rather than promote good design practice.
To critique your suggestion of keeping everything within the same box, this would violate requirements of many large mission critical applications, many of which need redundancy, scaleability and separation of concerns based on functionality and security. SOA at least provides us with a set of guiding principles that allow us to address these needs in a logical and consistent manner.
However, it is not appropriate in all situations, remember the adage “when all you have is a hammer every problem in the world looks like a nail”.
Regards,
Adrian.
Hi Adrian,
Thanks for stopping by!
I have never suggested “keeping everything in the same box”, I have simple pointed out the simple, indisputable fact that breaking apart applications causes myriad problems.
Anne and I both agree that SOA (and a vast majority appear to concur), as defined in the current software market, is dead (or dying), and the future is more on emerging new technologies and approaches, such a CaaS.
See also, IT Infrastructure: Capability as a Service;
http://www.thecepblog.com/2009/01/14/it-infrastructure-capability-as-a-service/
Yours faithfully, Tim