SOA? No.
Wednesday, January 7th, 2009
How we all agreed that SOA is dead. Well, most of us anway.
SOA is Dead; Long Live Services
I came across this post by Anne Thomas Manes shortly after I my last post and I couldn’t agree with her more.
She starts out by claiming that SOA is dead. Boom! I also agree with her statement that services will live on via Cloud Computing and SaaS (Software as a Service). Actually, I think the two kind of go hand in hand.
Next up is a quick explanation as to why it failed. SOA was supposed to be the key to finding the Holy Grail. It was how we would achieve scalability and flexibility. Of course, it turned out to be the key to a 1985 Yugo. I completely agree with her statements because I’ve worked on several SOA initiatives and this was rarely the case. There is nothing flexible about SOAP. Period. On multiple occasions, the service bus actually proved to be the bottleneck. There goes the scalability. To top it off these initiatives were expensive. It was not so much a result of the development costs as it was a result of the massive product purchases from vendors eager to capitalize on the latest buzzword: SOA.
She goes on to talk about how there is still a need for SOA. The point is that the term SOA is dead. The use of services as part of an enterprise architecture will live on. I agree with that too. I remember working with clients whose sole desire was to strengthen the so called SOA initiative. I can’t imagine that will continue to be the case. That doesn’t mean we are going to stop using services though. It just means we will not be using services for the pure sake of using services.
From the comments…
I think Scott Francis hit it right on the head. Most of the time I see services built for point to point communication, and they are routed through a service bus. That is pointless. Like that? He also mentions that every time a new requirement is made the SOA architect requires that it be exposed as a service and routed via the service bus. Likely the service is not even reusable. The simple fact is that a client made a requirement and it was decided that they must call a service.
I saw a number of comments that mentioned vendors and platforms. The truth is that many organizations assumed that they could simply buy SOA. They didn’t need to actually implement it. They just needed to buy a platform. There is also this notion that if you had enough services routed via a service bus that somehow synergy is achieved and a SOA appears right before your eyes.
I also saw a number of comments that mentioned the fragile nature of a SOA. This is so very true. I’ve seen this first hand. In two different cases, the service bus became the bottleneck. One simply couldn’t scale. The other used database persisted JMS for monitoring and reporting and it put a hurt on the SLA. Synchronous services can be a real issue when they aren’t living up to the SLA. Finally, a service itself presents a single point of failure. If that service is down, so are its clients
Goodbye SOA, we hardly knew you.
Next we have a follow up post by Dan Foody. While he agrees with Anne, and he made of couple of points regarding where we are going with services.
The first is that while SOA may be a noble goal, it is unattainable. Try and you will fail. It really doesn’t matter how many SOA architects you bring on. He suggests that SOA was about more than just architecture. It was a philosophy of the organization as a whole.
Next he talks about service delivery and orientation. Organizations should focus on delivering services rather than building applications and taking on projects. I agree with this because the ‘architecture’ should really be dropped. It is about the orientation.
My take on this is that most organizations can not or should not be service oriented. If your organization has to maintain a single web application then you do not need to be service oriented. However, if your organization has to maintain a complex, heterogenous environment then you should be.
SOA ain’t dead but it certainly is transforming
In this post, we see some disagreement. The one thing I took from this is the idea that the concept of SOA governance was a failure. I couldn’t agree more. It might just be one of the reasons SOA is dead. How was it a good idea to have management govern your architecture. He suggests that SOA should be decentralized. I agree with that from both a business perspective and a technical perspective.
To the naysayers…
SOA is the alternative to vertical applications. Distributed systems existing long before SOA and they’ll exist long afterwards. Not too mention there is nothing wrong with vertical applications. If you have a single web application then SOA should not be a concern for you. However, in a complex heterogenous environment services are a great option. It comes down to resuability and integration. If you do not need either, then you don’t really need services.
SOA is how you realize concepts such as loose coupling. Again, these concepts existed long before SOA and they’ll exist long afterwards. They are not exclusive to SOA. They can be achieved in any number of ways.
SOA is about more than services and technology. I think not. One of the contributing factors to the demise of SOA was all the semantics about it being some sort of organizational philosophy. This is just plain nonsense. The problem is that SOA was all about the preacher.
My Point
There are one too many letters in SOA. It should have just been SO. I like the notion of being service oriented, but I don’t find there to be any architecture involved. Services are just a means of communication. There is no architecture involved in deciding to use them. Achitecture is about so much more. It begins with the data model and it continues through each application and its tiers. As a floorplan for a house is one dimensional, the floorplan for an enterprise is three dimensional. Services are just a single, flat dimension in that plan.
That doesn’t mean there isn’t any decision making involved. Sure there is. I’ve worked with other architects to define the communication routes between disparate applications, but I’m not so sure I’d call it SOA. We simply had to make decisions about issues such as transactional boundaries, synchronous vs. asynchronous communication, and the compartmentalization of business logic. We’re drawing process diagrams and determining the best way to implement them. It doesn’t really matter whether we chose to use services or not. We’re simply applying the same skills used in application architecture to enterprise architecture.
I’m not singling out SOA architects either. The same goes for web architects, data architects, and other specialized architects. There is certainly an art to all of these practices, but not nesseary architecture. A web architect just takes a bunch of blocks and places them together. These days it is pretty easy. A data architect simply converts business entities into data models. It is good to specialize in these areas. With expertise comes efficiency and polish. When a web framwork comes out, everyone starts out by building web applications using the tutorials and examples available. Eventually you start to deviate from them and find your own way to use the web framework. You develop your own best practices and patterns. That is not architecture though. I happen to be very found of data modeling. It is how I started and if I had not moved to Java I would have continued along that track. Again, normalizing a database is pretty straightforward but after a while you discover that there are many ways to define a schema while keeping it normalized. The difference is that your approach may be more flexible, maintainable, and more. That is not architecture though.
All an organization needs is an Architect. Period.
Update: See my follow up post here.
So until next time, good fight, good night.
Tags: Architecture, ESB, SOA
3 Responses to “SOA? No.”
Leave a Reply
Pages
Calendar
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Very well summarised and commented upon.
I agree that the S is much more important than the A. If the internet space is any indication, each website implements its own S, the basic binding glue is REST or POX/HTTP and the resultant A stays quite simple. Will everyone call it SOA ? I don’t know – to me it walks like, smells like and talks like a SOA.
Having lost the ‘A,’ and maybe the ‘O,’ that leaves us with an ‘S.’ How about we just prefix a ‘B’ and see what’s left. Seriously though – ‘O’ was always a weasle word that allows everyone to pretend they are doing somthing different than what they were up to before without actually retooling! If SOA isn’t defined in some detail – maybe along the lines of Dhananjay above, then we will never know if it has succeeded or failed.
SOA should not be seen as must or as a replacement for the old stuff ! It simply address the needs of specific business logics where it makes sense to openly give services !
Flickr, Facebook, etc…
____________________
Saguenay-IT, IT Outsourcing (PHP, ASP, SOA, Flex, AIR, ActionScript, JavaScript…)