These days, there is a lot of talk about the ‘API Economy’: a world filled with systems providing services to other systems using (above all RESTful) services. It would be easy to miss the fact that this isn’t new at all. It used to be called ‘Service Oriented Architecture’ (SOA). That these are the same becomes rather clear when you try to model it in ArchiMate.In ArchiMate, the active element is ultimately modeled separately from the behavior it performs. Yes, you can leave out the details, but if you don’t, you get this picture [Updated May 4 2017 to make it easier for non-ArchiMate users to understand System X is not a user but a provider of API/Service]:
The ‘API Economy’ story focuses on the interface. The ‘SOA’ story focuses on the service. But a small ArchiMate diagram shows that — in ArchiMate at least — these are two sides of the same coin. Again: the (AP) Interface is the active element that performs the Service behaviour.
Don’t get me wrong: There is real value in a service-oriented architecture/API approach. But it is also true that SOA was once hailed as the solution for about everything and API has all signs of being marketed in the same way. In ArchiMate at least, we can show that they are the same. So, don’t get burned (again) by the hype, but realise the value without ignoring the limitations.
R&A IT Strategy & Architecture 
Agree fully – see the structures I modelled for OpenStack Cloud on my AgileEA.com website under Blogs. One view is Behavioural (services) and one is Structural (API Interfaces)
LikeLike
Some of the principles of SOA and modern (RESTful) APIs are still the same, but the application of these principles is different as well as our current understanding of these principles:
– Typically, traditional SOA services are big and monolithic and not design for reuse but for single purpose.
– At the time SOA was introduced there were no technologies and tooling to drive the consumption model and to support the complete software development lifecycle (SDLC). That is, there were no tools and technologies to easily design services, to mockup services, to publish services and engage developers, and to collect usage metrics and analyse the performance of the services.
– The technology stack of SOA is very complicated. For instance, building mobile app with traditional SOA technologies is very painful process – mobile developers do not like XML and SOAP – they use JSON and standard web protocols. Currently, there are millions of developers and the majority of them do not understand traditional SOA and WS-* standards.
SOA resulted in heavy governance and poorly designed, undiscoverable services. This made impossible for organisations to be agile and innovate. The big difference between SOA and modern (RESTful) APIs is in the mind-shift towards reuse and consumptions model over the production model.
LikeLike
Hmm. For me SOA is a pattern, not a technology stack. It’s service oriented architecture, not SOAP and XML. That initially SOAP and XML where used is not that important from an architectural view. I see RESTful services as a different (and in many ways better) way to implement a SOA. The same is true for your argument as big (SOA) versus small (API) services. The pattern was SOA, not BSOA (Big Service Oriented Architecture). Big didn’t enter the equation of the pattern when it was being popularised.
If I recall correctly, SOA was influenced by the Unix approach to operating systems: many small programs that do a specific function and do it well that are combined to do bigger things. At least it was an argument that I heard often in the early days. In a sense, the Unix set of small commands was a SOA avant-la-lettre. I just want to say: these ‘independent services’ ideas have been around for a long time.
LikeLike
I should add: some of the problems with early SOA were indeed the result of problems with the heavy-handed implementations (SOA and so forth), you’re right to point that out. The limitations of the past were not only one of technology choices (SOAP, XML), though. Many complex problems remain, e.g. the loosely coupled spaghetti effect and all other kinds of dependencies and complexities that are not technical, but more functional.
LikeLike
Agree. ReST is not an architecture style, just like SOAP isn’t. However, insofar as you use APIs as a moniker for the emerging microservices style, then there are some striking differences with SOA, as microservices are (intended to be) much more autonomous then SOA services. In a true microservices world, which once started as the guerrilla SOA movement, there is no shared Enterprise Service Bus, for instance. Each microservice itself is responsible to handle its interactions with other services. In a way, it is the “shared nothing” principles of resilient hardware design applied to SOA.
LikeLike
What I found interesting/amusing is that Mulesoft (which sells a commercial version of the open source Mule ESB) uses the term API-Led Connectivity as a marketing label to sell their ESB. Actually, it is not just marketing: Mule is built entirely on RESTful APIs. From (SOA-)ESB, to Guerilla-SOA (API), to (API-)ESB again.
LikeLike
IMHO SOA is (was) an architectural style, not a technology stack. ESB is a pattern, not a product. From a high-level architectural point of view there’s really no big difference between SOA and the new Microservices / API-era.
SOA could be implemented in many ways, but it is of course strongly associated with the SOAP technology stack. And that technology has some disadvantages for sure, even though not that heavy-handed to implement as been stated. But nevertheless it never had any chance to appeal to developers.
IMHO the biggest problem with SOA was the strong reliance on separation of concerns (in general a good principle) to the extreme. Someone was supposed to provide the middleware, contracts and interfaces, another one to provide the producer, and a third one to provide the consumer. A proper business case would require several producers and consumers, which in most situations was wishful thinking.
Within the new era of APIs there are at least hope for smaller grained services that could deliver short term value and still the ability to provide reusable components.
LikeLike
I agree with Gerben’s comment that there’s no reason for SOA services be “big” or APIs be “small grained”.
If you were to model a web shop functionality (browse items, add to cart, place order, handle payment), you could probably do it with just two “SOA style” services (e.g. GetItems, PlaceOrder). Those could just as well be corresponding JSON/REST APIs (which you may also call SOA services).
On the other hand, technologies like e.g. GraphQL allows you to do many things at once – something that doesn’t fit very well to either SOA or REST kind of thinking.
Someone might argue that some APIs may well be “bigger” or more coarse-grained than SOA services, and provide even more value and reusability because of that.
LikeLike
To me, API Economy differs from SOA in a few, quite subtle ways.
1) I encounter SOA mostly related to integrations within an organisation or in B2B environment. SOA services usually have at least implicit concept of contract between the caller and the provider of a service. (Regardless of whether the contract is modelled as a WSDL document, a signed piece of paper or just mutual understanding.) APIs are more open in their nature: “Hey all developers in the World. We have an API. Take it and use it!”
2) In the API Economy era, you’re not just thinking about computer systems and their interfaces. Instead, you (should) focus more on the core values your organisation is offering to the surrounding ecosystem, and building APIs so others can leverage that value.
3) I think that in SOA, you are designing services. You think about the requirements of various users and try to make a service that’s reusable in different use cases. In API Economy, you’re more often exposing what you have. You look inside more than outside – realising that you get more innovative solutions by not trying to anticipate all use cases beforehand. I’m not saying that APIs aren’t (or shouldn’t be) designed. Just that the design philosophy may be slightly different.
4) Some programming languages and patterns make it clear whether it’s OK to directly read or modify an object’s properties, or whether you should always call getter and setter functions. SOA (IMHO) seems to state that there should be services to get and set property values, whereas APIs allow you to read and modify them directly.
Of course, you can use RESTful services to implement SOA. Perhaps you can also use the SOAP stack to implement your APIs, but often you don’t. It’s not just that SOAP is so last decade and requires more work or tooling from programmers. I think a big part of the difference is the contract aspect.
And of course, when you’re modelling the implementation, there’s not much difference between HandleInsuranceClaim SOA Service and /insurance/claim/ API.
The differences between SOA and APIs are in higher, more strategic levels.
LikeLike
As an architect I agree with you that many of the claimed innovations of ‘the API economy’ are merely a question of different focus and scale in use. And yes in Archimate terms, service and interface are indeed ‘two sides of the same coin’,
But in broader terms “SOArchitecture” is different from “API economy”. One is an architectural style, the other is a business model (in which focus on services has switched to focus on interfaces).
LikeLike
Agreed. Actually, I was inspired to write this because of Mulesoft’s “API-Led Connectivity” architecture style. But as probably nobody knows this term, I turned it into ‘API Economy’. But that is not quite right, because indeed the API economy is more like a business model.
LikeLike
Just bumped into your blog. Thanks for the article. I believe the main difference between the two architectural style seems to be the following:
– The SOA architectural style was driven bij a layering approach. Adding integration capabilities by introducing an ESB on top of legacy systems (of exposing database as services). Adding a proces layer (often with an expensive process engine) to automate business processes orchestrating the previously mentioned (data) services via (process) services and last but nog least introducing a centralized business rules engine to deliver (decision) services combining (parts) of previous services (and vice versa).
The microservice style has principles of self-containted services. Hereby I mean the service itself contains the process, business rules and data logic. In a way this service is oriented around business capabilities/ process groups. The service (or better deployable unit) is determined by business needs and not per se by a technological segmentation. So I would believe the technology layer of the given structure could be completely different from the SOA style and microservicestyle.
So my conclusion would be: the API economy doesn’t differ from the SOA approach fromt the context of the enterprise. But the implementation and it’s philosophy around business-IT alignment, landscape decomposition etc has some fundamental differences.
LikeLike
Forgot to tick the notify box 🙂 So doing it right now. 🙂
LikeLike
Many things have already been said. IMHO, the difficulty of creating services/APIs remains whatever the naming of things. Rest pushes for the “micro” approach (the CRUD style) which is often not a real business oriented way of providing business added value. Microservices introduce also the idea of building apps from many sources and many companies, but in order to do that, every provider/consumer must have a business model… so no change compared to SOA. Perhaps APIs mean lighter protocol (JSON).
When we go out of the basic micro service stuff, we come back into SOA (which BTW was not called like that before it was marketed under this term).
As Gerben said, the same content under a new branding.
LikeLike
Thanks for sharing this content! Its a nice view to compare the two with the help of ArchiMate. I did an overview of the two and here is my view on it:
Similarities between the two:
– Both enable an integration of IT – in contrast to monolithic systems that have no integration. A monolithic system can be the better option in areas where security is highly important or where there are no synergies with other systems expected, however, with the broad adoption of cloud technology and the required scalability, integrated systems are usually the preferred solution for architects
– Both try to identify independent pieces of software that can be applied in different contexts and environments. SOA does this with the help of services that deliver information from one to another system and microservices do this with APIs that provide standardized interfaces for communication
– SOA can have very different scopes, from very small to very big. Unlike the name suggests, this is also true for microservices, which can be just the authentication of a user at a service or the full purchase process behind your e-commerce basket
Differences between the two:
– The objective of SOA is to enable an integration and centralization of services. On the contrary, microservices have the objective to work on different platforms and in different environments that emerged due to the manifold cloud environments and mobile solutions that require to work on different operating systems.
– SOA is not dynamic and cannot fit for different purposes. They must be adapted or redeveloped every time a critical architecture piece of the involved technology changes. On the contrary, microservices try to be more independent by building on standardized interfaces that are valid across different technologies. However, there are often different standards, which can in the end lead to the same challenge that SOA has.
– SOA typically shares fundamental components across different services. On the contrary, microservices usually have everything they need within the service, duplicated in every single microservice. Microservices are hence a bit slower, but less dependent on underlying services in order to work.
Check out my blog if you want to read more about my content about microservices:
https://www.digitalroadmap.management/blog/tag/Microservice
LikeLike
One could say that there is nothing more integrated than a monolithic system… (sorry, could not to resist).
LikeLike