Should I Build or Buy a SOA Layer Today?
With enterprises in every industry evolving their IT frameworks to meet the demands of new digital ecosystems and a burgeoning app economy, it's no surprise that we've received a few questions recently around whether it makes sense to build or buy the components of a Service Oriented Architecture (SOA) layer. And the answer? Generally not.
It certainly makes sense to extend the life of existing investments. If you already have a Service Oriented Architecture and you're finding that it's just not flexible enough to fulfill the requirements of today's projects, you need a path to evolve your SOA.
Before making new investments, one should ask about the problem that needs to be solved in today's business environment. Is it about making business functionality consumable? Does your business need to deploy functionality to mobile devices? To multiple channels simultaneously? At a faster pace than ever before?
If so, it makes sense to focus on the current generation of technology, which solves these types of problems. What you don't want to do is implement an old, albeit familiar, solution that is not designed to address today's business challenges. If you don't already have a SOA infrastructure you probably don't need one.
Already have an architecture?
The good news is that if you have stuff in place, it can probably be re-used. In a recent webcast, we discussed the harmony between an existing SOA layer and an API layer (Successful Transition from SOA to APIs for the App Economy). While it's true that overlap exists between the layers, they are each very good at specific things. Together they can create a solid architecture to meet the needs of today's mobile, social, and cloud-driven business ecosystems.
Starting from scratch?
So what if you are starting from scratch? In all likelihood, the problems you are trying to solve are around the exposure and consumption of existing assets (services, data, back-end systems). You want to look at technologies that are designed from the ground up for these types of problems, tools that manage the entire lifecycle of an API.
Some tools like service registries might not be needed at all. Others, like ESBs, can be very useful in extending your existing service functionality to the API layer. Since APIs are generally presented as a facade (or as multiple facades) and are proxied in an API gateway, it makes sense to pass certain types of requests to an ESB once the gateway completes its processing.
Separating interface from implementation
What I would not do is look at my services one by one and expose a mini-facade (API) for each one. Instead, look at the high-level functionality across the back-end systems - the kind of functionality and value that draws customers and partners to the business - and build a coherent facade for this functionality. This not only decouples the physical endpoints, but also separates interface from implementation (always a good thing!).
Allowing the interface and the service implementation to change independently means that services can be changed, updated, even combined without affecting the interface (API). Back-end services, systems, and data formats change frequently; interfaces should not! You don't want to expose frequent changes to your developers and partners. Instead they should see a consistent and intuitive interface so that they can concentrate on building great apps.
Obviously, the question of whether one should begin implementing a SOA-based architecture today depends on the particular circumstances of the company's existing technology and its business goals. Addressing every possible iteration is well beyond the scope of a single blog post. What we have tried to do instead is to re-frame the question and to provide the beginnings of a decision framework to help those currently facing this type of question.