Akana Platform Free Trial

Get Started Today »

Laura Heritage

In June I gave a webinar on the Business Value for Internal APIs in the Enterprise that was very well received by the enterprise community.   I have spent most of June and July travelling and speaking with enterprises in a huge range of industries on the topics I introduced in that webinar.   One topic that really resonated with every enterprise I spoke with was the notion of breaking down the SOA silos and the need for an enterprise to have an internal developer community.

For those of you that didn’t attend the webinar, let me explain what I mean by “SOA silos”.   Today, most enterprises are doing development among their individual teams or projects, where-in each line-of-business focuses on the immediate initiative at hand creating services, datastores, apps and APIs to fill the gaps without looking beyond their immediate line-of-business (LoB).  The goal of Service Oriented Architecture (SOA) was to break down these types of silos. The first step in this direction was the introduction of SOA Centers of Excellence (CoE) and the concepts of a registry/repository.  This led to what you see in the image below, where a few chosen architects formed a board and discussed what projects were being working on and what, if any, shared services might come out of it.    These shared services were then entered into the registry/repository.   Typically, it was the representative on the board or a person slated as the registrar who entered the shared services into the registry/repository, not the API/Service developer.


Figure 1: LoB SOA Silos

Figure 1: LoB SOA Silos


The result was some improvement in collaboration, efficiency, agility and cost savings among LoBs, as the architects in the CoE had the best insight into activity in other LoBs.   However, the actual development teams still remained in the dark.   Their only view of what was happening elsewhere in the organization came from whatever their LoB representative chose to share.    The registry/repository information helped the CoE architects understand top level shared business services, however it isn’t widely used by the developers within the LoBs.   This is still the case for most enterprises today.

There are many reasons for the developers not leveraging the SOA registry/repository.  For one thing, registries/repositories weren’t designed with consumption in mind.  They were designed for enterprise architects who were trying to get a handle on the services being created in the enterprise and who were trying to establish standards and policies for how services in the enterprise should be built. .  The SOA registries/repositories do this well, but expanding them to manage consumption was a manual and sometimes a difficult task. Developers didn’t really use the registries/repositories as intended, didn’t have access to them, or the consumption governance process was too cumbersome. Besides the lack of visibility into the services that were available in the enterprise and the lack of tooling to allow for easier consumption of the service/API, there were a couple of other obstacles to developer adoption of the SOA services.   Overcoming these obstacles is incredibly important in order to take SOA or APIs to the next level within the enterprise.  The first obstacle is the “not invented here” syndrome. The second is to the lack of trust about whether or not an API/service will perform as stated.

I have seen the “not invented here” syndrome disappearing and is almost a non-issue because of the popularity of the external API movement.  Lack of resources and the need to innovate quickly has developers borrowing, reusing and building on top of existing services and assets in order to achieve a break through, a new product or get to a new market.  The second obstacle around trust is also being broken down because of new technologies in the market that can help instill trust in the services and APIs.

Enterprises, especially those with a SOA and services background, have an opportunity to leap frog their competitors by leverage their internal developers.   The developer attitude, because of all the external API developer innovation, is primed to allow this to happen.   There is an inventive energy in the air and, no matter if they are inside an enterprise or not, it appears that people want to be part of creating the next big (or small thing) that changes the way we live.  The technology to enable this is now available.  SOA Software announced an enterprise API Catalog, an enhancement to their API platform, geared towards establishing internal developer communities.  This platform provides the day-to-day developer visibility over all APIs /services in the enterprise, across all LoBs, that are ready to be consumed, not just the few business services that the architects on the CoE communicate to the team.

The enterprise API catalog provides the ability to communicate and collaborate with other developers outside their LoB.  Developers can easily talk to other users of the API/service and with the API developers directly.  The API catalog surfaces information that a developer wants to see in order to begin using an API/Service.  It provides embedded tools in order to test the API/service right in the catalog.   Additionally the developer can see the current and past performance of the APIs in order to gain trust in the API/service.  Most importantly it provides a self-service automated consumption model removing any barriers, do to manual or cumbersome processes, for the developer to begin using the API/service.  By removing the limitations on the developers visibility of the APIs/services that are available in the enterprise, providing tools to make testing and consuming these APIs / services easier and removing barriers to consumption, enterprises can improve productivity, increase innovation and make a direct impact to the bottom line in terms of increased customer satisfaction, new revenue, or cost savings.

Enterprises need to break down the LoB developer silos that exist, as shown in figure 1, and establish an internal developer community as shown in figure 2.


Figure 2: Internal Developer Community

Figure 2: Internal Developer Community


As the enterprise’s internal developer community grows and matures, they are then poised for moving and expanding outward to intersect with partner developer communities and other external developer communities.  This will further increase the impact to the enterprise’s bottom line.


Figure 3: Intersecting Internal, Partner and External Developer Communities

Figure 3: Intersecting Internal, Partner and External Developer Communities


Establishing an innovation engine in an enterprise is as simple as enabling your developer community to do what they do best, create and innovate.   Tackle any mindset issues that impede the acceptance and put in place the tools to encourage the creative process.    Continually reward community innovation behavior and watch the productivity and the agility increase, see the innovation that can change your business and notice the impact on your bottom line.

Share Button

Add a comment