From ESBs to API Portals: an Evolutionary Journey Part 3

In this article series we build the case for API portals, out of which the Intel® Mashery API Management platform are representative examples, as the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s execution of a business strategy and revenue generation. In the introductory article in Part 1, we discussed some of the business dynamics that led to cloud computing and the service paradigm. In part 2 we took look at the SOA transformation in the big enterprise. Let’s now examine the influence of SOA in small and medium businesses. At a first blush it would appear that only large organizations have the critical mass to a large number of application instances to make reuse under SOA economically justifiable. This is not really the case because of some unintended consequences and fortunately, a happy ending.

Let’s do a brief introduction to small businesses first to establish a context for the discussion. Between large companies and individual consumers lies the vast ecosystem of small and medium business, from mom and pop outfits to sizable companies, but perhaps not yet with global reach, the small and medium businesses or SMBs.

According to the U.S. Small Business Administration, small firms, defined as independent business having fewer than 500 employees, constitute 99.7 percent of all employer firms in the United States. Furthermore, small firms pay more than 42.9 percent of total U.S. private payroll and have created more than half of nonfarm private gross domestic product (GDP). According to the US Small Business Administration, the number of businesses in the United States in 2010 totaled about 27.9 million, out of which only 18,500 are were large firms. In other words, looking at the statistical distribution of all businesses in the United States, there is a long tail represented by SMBs. This long tail has a significant economic impact that cannot be ignored.

By their very nature of SMBs typically do not have a large IT budget, or a large IT department. Many of them have only a few IT literate employees acting as part time IT support. They could not afford the kind of “internal-only” or inside-out SOA adoption model described in Part 2. This fact effectively precludes the conditions under the inside-out SOA model.

However, it turned out that small businesses started partaking of the third party IT services used by large firms. How was this possible? That’s because service oriented IT, with metered, a la carte services enabled the delivery of IT in small, reasonably priced doses. Even a company without the resources to purchase and maintain a backroom server can purchase a cloud backup service for an affordable monthly sum.

Two factors are driving this demand from SMBs: the capital costs for a corporate owned data center, an insurmountable barrier for small firms, is now spread out over a large customer base. The service provider takes care of finding financing for the infrastructure acquisition and converts these costs to a monthly fee. The second factor is that although demand for IT services in any single SMB may be small when compared with a large company the aggregate demand is enormous as evidenced by the US Small Business Administration data, and hence serving the SMB segment can be a profitable endeavor. Companies like N-Able, CoSentry and Dataprise actually target small businesses.

Hosted servers may be an alternative. However if an IT department consists of two or three people, there may not be enough time or expertise to nurse the equipment through the entire life cycle and maintain the applications that run on them.

The dynamic playing out is that if a service can be delivered in small doses, the services used by large firms under the inside out SOA model are just as good for SMBs, and hence third party service providers enjoyed an additional tailwind coming from small businesses.

On the supply side, demand from SMBs represents a significant driver for the IT economy and presents opportunities to software and service developers in the supply chain. On the demand side we can safely claim that the IT economy has effectively reached not just SMBs but individual consumers as well. An individual consumer also follows this service model whenever she downloads a mobile application from the iPhone App Store or from Google Play, installs a Dropbox file hosting instance or activates Windows Skydrive. This practice is so commonplace today that it’s hard to imagine how revolutionary and how recent the concept is. Google Play started in 2012 and the “grandfather” of the app store, iPhone started in 2008. See Figures 1 and 2.

Figure 1.  Web Search Interest for “Google Play”.  Source: Google.

Figure 2.  Web Search Interest for “Apple App Store”.  Source: Google

Figure 3 illustrates the outside-in service integration process where a business application is built out of one or more service components available from a portal such as Intel® API Manager. The central application core described in the previous article that gets smaller as services get outsourced no longer exists. Instead applications are built from third party services, or more appropriately “servicelets” from the ground up.

Figure 3. A Compound Application with no Central Core

Given the “outside-in” potential, we conjectured back in 2008 that SOA would flourish in small organization environments as well. See the book “The Business Value of Enterprise Service Grids”, Intel Press. This prediction came to be, but with a twist: these service components live today in the cloud.

The democratization of SOA has taken a different dynamic: SOA has fled the enterprise and instead of reuse from within, or across organizations in large enterprises, a condition we thought necessary for critical mass for adoption, the critical mass actually happened across whole ecosystems, not just a single enterprise. In the process, these service components are remaking the IT industry and touching service consumers, providers and developers all the same. This dynamic essentially defines the third incarnation of the service ecosystem.

In the book, we proposed a model for SOA deployment that depended on a variety of ecosystem players providing composite applications that are used to build more complex SOA-style composite applications. Today we call these players cloud service providers or CSPs. Under this environment we can expect a degree of specialization where the individual services are provided by smaller players with the appropriate expertise. This situation is illustrated in the figure below.

To distinguish this approach from the traditional “internal only” or “inside-out” approach to SOA specific to large enterprises, we call it outside-in SOA.

The end state is a rich, diverse economic ecosystem with an excellent impedance match between technology and business needs

Who has a vested interest in making the transformation to outside-in SOA take place? It is a truism in an economic ecosystem that the cost equation for some players translates into an identical revenue consideration for another player. The whole ecosystem benefits when the value received greatly exceeds the cost expended for purchasers, and when sellers realize additional demand for products and services because of this value.

Consumers of services stand to gain because of the lower cost overall for procuring application capabilities via composite applications through composite services. SMBs get access to capabilities otherwise they could not afford. Large enterprises and service providers can generate additional cash flow from reduced capital expenses.

Canonical service components, i.e., services designed as services from the ground up, are not essential to make this scheme work. The traditional stovepiped applications in can be retrofitted through middleware shims to behave as composable services, in a manner not unlike screen scraping programs are used to extend the life and usefulness of legacy mainframe applications. The barriers to the outside-in model are lower than they appear at first analysis because the industry does not need to wait until a large repertoire of canonical reusable services becomes available.

The dynamic of this process is that as service economy matures, services will become and will be traded as commodities. This is leading to varying degrees of specialized providers. It simply will be cheaper to build specific functionality by contracting out constituent components in the marketplace rather than build the same functionality wholly in house.

The outside-in approach differs from traditional outsourced arrangements: the negotiation of an outsourced payroll function may involve months and real people at the table. On the other hand, outside-in transactions will be eminently automated, machine to machine and highly dynamic through automated registries and discovery services and using open standards. One such transaction might take from a fraction of a second to no more than a few seconds.

The externalization of service components allowing the quick assembly of applications from third party offerings brings challenges to service providers, developers and consumers alike. We will cover some of these issues in Part 4.

Comments are closed.