Enterprises pursing a SOA strategy over the last decade often put increasing reuse high on their list of objectives, reasoning that they were wasting a lot of money on needlessly redundant copies of the same services, also driving up maintenance costs. Yet many firms have struggled to achieve meaningful reuse, and some have either given up on reuse, or at least significantly lowered its priority as an organizational objective. Now that we are well into the era of APIs, mobile, and cloud, it’s right to ask the question “should we pursue reuse, and if so, how much?”
One of our customers demanded that their developers register all their SOA services in a registry-repository, and was dismayed to learn that the thousands of services eventually registered were 80% redundant – rather than perhaps 2000 services, they really had only about 400, implemented five times over. Upon further investigation, it became clear that at the critical moment when each team decided to build a new service, they were rarely aware of any opportunity for reuse, despite the registry-repository. This happened for multiple reasons:
- Information entered the registry-repository too late – not at design-time, when the potential for a service was first identified, but only later, when it had already been implemented. Multiple teams working in parallel could not see that their parallel efforts were often spawning similar services.
- Registry-repositories are not a collaboration environment. Providing a searchable repository only helps if it’s integrated into the service design lifecycle, makes services easy to find, and contains all the information that’s needed to identify a common service – its full data and service lineage. Registry-repositories lack all these crucial features (whatever other benefits they may provide).
The community of developers using APIs, building mobile apps, and exploiting cloud platforms, is understandably more enthusiastic about the potential for reuse, given the contribution of API portals to making it easier to find and reuse APIs. As firms promote their API platforms aiming to develop an API ecosystem, they drive reuse of these APIs, especially when they take steps to get developers to love their APIs. So how should enterprises think about reuse today? Consider that:
- Enterprise reuse scenarios blend internal and cloud services. APIs put all services on a level playing field, although not all internal/private services need be made public, any of them can be made public when circumstances demand it.
- Core SOAP services can and should be included. Several of our customers have achieved quick wins by creating an API Façade over their SOA (often SOAP) services. The interface often differs, but the core reusable business functionality remains the same whether it be for customer information, order management, sales tracking, or logistics.
- Not all APIs are meant to be reusable. One industry pundit I know quipped that we should be talking about AOS, not SOA – Application Oriented Services. There’s a lot to that idea, in that mobile apps often require APIs that are uniquely fitted to their particular requirements. This pattern of layering “consumption APIs” at the edge over “exposure APIs” (or SOAP Services) that encapsulate reusable business services at the core has a demonstrated track record of delivering both reuse and flexibility.
But I think there’s another equally important set of reasons driving greater success with reuse in the API era, which is increased developer adoption brought by the greater consumability, lighter weight, and flexible nature of the API approach. The opportunity to strike a healthy blend of code-first and contract-first approaches, combined with the way tools in the API space tend to drive collaboration, also promotes adoption. Developers are fishing in a larger sea of services, which tends to operate as a meritocracy, rather than the more rigid, top-down kind of reuse regime often associated with SOA.
Shape Your Reuse Strategy To Promote Business Agility
As SOA experts have pointed out for many years, the key reason to seek reuse is not mainly for the savings through avoiding redundancy: it is to achieve business agility through equipping teams with rapid access to the portfolio of core APIs and services they need to quickly deliver powerful business solutions. Driving successful reuse also positions your firm to respond more quickly to changing business circumstances, as you can rapidly pivot your core APIs and services, with those changes immediately available to all the apps that consume those APIs.
This kind of leverage can be a bit frightening without an effective collaboration environment for managing design and change of these critical APIs and services. Such an environment should enable rapid impact analysis of proposed changes, and automate as much as possible the implementation of those changes, including updating all affected APIs and contracts. To support these capabilities, your service design platform must include all the information required to see how all your APIs, services, and data are connected “under the covers.” Registry-repositories lack this critical information, too.
One way or the other, you need a more effective service design platform to fully exploit the potential of APIs and services to drive business agility. It’s time to revisit your assumptions about your approach to managing your API and service portfolio, so you’ll be properly equipped to meet this rising challenge.