Enterprise Shared Services and the Cloud

As an industry, we have converged onto a standard three-layered service model (IaaS, PaaS, SaaS) to describe cloud computing, with each layer defined in terms of the operational control capabilities it offers to its consumers. However, from the perspective of Enterprise Shared Services, this categorisation is not optimal. Shared services have unique characteristics around ownership, funding and operations, and they span SaaS and PaaS layers. And conversely, while line-of-business applications and application frameworks are categorised as belonging to the SaaS and PaaS layers respectively, they share some common logistical and management characteristics. This article proposes a refinement to the three-layered categorisation scheme that may help in making better planning, funding, deployment and management decisions as enterprises move their line-of-business applications as well as their shared utilities into the cloud.

Introduction

The traditional view of cloud computing, as defined[1] by the National Institute of Standards and Technology (NIST) of the US Department of Commerce, comprises a simple three-layered service model that looks like this:

(Click on the image to enlarge it)

While the IaaS and SaaS layers are straightforward and well defined, there are several aspects to PaaS offerings, and a lot of current activity is around analysing and classifying the categories of PaaS as well as the components within it[2].

The NIST definition of PaaS[3] is silent about its relationship with “middleware”, but somewhere along the way, PaaS seems to have acquired synonymity with middleware, and many sites now refer to PaaS as “middleware-as-a-service”.

Gartner has recently expanded this latter definition of PaaS to track many different kinds of middleware[4], of which they believe two broad subcategories are particularly important – Application PaaS (aPaaS) and Integration PaaS (iPaaS). Enhanced application servers with development tools and data stores are considered to be aPaaS (e.g., Force.com, Google App Engine), while examples of iPaaS are cloud-based versions of standard enterprise middleware[5], such as Apprenda's SaaSGrid and WSO2's Stratos.

The Gartner-enhanced service model of cloud computing therefore looks like this.

(Click on the image to enlarge it)

We will return to this model after a brief discussion of Enterprise Shared Services.

Enterprise Shared Services

In medium to large enterprises, it is common to see a department within the IT function devoted to the development and maintenance of applications and systems that do not have a single business owner, but are used or shared by multiple business units. This is in contrast to line-of-business applications, which usually have a well-defined owner in the form of a business unit. These shared systems are usually referred to as Enterprise Shared Services, Enterprise Utility Services or something similar. Common examples are Identity Management, Content Management, Integration, Presentation, Document Composition, Communication Gateways, etc.

There are some important differences between Enterprise Shared Services and line-of-business applications.

Expression of requirement

The requirement for a line-of-business application (e.g., a new foreign exchange trading system, or a new pricing engine) comes from a business unit based on business requirements. In contrast, the requirement for Enterprise Shared Services usually comes from the Enterprise Architecture function or the CIO's office, based on an analysis of reusable functionality. The driver has as much to do with rationalisation of functionality for reasons of efficiency as with providing new business functionality.

Funding and value-assessment model

Line-of-business applications are assessed for their return on investment by their respective business units, and funding is typically made available for their procurement or development through the business unit's budget once the required benchmarks are met. The returns from the development of Enterprise Shared Services are less tractable and rely on more tenuous projections. Funding is either made available through an Enterprise budget, or through allocations from one or more business unit budgets. Buy-in from business units in the latter case is more difficult to obtain because parochial considerations militate against enterprise thinking.

Phase-wise rollout

The rollout of a line-of-business application can often be staggered in terms of incremental business functionality, and funding can be matched to each phase, enabling calculations of return on investment at each phase. Partitioning of Enterprise Shared Services for the purpose of a multi-year rollout is less straightforward, because the phases are usually across business units rather than across features. E.g., an Identity Management system may be rolled out to cover one business application after another, but the complete set of Identity Management features may have to be deployed for the very first application (perhaps because of a packaged solution), and it could be very hard to design rollouts around incremental feature enhancements. This in turn impacts the funding model and could result in an onerous “first project pays” policy.

Chargeback of operating costs

The operating costs of line-of-business applications are relatively easy to calculate and charge back to the respective business unit. The corresponding calculation for Enterprise Shared Services is necessarily arbitrary. These chargebacks could often be challenged by business units that do not see the value of shared services.

These and other related operational and budgetary reasons make line-of-business applications very different from Enterprise Shared Services in the way they need to be funded, developed, deployed and maintained.

The Inadequacy of the NIST service model

The diagram below shows the overlaps between Enterprise Shared Services and line-of-business applications when juxtaposed against the cloud service model.

(Click on the image to enlarge it)

Aren't Enterprise Shared Services in “terrestrial” (i.e., non-cloud) environments similar to cloud services already? Well, Enterprise Shared Services are shared between business units in an organisation, whereas cloud services are shared between tenant organisations. When migrated to the cloud, Enterprise Shared Services would still be shared between business units within a single tenant organisation. How should charges for the use of Enterprise Shared Services be split between those business units? The cloud provider may not have visibility below the level of the tenant organisation. That's one reason why Enterprise Shared Services require specialised treatment.

Now, full-fledged cloud-based line-of-business applications such as Salesforce.com or SugarCRM are considered SaaS offerings. Frameworks and tools to develop line-of-business applications, such as Force.com and Google App Engine, are considered PaaS offerings (aPaaS, in Gartner's classification). Yet they are likely to share common characteristics of expression of requirement, funding, rollout and chargeback models.

In similar fashion, full-fledged Enterprise Shared Services such as document management services and communication gateways (fax, email, etc.) are examples of SaaS. Traditional “middleware” components such as integration tools fall squarely into the PaaS category (iPaaS in Gartner's classification). Yet, the two groups share similar characteristics of expression of requirement, funding, rollout and chargeback models.

These financial and logistical aspects are arguably more important to an enterprise than the Saas or PaaS monikers. From a management and operational point of view therefore, the three-layered NIST service model is unlikely to be adequate as a guide to planning and control. A different model is required.

A Proposed Refinement to the NIST Service Model

Rather than propose a radically new service model, we propose a simple division of the SaaS and PaaS layers into “vertical” and “horizontal” parts. “Vertical” refers to line-of-business applications, and “horizontal” refers to shared applications. This results in the following readily-understandable diagram.

(Click on the image to enlarge it)

A critic would point out that “Vertical PaaS” and “Horizontal PaaS” are nothing but “aPaaS” and “iPaaS” rebadged. That is true, but the meaning of the terms “vertical” and “horizontal” is uniform across both the SaaS and PaaS layers, and they suggest strategies that are business-unit specific and enterprise-wide, respectively. We would therefore suggest that they are more natural terms than aPaaS and iPaaS.

A Reference Architecture for Vertical and Horizontal SaaS and PaaS

There is value in drilling down a level to identify some of the horizontal components that comprise Enterprise Shared Services. The following diagram provides a relatively detailed view.

(Click on the image to enlarge it)

Description of components

The Vertical components of SaaS and PaaS are relatively straightforward. They are business applications and frameworks for building business applications, respectively.

Horizontal SaaS is also easy to understand. These are full-fledged applications that are shared across business units, and this sharing could exploit the cloud environment's multi-tenancy feature. Vertical PaaS for specific industry segments could be built on top of a Horizontal PaaS offering.

Horizontal PaaS is the most interesting. We believe there are three further layers to this.

At the lowest layer is Service Enablement. These are server platforms and libraries that allow business logic to be exposed as services.

The middle layer is Enterprise Integration, whose fundamental capability of “Core Integration” is implemented through a Broker component aided by specialised capabilities for Data Access, Messaging and Event Propagation. What turns Core Integration into an Enterprise-class capability is the addition of Identity and Access Management for security, and a comprehensive SOA Governance capability. The former consists of an access management module operating on a user repository, with the ESB supporting Identity Management by providing a reliable transport for user provisioning events and a Registry/Repository holding security-related policies. The latter capability comes about through a registry/repository of service artifacts, an event monitoring capability and a message transformation and logging capability (the Broker).

The topmost layer comprises higher-order SOA functions. These include, but are not restricted to, Process Coordination, Complex Event Processing, support for Presentation and client devices, Business Rules and Service/Content Aggregation (“mashup” capabilities).

Three components (for Service Hosting, Broker functions and Process Coordination) are the core building blocks of SOA, while the rest are supporting capabilities that refine and enrich solution designs. (While messaging & event transports and service libraries are also core to SOA, they are more “primitive” and a solution architect would not treat them as first-class building blocks.)

Clearly, Horizontal PaaS is about much more than integration, although integration is a central capability. Compared to “terrestrial” middleware, Horizontal PaaS needs to have the basic cloud characteristics of multi-tenancy, elasticity and metering/monitoring.

This reference model is useful to evaluate cloud-based SOA tool suites.

The possible dependency relationships between the vertical and horizontal SaaS and PaaS layers is shown below.

(Click on the image to enlarge it)

The traditional view of SaaS has been implicitly vertical, but as we have seen, Enterprise Shared Services are SaaS offerings that are different in nature from Line-of-business applications, and therefore deserve their own category (Horizontal SaaS).

For the same reasons, it is desirable to treat PaaS as belonging to vertical and horizontal categories, with the added wrinkle that Vertical PaaS offerings can be built on top of Horizontal PaaS, exploiting the generic middleware and other components of the latter and providing line-of-business-specific features as part of a framework that can be used to build full-fledged applications, i.e., Vertical SaaS.

Conclusion

The funding and operational management of Enterprise Shared Services require radically different strategies from those that are applied to line-of-business applications, and this distinction is likely to endure even in a cloud environment. The traditional NIST service model that classifies cloud offerings into SaaS and PaaS layers does not address the requirements of Enterprise Shared Services. It has therefore been necessary to refine the NIST service model to define vertical and horizontal variants to SaaS and PaaS in order to enable appropriate financial and operational models to be applied to them.

The detailed reference model that follows provides more clarity into the specialisation and functionality of the horizontal layers that comprise Enterprise Shared Services, and the dependency graph shows how the layers may relate to each other.

About the Author

Ganesh Prasad is an IT practitioner with 24 years of experience in software development, project leadership and architecture. His most recent experience over the last 8 years has been in governing the architecture of enterprise shared services (Identity Management, Integration, Presentation, Communication Gateways, etc.) in large financial services organisations. He has worked in India, the Middle East and Australia, and has been based in Sydney since 1998. He is currently working with WSO2 as a Consulting Architect and recently documented a lightweight approach to SOA in a white paper called "Practical SOA for the Solution Architect".

Ganesh writes extensively on technical matters. He has co-authored two books "Professional Linux Deployment" and "Beginning PHP4" by Wrox Press. He is also the co-author of the popular whitepaper, "Life Above the Service Tier", which introduced the SOFEA style of building application front-ends. A recent whitepaper of his, "Identity Management on a Shoestring", introduced the LIMA approach to identity management. He blogs at WisdomOfGanesh.blogspot.com

[1] As of September 2011

[2] Analyst Chris Haddad presents a comprehensive evaluation framework for PaaS

[3] NIST PaaS definition: “The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.”

[4] E.g., dbPaaS (Databases) and bpmPaaS (Business Process Management).

[5] Source: Online interview with Gartner Distinguished Analyst Yefim Natis. Gartner's original cloud definitions are not freely available.