Gianpaolo Carraro
Fred Chong

Microsoft Corporation

October 2006

Applies to:
   Software as a Service (SaaS)

Summary: The third article in our series about Software as a Service (SaaS) addresses SaaS from the perspective of the enterprise consumer. (17 printed pages)

Contents

Introduction
Understanding SaaS
Benefits of Consuming SaaS
The SaaS Continua
Considerations for Embracing SaaS
The Service-Centric IT
How SaaS Affects IT
Integration Architecture
Composition Architecture
Becoming a SaaS Provider
Conclusion
Acknowledgements
Further Discussion and Feedback

Introduction

Software as a Service (SaaS) has the potential to transform the way information-technology (IT) departments relate to and even think about their role as providers of computing services to the rest of the enterprise. The emergence of SaaS as an effective software-delivery mechanism creates an opportunity for IT departments to change their focus from deploying and supporting applications to managing the services that those applications provide. A successful service-centric IT, in turn, directly produces more value for the business by providing services that draw from both internal and external sources and align closely with business goals.

This is the third article in our series about SaaS. The first two articles, which can be found by clicking here, focused on the details of developing SaaS applications and providing them to customers. This time, we'd like to turn the question around and look at SaaS from the perspective of the enterprise consumer: How can IT departments benefit from adding SaaS applications to their portfolio of services? What are the implications of adding externally hosted applications to an enterprise-computing environment? What will one have to do to get ready for SaaS? This article will address all these points and examine a few special cases in which it might make sense for your department to become a SaaS provider, as well as a consumer.

Understanding SaaS

Simply put, SaaS can be defined as "software deployed as a hosted service and accessed over the Internet."

SaaS as a concept is often associated with the application service providers (ASPs) of the 1990s, which provided "shrink-wrap" applications to business users over the Internet. These early attempts at Internet-delivered software had more in common with traditional on-premise applications than with modern SaaS applications in some ways, such as licensing and architecture. Because these applications were originally built as single-tenant applications, their ability to share data and processes with other applications was limited, and they tended to offer few economic benefits over their locally installed counterparts.

Today, SaaS applications are expected to take advantage of the benefits of centralization through a single-instance, multi-tenant architecture, and to provide a feature-rich experience competitive with comparable on-premise applications. A typical SaaS application is offered either directly by the vendor or by an intermediary party called an aggregator, which bundles SaaS offerings from different vendors and offers them as part of a unified application platform.

In contrast to the one-time licensing model commonly used for on-premise software, SaaS application access is frequently sold using a subscription model, with customers paying an ongoing fee to use the application. Fee structures vary from application to application; some providers charge a flat rate for unlimited access to some or all of the application's features, while others charge varying rates that are based on usage.

On the technical side, the SaaS provider hosts the application and data centrally—deploying patches and upgrades to the application transparently, and delivering access to end users over the Internet through a browser or smart-client application. Many vendors provide application programming interfaces (API) that expose the applications data and functionality to developers for use in creating composite applications. A variety of security mechanisms can be used to keep sensitive data safe in transmission and storage. Applications providers might provide tools that allow customers to modify the data schema, workflow, and other aspects of the application's operation for their use.

Benefits of Consuming SaaS

Of course, just because you can add SaaS to your IT infrastructure is not by itself a reason to do it; there has to be a viable business reason, too. SaaS offers substantial opportunities for organizations of all sizes to shift the risks of software acquisition, and to move IT from a reactive cost center to being a proactive, value-producing part of the enterprise.

Managing the Risks of Software Acquisition

Traditionally, deploying large-scale business-critical software systems, such as ERP and CRM application suites, has been a major undertaking. Deploying these systems across a large enterprise can cost hundreds of thousands of dollars in upfront licensing cost, and usually requires an army of IT personnel and consultants to customize and integrate it with the organization's other systems and data. The time, staff, and budget requirements of a deployment of this magnitude represent a significant risk for an organization of any size, and often puts such software out of the reach of smaller organizations that would otherwise be able to derive from it a great deal of utility.

The on-demand delivery model changes some of this. SaaS applications don't require the deployment of a large infrastructure at the client's location, which eliminates or drastically reduces the upfront commitment of resources. With no significant initial investment to amortize, an enterprise that deploys a SaaS application that turns out to produce disappointing results can walk away and pursue a different direction, without having to abandon an expensive on-premise infrastructure.

Additionally, if custom integration is not required, SaaS applications can be planned and executed with minimal effort and roll-out activities, creating one of the shortest time-to-value intervals possible for a major IT investment. This has also made it possible for a number of SaaS vendors to offer risk-free (and often literally free) "test drives" of their software for a limited period, such as 30 days. Giving prospective customers a chance to try the software before they buy it helps eliminate much of the risk surrounding software purchase.

For more information about the business benefits of SaaS, see Architecture Strategies for Catching the Long Tail in the MDSN Library.

Managing IT Focus

With SaaS, the job of deploying an application and keeping it running from day to day—testing and installing patches, managing upgrades, monitoring performance, ensuring high availability, and so forth—is handled by the provider. By transferring the responsibility for these "overhead" activities to a third party, the IT department can focus more on high-value activities that align with and support the business goals of the enterprise. Instead of being primarily reactive and operations-focused, the chief information officer (CIO) and IT staff can more effectively function as technology strategists to the rest of the company, working with business units to understand their business needs and advise them on how best to use technology to accomplish their objectives. Far from being made obsolete by SaaS, the IT department has an opportunity to contribute to the success of the enterprise more directly than ever before.

The SaaS Continua

In the "pure" form of SaaS, a provider hosts an application centrally and delivers access to multiple customers over the Internet in exchange for a fee. In practice, however, the defining characteristics between an on-premise application and a SaaS application are not binary, but are graduated along three different dimensions: how software is licensed, where it is located, and how it is managed. Each of these traits can be visualized as a continuum, with traditional on-premise software on one end and pure SaaS at the other. In between are additional options that combine aspects of both.

Figure 1. SaaS applications are distinguished by their conceptual locations on three different continua.

• Licensing: On-premise applications typically are licensed in perpetuity, with a single up-front cost for each user or site, or (in the case of custom-built applications) owned outright. SaaS applications often are licensed with a usage-based transaction model, in which the customer is only billed for the number of service transactions used. In between is the familiar time-based subscription model, in which the customer pays a flat fee per seat for a particular time period—such as a month or a quarter—and is allowed unlimited use of the service during that period.
• Location: SaaS applications are installed at the SaaS hoster's location, while on-premise applications are, of course, installed within your own IT environment. In between is the appliance model, in which the vendor supplies a hardware/software component as a "black box" that is installed at your location, instead of the vendor's. An example of an appliance in this sense would be a device that includes a logistics application with a cached and periodically updated database. A shipping company might provide such a device to its large customers, so they can query the device for shipping information instead of hitting the shipping company's servers with thousands of individual queries a day.
• Management: Traditionally, the IT department is responsible for providing IT service to users, which means being familiar with network, server, and application platforms; providing support and troubleshooting; and resolving IT security, reliability, performance, and availability problems. This is a big job, and some IT departments subcontract some of these management responsibilities to third-party service providers that specialize in IT management. At the other end of the spectrum, SaaS applications are completely managed by the vendor or SaaS hoster; in fact, the implementation of management tasks and responsibilities is opaque to the consumer. Service-level agreements (SLAs) govern the quality, availability, and support commitments that the provider makes to the subscriber.

Considerations for Embracing SaaS

For any given application or function, you can determine your SaaS readiness by plotting your organization's needs and expectations on each continuum, using Figure 2 as a guide.

Figure 2. Each continuum can be subdivided into three segments, representing traditional, SaaS, and hybrid approaches. (Click on the picture for a larger image)

If you mark all three boxes in the rightmost column, you're ready to explore making the move to SaaS. Marking all three boxes in the leftmost column means you should probably stick with a traditional on-premise solution for this application. Any other combination suggests that a hybrid approach might be appropriate; explore the marketplace to see if you can identify any solutions that are right for you.

Finding the right place on each continuum involves taking a number of considerations into account, each of which ultimately boils down to a tension between control and cost. Some of these considerations include the following:

• Political considerations. Sometimes, the decision can be short-circuited by resistance from within an organization, if important people insist that certain functionality remain internal, under the control of IT; other considerations therefore become unimportant. Test-drive deployments (see the previous subsection titled "Managing the Risks of Software Acquisition") might sometimes help convince risk-averse managers to approve pilot projects.
• Technical considerations. SaaS applications typically provide some flexibility for customer configuration, but this approach has its limitations. If an important application requires specialized technical knowledge to operate and support, or requires customization that a SaaS vendor cannot offer, it might not be possible to pursue a SaaS solution for the application.

  Another factor to consider is the type and amount of data that will be transmitted to and from the application on a regular basis. Internet bandwidth pales in comparison to the gigabit Ethernet links commonly found in enterprise LANs, and data transmissions that take a few minutes to transfer between servers in your server room might take hours to transmit to and from a SaaS application located across the country. Because of this, it might make sense to consider a solution that takes network latency into consideration. An appliance-based solution, for example, might cache or batch.

• Financial considerations. Consider the total cost of ownership (TCO) of a SaaS application, compared to that of an equivalent on-premise application. Although the initial cost of acquiring software capabilities through SaaS is normally lower than that of on-premise applications, the long-term cost structure is less certain. Factors that can affect the TCO of a SaaS application include the number of licensed users; the amount of custom configuration you will have to perform to integrate the SaaS application with your infrastructure; and whether your existing data centers already provide economy of scale, thereby reducing the potential cost savings of SaaS.

  Additionally, you might decide to delay implementing a SaaS replacement for an expensive or recently implemented application until it produces a satisfactory return on investment (ROI).

• Legal considerations. Some industries are subject to regulatory law in different parts of the world, which imposes various reporting and recordkeeping requirements that your potential SaaS solution candidates cannot satisfy. Consider the regulatory environments in all the different jurisdictions in which your organization operates and how they affect your application needs.

  Sometimes, technical and financial considerations also can have legal ramifications, such as whether candidate SaaS providers will be able to meet your internal standards for data security and privacy in order to avoid legal exposure. Consider any legal obligations you have toward customers or other parties, and whether SaaS will allow you to continue to meet them.

The Service-Centric IT

We've discussed the benefits of SaaS in fairly specific business and technical terms. Ultimately, however, the biggest impact might be the fact that SaaS provides the right incentives for guiding IT towards a service-centric model.

If we examine the evolutionary role that IT has played in an enterprise over the last few decades, we will observe that technology has evolved from its past duty of performing mundane recordkeeping and calculation tasks to today's business-differentiating functions of streamlining workflows and communications.

Figure 3. Maturity model of the service-centric IT (Click on the picture for a larger image)

Figure 3 shows a maturity model that depicts the mannerism in which businesses procure and benefit from technology capabilities.

In the early stage, when a business initially considers incorporating technology, it is common for the business to associate the solution to its needs with a specific application that provides a narrow function. For example, if a user needs to interact with a partner on the design of a hardware component, they might be satisfied with a simple e-mail application as the primary collaboration and communication tool.

As an enterprise realizes that specific business needs are best met through perhaps a class of related applications, and not just one application, it evolves to adopt a more service-centric view for its application portfolio. Going back to the partner-interaction example, the enterprise might realize that the collaboration effort can be enhanced through a Web portal that incorporates document sharing with versioning support, threaded discussions, real-time whiteboarding, and slide-presentation support. As a result, the enterprise might decide to purchase and deploy a portal solution to expand the collaboration IT service capability that currently only has e-mail features.

With more and more platform and line-of-business applications getting delivered through the SaaS delivery model, enterprises are presented not only with greater number of vendor options, but also increased choices for where and how the applications are being delivered. As mentioned earlier, SaaS influences an enterprise's allocation of resources through a variety of licensing, operation, and management models. The smart enterprise will be able to trade direct control (over service-implementation details) for the additional flexibility, to optimize the strategy and execution of its core mission. However, the extent to which an enterprise can exploit SaaS is directly related to its ability to transfer and mitigate risks, and getting a good handle on service-level agreement is a key part of the risk-management game. Therefore, expanding the boundary of an IT's service portfolio beyond its firewall signifies another level of business and technical sophistication from the service-centric IT.

Beyond risk mitigation, an enterprise that has embraced SaaS as part of its service-centric IT must learn to maximize the business gains from using features and data exposed through the portfolio of on-premise and in-the-cloud services. Ensuring that business data processed by the disparate systems is clean, consistent, and secure is usually the foundational step in building the business-enabling IT. Integration technology helps deliver this cornerstone through data transformation and process orchestration. This is analogous to the mise en place routine that is frequently practiced in established restaurants: Recipe ingredients, such as garlic, herbs, and so on, are properly diced, minced, and ground in preparation for the final cooking "repertoire" performed by the top chefs. By the same token, an efficient integration architecture helps consolidate and organize the information assets in the enterprise for upstream user consumption through composite applications. Composite applications provide the computing fabric for which business functions and information can be effectively composed (or mashed-up) for the end users. When interacting with a composite application, the end user is unaware (and has no need to be aware) of the true source of information, but is instead focused on synthesizing and analyzing business information with minimal technology-related context switches.

In essence:

• At level 1 (top-left corner), the enterprise user needs are rudimentarily addressed by a collection of siloed applications.
• At level 2 (top-right corner), the enterprise user needs are better addressed through a service portfolio, each consisting of related applications offering a more complete set of functionalities.
• Level 3 (bottom-left corner) is about service-portfolio optimization. The service portfolio is enhanced with additional options coming from SaaS providers, allowing the enterprise to further optimize its IT strategy and cost-allocation decisions.
• At level 4 (bottom-right corner), in-the-cloud and on-premise services are seamlessly integrated, offering a platform for composing applications closely aligned with business tasks.

The last two sections of this article provide more details on how integration and composition architecture play crucial roles for assimilating SaaS into the enterprise-computing strategy. Before we do so, however, the next section will look into the impact of SaaS on IT governance and roles in the service-centric enterprise.

How SaaS Affects IT

After you've made the decision to pursue SaaS, the next step is to prepare for the transition by assessing how the deployment will affect your existing IT assets, and by taking steps to ensure that the transition can be handled smoothly.

IT Governance Implications

Performing due diligence is a routine part of any successful IT infrastructure deployment project, so the basics should already be familiar to you. Some factors, however, deserve special consideration. Some areas to address in your due-diligence checklist include:

• Data-security standards. Moving critical business data "outside the walls" introduces a risk of data loss or inadvertent exposure of sensitive information. Assess your data-security needs, and ensure that the provider has measures in place to meet the standards you set.
• SLA guarantees. The management contract between you and the SaaS provider takes the form of service-level agreements (SLAs) that guarantee the level of performance, availability, and security that the SaaS vendor will provide, and govern the actions the provider will take—or the compensation it will provide—in the event that it fails to meet these guarantees. Ensure that these SLAs are in place, that the guarantees they make are sufficient to meet your needs, and that they provide a sufficient level of mitigation in even the worst-case scenario.
• Migration strategies. At some point, you might want to migrate away from a SaaS application to another solution, so it's important that you are able to take your existing data out of the application and move it to another one. Ask your prospective SaaS provider about any data-migration strategies and procedures it uses, including any provisions for data and code escrow. (See "Integration Architecture," later in the article, for additional advice on preparing data for migration.)
• In-house integration requirements. Ensure that migrating to SaaS will meet any functional and data-integration requirements your organization has in place. We'll discuss integration scenarios in greater detail, later in this article.
• Reporting services. Because SaaS involves giving up direct control of some of your data, accurate and useful reporting is especially important. Determine what reporting services the provider offers, and whether they are compatible with your business-intelligence requirements.

Impact on IT Roles and Responsibilities

As mentioned earlier, adding SaaS to the enterprise IT mix can cause a fundamental shift in the IT department's role as a provider of information services. Business units are sometimes caricatured as being afraid of change, but IT departments are not immune to organizational politics, either, and institutional resistance to SaaS can come from IT itself, as easily as from elsewhere in the company. In the past, the nature of software deployment has put chief information officers (CIOs) and their staffs into the role of gatekeepers who could exercise a veto over any proposed software deployment by simply declaring that they would not host it in the data center. With SaaS as an option, control of the data center does not necessarily equal control over the entire enterprise-computing environment, and this can cause the gatekeepers to fear a loss of control: A "rogue" vice president could just subscribe to a SaaS application for their department, bypassing IT entirely.

Of course, a CIO who relies upon control of the data center to control the greater computing environment has governance problems, anyway. Successful CIOs engage with business units, educate them about the impact of certain purchases on their future agility, and work with them to determine whether their needs would be best met by on-premise software or SaaS. By performing this consulting role, as discussed above, the IT department can add value directly to the business by matching up business units optimally with technology.

Impact on Regulatory Compliance

Statement on Auditing Standards No. 70 (SAS 70) is an international auditing standard that enables businesses that provide services to other organizations to provide an independent, trustworthy account of their internal control practices. An SAS 70 audit is performed by an independent auditor and results in an SAS 70 report, which the service provider supplies to its customers and clients for use when they themselves are audited. SAS 70 is not a law, but auditing and disclosure standards in various jurisdictions around the world (such as Sarbanes-Oxley in the United States) make up-to-date SAS 70 reports a de facto requirement for any business that provides services to other businesses, and any SaaS provider should consider having one readily available for examination.

SAS 70 is not a stamp of approval, in that it does not dictate a minimum set of standards that an organization must meet. An SAS 70 report only documents the internal control practices of an organization, without offering any judgment as to whether they are satisfactory. Due diligence therefore requires that you not only request an SAS 70 report from a prospective SaaS provider, but that you examine it thoroughly to determine whether the provider is able to comply with your own internal standards for privacy, data security, and so on. For example, if a local privacy law requires that your customers' personal financial data be stored in an encrypted form at all times, a provider's SAS 70 report will reveal whether the provider's own data-storage practices will enable you to remain in compliance with the law.

For more information about SAS 70, visit the Web site of the American Institute of Certified Public Accountants.

Integration Architecture

Subscribing to a SaaS application means housing business data outside the controlled local network, within the Internet "cloud." The integration architecture specifies how you bring this outside data into your logical infrastructure, so that infrastructure components can interoperate with one another (whether they are hosted internally or externally) and each component has access to data it needs, regardless of where the data originates.

In most cases, implementing a SaaS application involves transferring data from one or more existing applications or data repositories into the new system. Common scenarios might include:

• "Bootstrapping" the SaaS application with preexisting data from an on-premise source.
• Configuring a SaaS application to depend on data produced by an on-premise source for part of its functionality (for example, a CRM application that references inventory data managed by an on-premise inventory application).
• Configuring an on-premise application to depend on data produced by a SaaS application for part of its functionality (for example, an on-premise payroll application that references HR data managed by a SaaS HR application).

In many cases, however, integrating a SaaS application into your environment will mean creating data dependencies that require data to be synchronized and moved between the SaaS application and one or more in-house applications, to facilitate processing. An integration broker is used to manage data movement and system integration.

The Integration Broker

Many enterprises already are using some kind of integration broker for exposing application functions, orchestrating business processes, and integrating with internal backend systems. In many cases, the same integration broker can be customized and configured to perform integration and routing functions for a variety of internal and external data sources, including SaaS applications.

Figure 4. An integration broker brings together internal and external data sources into a unified whole. (Click on the picture for a larger image)

Data can originate from different sources, using different protocols and a variety of mutually incompatible formats. The job of the integration broker is to take data from a variety of sources, determine how and where the data needs to be processed and routed, and send each piece of data to its destination in a form that the target system can use. The broker takes the form of a pipeline architecture to which you can add and remove modules that perform specific integration operations. Multiple logical pipelines can be used to process data traveling in different directions. In a typical case, for example, one pipeline would integrate data from sources on the Internet with local data sources, and another pipeline would take local data and integrate it with SaaS data on the Internet.

Data enters and exits the pipeline through data channels that define the protocols used to communicate with data sources. For example, one channel might be established to transmit data from a particular Web service to the broker using SOAP; another might transmit the data from the broker to a SaaS application using FTP. (See "Data-Transfer Patterns," later in the article, for more information about data transfer.)

The modules plugged into the pipeline determine how the data is processed, routed, and integrated with data at the destination. A metadata service provides the configurable rules that each module uses to do its job. Common integration operations include the following:

• Security—Incoming data typically is processed by a security module, which performs operations such as authenticating the data source or digital signature, decrypting the data, and examining it for security risks, such as viruses. Security operations can be coordinated with existing security policies to control access.
• Validation—A validation module can compare the data to relevant schemas, and either reject noncompliant data or hand it off to a transformation component to be converted to the correct format. (See "Data-Transformation Patterns," later in the article, for more information about data transformation.)
• Synchronization workflow—A synchronization component uses workflow and rules to determine how data changes are propagated to destinations, and in what order. In cases where one of these workflow sequences cannot be completed successfully, the synchronization component can use transactional or compensation logic to "unwind" the data transfer gracefully, to guarantee data consistency across different systems.
• Routing—Finally, routing rules define the destination for each piece of data. Routing might involve simply transmitting all data from a specific source to a designated target; or it might involve more complex logic, such as determining a destination from content information, such as a customer ID number.

A data-availability service provides the means by which the integration broker can detect when new data is available. See the next section, "Data-Availability Patterns," for more information about the methods that can be used to determine data availability.

Data-Availability Patterns

Synchronizing data involves transferring new and changed data from the source to the target (the data sink), either at regular intervals or when precipitated by an event. Three basic patterns are used to trigger data synchronization between a local source and a SaaS application:

• Polling—With polling, one source queries the other for changes, typically at regular intervals.
• Push—Push is the opposite of polling. In a push relationship, the source with the changed data communicates changes to the data sink. A data source can initiate a push every time data in a data source changes, or at regular intervals.
• Publish and subscribe—Event-based publication and subscription is a hybrid approach that combines aspects of both polling and pushing. When a change is made to a data source, it publishes a change notification event, to which the data sink can subscribe.

Different approaches are appropriate for different data, and you may decide upon a combination of approaches for a single application. The correct approach to use for detecting data changes can depend on a number of different factors, including whether data changes must be reflected at or near real time, and how many data sinks must be integrated with the data update. In some cases, you might have to seek a compromise that balances opposing interests. For example, a push approach is usually best for data that must always be kept up to date; but pushing data out to a large number of interested sources can be computationally and network intensive, and might degrade application performance. Whichever approach you choose, you must develop rules to govern implementation details, such as polling frequency, syndication format, and so forth.

Data-Transfer Patterns

Data can be transferred between two endpoints using synchronous or asynchronous communication techniques. A synchronous transfer is akin to an interface: When one party requires information, it connects to the other party and requests it, expecting to receive the result immediately. This connection can take place in a variety of ways. Synchronous transfers can be simple file transfers, or they can take place through FTP, HTTP, or some other method.

In an asynchronous transfer, the information can be transmitted by the sender and processed by the receiver at different times. Asynchronous transfers are typically message-based: One party sends a message to the other party requesting information, without expecting an immediate response. When the second party has processed the request, it sends a response back to the first party in another message. Messages can be sent by e-mail protocols such as SMTP, for example, or by message-queuing technologies.

Data-Transformation Patterns

Data transformation means taking data from one source, and altering its format and/or content so that it can be used by the data sink. Exchanging data with a SaaS application can involve some degree of data transformation. For example, one of your existing on-premise systems might exchange data using the EDIFACT standard, while the SaaS application you are integrating uses an incompatible XML-based format to send and receive data. Data emanating from an on-premise system must be transformed before it is sent to the SaaS application, and vice versa.

Transforming data is a multi-step process. Firstly, the incoming data should be validated against the appropriate data formats and schemas, to ensure that it will be usable after transformation. Optionally, the data can be enhanced by combining it with data from another source. Finally, the data itself is converted to the target format.

For more information on data-integration patterns, see Data Integration and Integration Topologies at the Microsoft patterns & practices Web site.

Identity Integration

From the user's perspective, as we noted earlier, whether the application is physically hosted inside or outside the enterprise firewall should not be an issue: Applications in multiple locations should be made accessible in a convenient and consistent way. One very significant component of this consistent user experience is single sign-on: Users enter their user name and password when signing on to the Microsoft Windows operating system at the beginning of the day, and thereafter can access applications and network resources without having to present their credentials separately to each one. In addition to convenience, single sign-on means that users have fewer sets of credentials to keep track of, and reduces the security risk of lost or misplaced passwords.

From the IT management and governance perspective, single sign-on means that support staff will not have to manage independent sets of credentials. It also facilitates identity integration in other ways, such as enabling the reuse of existing application-access policies to control access to SaaS applications. For example, a policy might indicate that a certain manager has the power to approve any purchase under a certain price, and you'd like a SaaS application also to recognize that permission. Integrating your directory service with a SaaS application means you won't have to replicate policy information manually when setting up your account.

SaaS applications can provide single sign-on authentication through the use of a federation server within the customer's network that interfaces with the customer's own enterprise user-directory service. This federation server has a trust relationship with a corresponding federation server located within the SaaS provider's network.

When an end user attempts to access the application, the enterprise federation server authenticates the user locally and negotiates with the SaaS federation server to provide the user with a signed security token, which the SaaS provider's authentication system accepts and uses to grant the user access.

Figure 5. A federation server provides enterprise customers with single sign-on authentication to a SaaS application. (Click on the picture for a larger image)

Implementing a federation server that uses well-known standards for remote authentication, such as WS-Federation or Security Assertion Markup Language (SAML), will help ease the process of implementing single sign-on with a wide range of SaaS providers.

Microsoft provides a number of resources for working with directory federation. For more information, see Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 and Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2.

Composition Architecture

Composite application is where business functions and information can be integrated effectively for the end users. The business benefits of a well-designed composite application are many and include reduced redundant data entry, better human collaboration, heightened awareness of outstanding tasks and their statuses, and improved visibility of interrelated business information. Generalizing the principles of composite applications at a more theoretical level, we observe that presenting information as a unified whole, instead of as isolated streams of data, carries benefits for users. It enables them to better see relationships between data from different sources, and apply their own "domain intelligence"—their own preexisting knowledge of how the business and its processes work—to better make informed decisions. It also enables the creation of better "process intelligence," which gives users an improved view of their own tasks and responsibilities.

Consider a doctor in a hospital. During the course of the day, the doctor might have to work with a wide variety of information related to patient care: X-rays, patient histories, prescription and pharmaceutical information, insurance-coverage restrictions, bulletins from the government health ministry or disease-control center, and so on. Normally, each of these kinds of information can be tracked by a separate application, which creates inefficiency for the doctor. The hospital, its staff, and its patients might all be better served if each of these functions was integrated into a single application that integrates business intelligence (like the kinds of information listed above) with process intelligence (like the operating-room schedule and the status of the doctor's active-patient queue), as well as collaboration tools that facilitate consultations with colleagues.

In a service-centric IT department, applications and other resources become ingredients that can be combined together in just such a fashion, to create task-focused composite applications that bring "business intelligence" and "process intelligence" together in a single package. Creating a composite application is not easy: It involves bringing together different applications, protocols, and technologies that weren't necessarily designed to communicate with one another, and integrating them into a seamless whole. The composition architecture is intended to make this possible.

Figure 6. Composition architecture is designed to draw from a number of different sources of different types and in different locations.

At the lowest architectural level of the composition architecture are the sources that provide stored or processed data as "raw materials." Sources can include internal applications, internal databases, SaaS applications, Web services, flat files, and numerous other sources. Many SaaS applications provide APIs that expose various properties and methods that you can use directly.

The composition layer is where the raw data is aggregated and provided to the user in a new, unified form. Its function is to transform data into business information and process intelligence, and vice versa.

The composition layer is itself composed of a number of components that manage access, data, workflow, and rules. Applications, databases, Web services, and other resources "plug-in" to this layer through service agents, which take care of the details of negotiating connections and exchanging messages with each service. The identity-management component ensures that users are properly authenticated and authorized, and can also manage credentials for communicating with Web services, which often require credentials that are different from the one the user supplies to access the local network.

The data-aggregation component of the composition layer takes the information from data sources and transforms it in ways defined by the application entity model. For instance, a catalog entity might need different pieces of product and inventory information from different systems. This information is then presented as a unified, correlated set of data to the end user. The workflow component organizes the information with conditions and flows to guide human interaction and collaboration; and the eventing mechanism enables notifications to be sent and received when specified conditions are met, so that the end user can react appropriately.

The user-centric layer presents the composite data to the user in a central, integrated, task-focused user interface that provides both information for decision-making and functionality for taking action. This is perhaps the fullest expression of the potential of the service-centric IT: combining the best aspects of any number of applications and data sources into a single application that is focused on the needs of the user, instead of on the capabilities and limitations of any one system.

There are many more business, architecture, and technology details that can be written about composite applications. The upcoming Architecture Journal Issue #10 will cover this topic in greater depth.

Becoming a SaaS Provider

We've discussed how businesses can benefit from becoming SaaS consumers. In some cases, businesses can benefit from becoming specialized SaaS providers, too.

Becoming a SaaS provider can benefit a business that has dependent entities—such as franchisees or resellers—with which it has a strong business relationship, but poor IT process automation and information transfer. For example, consider a fast-food chain that operates through the franchise model. Some or all of its restaurants are owned by independent franchisees who contract with the franchiser for branding, recipes, and perhaps stock and facility rental. The franchisees have neither the personnel nor the budget to deploy and maintain satellite IT infrastructures at their location, so most or all of their communication with the franchiser tends to be done the old-fashioned way: through the postal system, by phone, during periodic meetings at a district office, or using some other non-technical method. A better IT relationship between the central business and its franchisees could raise the quality of services by improving information transfer and enabling certain processes to be automated.

This is where SaaS comes in. By becoming a SaaS provider, the central business can host specialized applications for its franchisees, for business functions such as inventory control, accounting, promotions, loyalty programs, and so on—applications that franchisees around the world can access using only an ordinary personal computer and broadband connection. This arrangement benefits all the parties in the relationship. In the example given, the franchisees benefit from applications that would otherwise not have been available to them. Similarly, through the usage of these applications by the franchisees, the franchiser receives enhanced feedback and data that contribute to more accurate and valuable business intelligence.

An enterprise might also consider becoming a SaaS provider if it has developed a valuable IT asset that could be monetized by providing it to other businesses. For example, a bank that has developed a sophisticated fraud-detection system for internal use might develop a commercial version and offer it for subscription as a SaaS application. The same principles that make it feasible for an enterprise to consume services from the Internet cloud can make it possible to offer services to the cloud, too.

Conclusion

Enterprises would do well to consider the flexibility and risk-management implications of adding SaaS to their portfolios of IT services. Integration and composition are critical components in your architecture strategies to incorporate SaaS successfully as a fully participating member of your service-centric IT infrastructure.

Finally, we believe that the future of enterprise computing is not going to be purely on-premise or in-the-cloud. Instead, like the yin and yang, they will exist in symbiotic harmony.

Acknowledgements

For his help with technical writing, many thanks to Paul Henry.

Further Discussion and Feedback

For further discussion on this topic and many other SaaS-related topics, visit Fred Chong's blog and Gianpaolo's blog. For feedback about this paper, please e-mail either Fred Chong or Gianpaolo Carraro. Thank you.