an enterprise perspective

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/


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




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




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




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/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




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




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




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




10/15


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

'




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,"




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.




14/15


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.


an enterprise perspective

Documents