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.

1. Software as a Service (SaaS): An Enterprise Perspective
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

2. 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.

3. 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

4. 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.
Aa905332.enterprisertw01(en-us,MSDN.10).gif
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

5. 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.
Click here for larger image
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.

6. • 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.
Click here for larger image
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

7. 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:

8. • 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.

9. • 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

10. 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

11. 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.

12. • 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.

13. 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.

14. 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.
Click here for larger image
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

15. 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.
Aa905332.enterprisertw06(en-us,MSDN.10).gif
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-

16. 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

17. 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.