When focusing or comparing SOA versus API approaches, it’s easy to take shortcuts and thus not considering the whole scope. This inevitably brings the reflexion to a partial, if not wrong result.
Across its blog and a SOA versus API trilogy, SOA software provides you with a realistic view of this exciting topic. Feel free to join us on our blog for reading and debating with us around this:
“SOA vs API 1/3: SOA, let’s speak reality and listen to experience”
- Initial SOA objectives
- Where and why SOA partially failed against its objectives
- SOA = a strong and concrete legacy: Services / Best Practices / Governance
“SOA vs API 2/3: Sisters approaches … but not twins sisters”
- API Economy: API drivers vs SOA drivers
- API = a business driven instance of a SOA Class
“SOA vs API 2/3: API: Pitfalls and Anti-patterns”
- API: strategic pitfalls to avoid
- API: technical anti-patterns
SOA vs API 1/3: SOA, let’s speak reality and listen to experience
Well, how to start speaking about SOA without falling into pitfalls? I would say let’s start by the beginning, and as usual it requires answering a simple question: WHY? precisely why SOA got such an interest in the 2003 – 2008 years?
Initial SOA objectives
Each new architectural approach (and it’s true for both domains: humanity history and IT) relies on the requirement to solve some issues or pains. So what SOA was expected to solve? The answer was: nothing but looking for a “better alignment between Business & IT strategy”. As companies faced a challenging globalized business environment, they began to ask for a better alignment between Business and IT, in order to reduce the time required by IT to provide the company with a new business solution / application. Having a clear and deep understanding of this is highly important as the SOA wave has been driven by this objective. To make it simple, let’s formalize it this way:
Cause: IT built in silos, lack of agility because no alignment between business and IT strategy.
Solution: Build a Service Oriented Architecture in order to identify and create services, use them to break silos and finally align the business and IT strategy.
SOA approach: mid to long-term iterative approach (2-3 years vision); think big, start small; project-by-project.
SOA ROI: at IT level = service reuse; at Business level = agility … and it won’t happen at the first iteration/project!
At a glance: Services then Reuse then Agility then ROI
Did it happen? Hum… not really, so what did wrong?
Where and why SOA partially failed against its objectives
The main part of the answer is here, three letters, no big deal, just three letters: ROI
If a company doesn’t have a strong compelling event for doing something, at least this company expects an ROI in regard of its investments. Let’s get back to the real sense of the SOA’s ROI: it was definitely not the possibility to build a new application that could not have been created without SOA. In other words, if you frankly try to answer this question: would SOA allow me to create a new application that will generate more income, expand my visibility across the world or win or reach new customers … and could I do it without SOA? The answer is YES, I could do it without SOA! You see that the SOA’s ROI was not that simple to point out (where the costs were much easier to identify: money and time to create and manage services …). Being not able to use the ROI factor to strengthen the approach, the focus decreased in time when facing classic difficulties in projects. By honesty, we must also add that the subprime crises in 2007-2008 didn’t help companies to keep focused on such mid-term and iterative engagements (in 2008-2009 reducing costs were the main objectives).
Results at a glance: No continuity then No Reuse then No Agility then No ROI then End of SOA initiatives
Let’s keep in mind this lesson: ROI is the cornerstone of each company’s investment. Aligning business and IT strategy was not a tangible enough ROI to allow such an ambitious architectural approach to succeed!
So, does it mean that nothing was good in this architectural approach?
SOA = a strong and concrete legacy: Services / Best Practices / Governance
Let’s first recall that SOA was not something that a company had to buy, but it was an architectural approach that a company had to build, iteratively, over the time and projects-by-projects.
First legacy: Services. From the Cloud to Internet of Things or APIs, everything is Service oriented. Thinking Services is the best way to fit a technical or business need by considering the appropriate granularity and level of abstraction it must have. In 2009, Anne Thomas Manes from Burton Group wrote this laconically article: “SOA is Dead, Long Live Services”. In other words, forget the concept, keep the legacy and go ahead! I would had to keep in mind that the real value is within the Services.
Second legacy: Best practices. Very soon it appeared that identifying, building, using services required best practices to address the full lifecycle of services: design, model, build, compose, publish, integrate, deploy, secure, manage, and evaluate Services. Experiences and tools provide us with the relevant best practices for a mastered SDLC.
Third legacy: Governance. A strong knowhow that we learned from SOA initiatives is that maintaining the focus of a mid-term strategy, in heterogeneous environment (different products, teams, projects, objectives, LOBs), requires strong governance. As a European citizen, I want to share this strong belief: we, as European Community, will only survive if we are able to define, put in place and execute without weakness the right governance model for us. The one that will allow such different countries (in regard of secular divergent interests, conflicts, crises, wars) evolving together in a shared vision for a better future. This is what crises told us. It is the same for a company, no doubt on this: there is no success to expect in a mid-term IT strategy without strong Governance.
To summarize this first part, here is what we learned:
1) The ROI of SOA was “aligning Business and IT strategy”. It was not business (money) driven enough, not tangible enough to strengthen the SOA approach and survive the iterative and multi-projects approach.
2) We have a strong SOA legacy (Services, Best Practices, Governance) that we can use to be more efficient in new IT / Services initiatives.
Stay in touch with us for the next episode of this trilogy: “SOA vs API 2/3: Sisters approaches … but not twins sisters”. We will analyse exactly why both topics are tied but also how they are different. We will explain why differences are not as simple as presenting SOAP vs REST ; Internal vs External services ; known vs unknown consumers …