SOA tutorial: Trends, governance and the microservice impact
A comprehensive collection of articles, videos and more, hand-picked by our editors
"What's in a name?" asked Juliet in Shakespeare's Romeo and Juliet. The question certainly applies to SOA today. Why is service-orientated architecture now so toxic a term that the company formerly known as "SOA Software" had to change its name?
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Although many will say that SOA is dead, the principles behind SOA are still alive and well. In fact, these principles have been in use for thousands of years. The idea that if you have a complex problem to solve, you break it down into smaller, simpler problems, solve these, and then recombine the result to solve your original problem, has been in use for a long time indeed.
The principle behind SOA -- that you should define self-contained systems with well-defined interfaces -- is still very much being used. In fact, the current microservices trend takes the same principles espoused by SOA at an enterprise architecture level and applies them at an application level.
Blaming SOA to sell, cover mistakes
So why does SOA have such a bad reputation? In part, this is just marketing. Software companies always want to sell us the next big thing, so once a label has been around for five years or more, people start looking at ways to rebadge it. Before SOA the same principles were called enterprise application integration (EAI). The products were different, but the underlying principles were the same.
Another key factor is that when software projects fail, or don't live up to all the expectations that were placed on them, it is often easier to blame the framework you were using than admit there was something you could have done better. Having told managers or accountants that SOA is to blame for a recent failure, a project or development manager can't tell them SOA will be used for an upcoming project. So he says he's using microservices.
It is also the case that, like any new technology, SOA was over-used by developers keen to get the latest technology on their CV, without giving any thought as to whether it was a good fit for the particular business requirements they needed to fulfill. In particular, it was common to see enterprise-grade service bus technologies being used to integrate fine-grained application components, rather than integrating enterprise services. By rebranding the frameworks as microservices or something else, we can try again without ever having to admit that the failure was our own mistake.
So what about SOA Software changing its name to Akana? I think there are a number of factors. Even if SOA's name wasn't being dragged through the mud, it isn't particularly great for a software company to have a name based on a five-year-old technology. Naming your company after any technology is a problem, and a key factor behind many company name changes. In addition, there are business drivers for building a brand around a word that can be trademarked and that is more easily identifiable as a company, rather than using a generic term. I think SOA Software's rebranding was inevitable for business reasons that would still apply even without the negative connotations that many apply to the phrase SOA.
A new name for SOA?
So what about service-oriented architecture itself? What do we call it, now that it is frowned upon to call it SOA?
My experience is that on the ground, at least in Europe, the backlash against SOA is not as bad as it is made out to be, at least with customers who have genuine business requirements for which service-orientated architecture is a good fit. For those who are trying to build an application out of fine-grained components, microservices (which as the name implies, is service principals applied in a small scale) products provide a better fit than enterprise service bus (ESB) products, but the principles are the same.
So what do we call it? I would argue that we don't need a name change. Service-oriented architecture covers architecting services, whether we use an ESB to orchestrate them at an enterprise level, or a microservices framework to do it at an application component level.
If SOA as a term is sufficiently out of favor that we don't want to use it, perhaps we don't need a name anymore. I believe that the principles of service-oriented architecture are now so mainstream in software design -- as evidenced by their use to build applications (as in microservices) and systems (as in ESBs) -- that service-oriented architecture can now be referred to simply as "architecture."
Microservices bring agility to SOA
SOA technologies in 2014