Despite hundreds of publications, vendors and analysts hype, the fact that SOA has been proclaimed dead and later reincarnated in an SOA manifesto, there is still a mystery surrounding this topic. Some of these mysteries are described in Joe McKendrick’s latest post.
What's the difference between SOA and cloud computing? The relationships between the two were very well defined by David Linthicum:
SOA is all about the process of defining an IT solution or architecture, while cloud computing is an architectural alternative. Thus, SOA can’t be replaced by cloud computing. In fact, most cloud computing solutions are going to be defined through SOA. They don’t compete -- they are complementary notions.
McKendrick elaborates further on this:
When you get right down to it, cloud is the acquisition or provisioning of reusable services that cross enterprise walls. Likewise, Enterprise 2.0 is accessing services that enable greater collaboration and mashing up of information by end-users. They are service oriented architecture, and they rely on SOA-based principles to function.
How could SOA be failing when nobody really has fully implemented SOA yet? If we go by the most simplistic definition:
... service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration.
Which means that an SOA is a way of architecting systems - in other words it is how not what. In McKendrick’s opinion:
SOA is an evolutionary process, and nobody really has fully completed a SOA implementation yet... most companies are still planning or considering their first service-oriented projects. In fact, the major challenge I keep hearing about these days is SOA gets too successful, and too many services are being added or launched willy-nilly - or being demanded - across enterprises that have SOA efforts underway.
How does one know when a SOA project has been successful or unsuccessful? The issue with this statement is that a success criterion for the enterprise architecture in general and SOA in particular is not well defined. According to Todd Biske
... the major difference between what companies claim as success or failure does come down to expectations and goals. When the expectations are clear and the goals are clear, claiming success or failure is also clear... Here's your litmus test. If you are adopting SOA, can you answer the question, "How will you know when you're successful?" If you can't answer it, then guess what. You're probably setting yourself up for a perceived failure.
Ugo Corda adds to this by saying:
... proper verification of SOA success in certain areas of claimed SOA benefits requires a significant amount of time (e.g. a couple of years) and those success stories are far from verifying success across that time period.
According to McKendrick:
This is one of the biting challenges of SOA to begin with - success is a long-term gain, evidenced by the sharing of services across multiple business units, in which service development time is notably cut back, or, a business is able to reconfigure and achieve faster time to market with a product or service thanks to the increased flexibility of its underlying infrastructure... the only true measures of long-term success in the market are either increased revenues or increased stock values, and many factors besides SOA will contribute to this.
How many full-functioning, true "SOA" implementations are there, exactly? Again the question is how this number can be measured? By number and granularity of services? By number of service consumers? In words of McKendrick:
When does Just a Bunch of Web Services become SOA? What is the threshold at which Web services may require some better care and feeding, with governance, registry, management, and all that good stuff - and thus become more SOAish?
Herbjörn Wilhelmsen elaborates on this by saying that the full functioned SOA requires:
- Clear strategic leadership.
- Prioritizing business value.
- Corporate culture.
- Proper incentives.
- Service discoverability.
- Interoperability.
- Opportunities for reuse.
- Making the services evolvable.
- Service level agreements.
- Testing the service-oriented architecture.
- Monitoring services.
If SOA is "not about technology," why are technologists driving it? According to McKendrick:
You hear it all the time, at every conference, in every analyst note, in every article. SOA is not, absolutely, positively, assuredly, is "not about technology." Yet, it's promoted by technology vendors, and usually falling under the aegis of IT departments.
As McKendrick points out, an SOA is a living evolving architectural approach and, despite all the buzz, many of the statements about it are driven more by emotions then actual facts.