8/6/2019 An Enterprise Perspective
1/15
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 fromthe 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 ITHow SaaS Affects IT
Integration Architec ture
Composition ArchitectureBecoming a SaaS Provider
Conclusion
AcknowledgementsFurther 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 t ime, 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 anenterprise-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.
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 1/
8/6/2019 An Enterprise Perspective
2/15
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 assoc iated with the application service providers (ASPs) of the 1990s,
which provided "shrink-wrap" applications to business users over the Internet. These early attemptsat 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 andprocesses with other applicat ions was limited, and they tended to offer few economic benefits over
their locally installed counterparts.
Today, SaaS applicat ions 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, SaaSapplication 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 providerscharge a flat rate for unlimited access to some or all of the application's features, while otherscharge varying rates that are based on usage.
On the technical side, the SaaS provider hosts the application and data centrallydeploying
patches and upgrades to the application transparently, and delivering access to end users over theInternet 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 applicat ion'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 enterprisecan 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 thedeployment 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 direct ion, without having to abandon an expensive on-premise
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 2/
8/6/2019 An Enterprise Perspective
3/15
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 as30 days. Giving prospect ive 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 Catchingthe Long Tail in the MDSN Library.
Managing IT Focus
With SaaS, the job of deploying an applicat ion and keeping it running from day to daytesting and
installing patches, managing upgrades, monitoring performance, ensuring high availability, and so
forthis handled by the provider. By transferring the responsibility for these "overhead" activities toa third party, the IT department c an 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 astechnology 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. Farfrom being made obsolete by SaaS, the IT department has an opportunity to contribute to thesuccess 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 multiplecustomers over the Internet in exchange for a fee. In pract ice, 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 applicat ions 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
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 3/
8/6/2019 An Enterprise Perspective
4/15
periodsuch as a month or a quarterand is allowed unlimited use of the service during that
period.
Location: SaaS applications are installed at the SaaS hoster's location, while on-premiseapplications 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 inthis 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 largecustomers, so they can query the device for shipping information instead of hitt ing the
shipping company's servers with thousands of individual queries a day.Management: Traditionally, the IT department is responsible for providing IT service tousers, 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 SaaSFor 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 s egments , 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 cons iderations. SaaS applications typically provide some flexibility for customer
configuration, but this approach has its limitations. If an important application requires
s ecialized technical knowled e to o erate and su ort or re uires customization that a
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 4/
8/6/2019 An Enterprise Perspective
5/15
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 andfrom 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 andfrom 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
applicat ions, 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 sc ale, 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 jurisdict ions in which your organization operates and how they affect your
application needs.
Sometimes, technical and financial considerations also can have legal ramifications, such aswhether 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 meetthem.
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.
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 5/
8/6/2019 An Enterprise Perspective
6/15
Figure 3. Maturity mode l 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 applicat ion 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 ofrelated 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 incorporatesdocument 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-
enablin IT. Inte ration technolo hel s deliver this cornerstone throu h data transformation and
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 6/
8/6/2019 An Enterprise Perspective
7/15
process orchestration. This is analogous to the mise en place routine that is frequently pract iced 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 interact ing 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 c omplete 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 seamlesslyintegrated, 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 c ontract 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 providein 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 strateg ies. At some point, you might want to migrate away from a SaaSapplication 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 andcode escrow. (See "Integration Architec ture," later in the article, for additional advice on
preparing data for migration.)
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 7/
8/6/2019 An Enterprise Perspective
8/15
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 theprovider offers, and whether they are compatible with your business-intelligence
requirements.
Impact on IT Roles and Responsibili ties
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, andinstitutional 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 todetermine 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, trustworthyaccount 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 c lients foruse 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 otherbusinesses, 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 yourown 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 enableyou 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
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 8/
8/6/2019 An Enterprise Perspective
9/15
network, within the Internet "cloud." The integration architec ture 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 partof 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 creatingdata 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. Inmany 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 ex ternal data sources into a
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 9/
8/6/2019 An Enterprise Perspective
10/15
8/6/2019 An Enterprise Perspective
11/15
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 fac tors, 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 mightdegrade 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. Thisconnection 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 bythe 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 firstparty 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 applicat ion can involve somedegree 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-premisesystem 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 Topologiesat the Microsoft patterns & pract ices 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 bemade 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 credentialsseparately to each one. In addition to convenience, single sign-on means that users have fewer
sets of c redentials 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 willnot 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
'
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 11/
8/6/2019 An Enterprise Perspective
12/15
,
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 serverlocated 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 userwith a signed security token, which the SaaS provider's authentication system accepts and uses to
grant the user access.
Figure 5. A federation se rver provides enterprise customers with single sign-on
authenticat ion to a SaaS applicat ion. (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 ofimplementing 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 Act ive Directory Federation Services (ADFS) in
Windows Server 2003 R2.
Composition Architecture
Composite applicat ion is where business functions and information can be integrated effec tively 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 outstandingtasks 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 workto better make informed decisions. It also enables the creation of better "process intelligence,"
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 12/
8/6/2019 An Enterprise Perspective
13/15
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-c entric IT department, applications and other resources become ingredients that canbe combined together in just such a fashion, to c reate 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 des igned to draw from a number of different sources
of different types and in different loca tions.
At the lowest architectural level of the composition architec ture are the sources that providestored 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.
6/21/2011 Software as a Service (SaaS): An Enter
msdn.microsoft.com//aa905332.aspx 13/
8/6/2019 An Enterprise Perspective
14/15
8/6/2019 An Enterprise Perspective
15/15
2011 Microsoft. All rights reserved.
that could be monetized by providing it to other businesses. For example, a bank that hasdeveloped a sophisticated fraud-detect ion 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 servicesto the cloud, too.
Conclusion
Enterprises would do well to consider the flexibility and risk-management implications of addingSaaS 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.
6/21/2011 Software as a Service (SaaS): An Enter