White Paper published on Microsoft Architecture Center
http://msdn2.microsoft.com/en-us/architecture/bb507203.aspx
An Overview of Software as a Service in Retail
Wladimiro Bedin
Moin Moinuddin
May 2007
Summary: One of the emerging trends in the technology space is something known as Software as a Service
(SaaS). This paper provides an overview of different architectures, their pros and cons, and the key
technologies that are reinventing the centralized architecture now known as Software as a Service.
Contents
Abstract
Introduction
Business Challenges
Point-of-Sale Transactions
The Distributed vs. Centralized Architecture Dilemma
Client-Server Architecture
Centralized-Architecture Revival
Service-Oriented Architecture (SOA)
Smart Client
Software as a Service
Key Microsoft Technologies
Conclusion
References
Abstract
IT is evolving rapidly, and the retail industry is looking at how it can improve business. Retailers are facing the
challenge of how best to meet the need of an increasingly demanding customer base, while reducing the overall
costs. In addition to meeting customer demands, retailers are facing the challenges of integrating their various
functionalities and channels, which are mostly run as silos.
One of the emerging trends in the technology space is something known as Software as a Service (SaaS). This
paper provides an overview of different architectures, their pros and cons, and the key technologies that are
reinventing the centralized architecture now known as Software as a Service.
Introduction
The retail industry is known to lag behind other industries in adopting new technology. One of the major
reasons is the razor-thin margins with which retailers work, which demand the quick return on investment
(ROI) that are usually granted only by established technologies and methodologies
Looking back, the evolution of retail architecture has thus followed what happened in other industrial sectors,
moving from mainframe-based centralized architecture towards a departmental architecture where mini and
personal computers brought data processing inside the stores. However, this shift created the new problem of
data exchange with corporate systems. The evolution continued with client-server and then distributed
architectures and now is evolving towards service-oriented architecture (SOA). Also, new concepts like Software
as a Service (SaaS), which are achieving considerable success in the customer-relations management (CRM) sector,
are not present yet in the store applications; but the situation is changing. This paper will provide an overview
of SaaS and applicable technologies and their benefits to the retail industry.
Business Challenges
Retail presents some peculiar challenges. Inside the store, there are two very distinct software functions: the
store front, which is the "public" part devoted to check out that accesses data on products, customers,
promotions, and so on; and the store back-office or "private" part of the store systems, for stock management,
replenishment, reporting, labor scheduling, and inventory management. In some really small-footprint stores,
both functions are carried out on the same physical computer, but they remain very distinct in nature.
Figure 1. Retail store with front-end and back-office applications (Click on the picture for a larger
image)
Point-of-Sale Transactions
In retail, the point-of-sale (POS) transactions are extremely important, yet have unique issues when compared
to similar transactions in the B2B world. An obvious question is: Why is the problem of a delay in issuing a
small valued ticket (due to a hardware or software failure, or just slow response time) so critical? The same
problem for higher-valued invoices in a B2B transaction creates a limited problem, to the extent that it is not
even noticed. The reason for this is twofold:
Stores make their profits from a high number of low-value transactions, usually concentrated in part of the
day or part of the week and the check-out operations cannot be delayed during these times.
A POS interruption, even for a limited time, may cause not only significant economic losses but, even more
important, losses of customers gained with expensive and long effort.
The bottom line is that POS is more mission-critical than the back office. POS must function at all times,
irrespective of connectivity in the store, whereas back-office functions can wait for the connectivity to
comeback. It also points to the possibility of back-office functions running either inside the store or provided by
a service providers over the Internet.
The Distributed vs. Centralized Architecture Dilemma
Outside the store, there are many centralized activities, such as logistics, marketing, bookkeeping, and so on.
The efficiency of the retail activity depends on quantity and quality of data flow inside and outside the store.
Software architectural choices are very important and difficult, because reliability and data sharing are
conflicting factors.
Traditionally, POS systems are autonomous systems that exchange flat files in batch mode with back-office
systems for stock management and reporting. In the same offline mode and after a role change, the back-office
system exchanges sales and item data with corporate systems and other partners. This is defined as distributed
architecture where operations are supported by a local database, so that no external failure can stop such vital
operations.
The distributed architecture has a reliability and scalability advantage because it has no single point of failure
and processing is distributed, but requires a complex synchronization activity among autonomous systems with
their own databases and an expensive deployment. Store-sales information must be uploaded to the corporate
systems and item and promotion information must be downloaded to the store systems. In addition,
deployment of new applications, patches, and updates is not easy. There is also the issue of monitoring
systems at the stores to ensure that the critical systems are functioning normally at all times.
Figure 2. Distributed architecture (Click on the picture for a larger image)
In the centralized architecture, the store front-end systems (POS terminals, self service kiosks, and so forth)
are connected online to the store server over a network and exchange sales information in real time. In the
same way, the store back-office systems can be connected online to the corporate systems for exchanging
sales and item information. Permanent connection over a network makes richer data available, such as a
customer's previous transactions, specific promotions, real-time loyalty-points management, stock availability,
and next delivery date.
A centralized architecture with a single database solves the synchronization problem, but introduces a single
point of failure and scalability limit, both inside the store for POS management and outside for connection to
corporate systems. The central server failure or a network failure stops the business completely, with very
serious consequences.
Unfortunately, it is not possible to achieve the advantages of the distributed architecture (such as reliability and
scalability) without the burden of database synchronization. Many organizations that need services given only
by an online access to centralized data, being on the store or in the HQ, use redundant servers and connections
or emergency operations, but at higher costs and complexity.
When data exchanges among autonomous and heterogeneous systems are performed through flat files,
eventually with some "impedance-mismatch" problems or even with some data loss, the architecture is defined
as departmental.
When the data exchange among subsystems is performed by design with maximum fidelity, no data loss, and
automatic updates, the architecture is defined as distributed. Sometimes, the term "distributed architecture" is
used for "grid computing," the sharing of resources through a network of generic computers arranged to create
a virtual super computer. In our case, the term "distributed" is used just to emphasize a high integration level
among subsystems obtained at the application level, and not at the operating system level.
Only recently have the big enterprise resource planning (ERP) players offered vertical solutions for retail—
always deriving from acquisitions and after some efforts on user interface (UI), business rules, and data
integration. The majority of retail systems in use today are situated in the spectrum from departmental to
distributed architectures, with a gradual migration from the first to the second.
Figure 3. Centralized architecture (Click on the picture for a larger image)
Client-Server Architecture
In the client-server architecture—as the name implies—the client asks for some service, which the server will
fulfill. The client-server architecture represented an improvement over centralized architecture, because
presentation and user-interaction functions are transferred from the server to the client—normally, on a PC with
a processing power much higher than the old green terminals. This reduces the load on the server and leads to
an improved system scalability and responsiveness to the user. However, it does not solve the "single-point-of-
failure" issue.
In the retail industry, the client-server architecture is used more often inside the store—connecting POS to the
back of the store—and less outside using a unique centralized server for an entire chain of stores.
Centralized-Architecture Revival
With the increasing availability of high-speed Internet connections, centralized architecture is gaining new life,
not with old mainframes and green screens, but with modern and rich graphical user experience through
Windows Terminal Server from Microsoft, similar products from Citrix, or browser-based applications. Also
client-server applications, which depend heavily on the connectivity, received a huge boost due to the
widespread availability of virtual private networks (VPN).
The application software providers (ASP) of 10 years ago were based on a centralized architecture in which
data, business logic, presentation, and user interfaces resided in a data center—leaving in-store personal
computers underutilized.
ASPs offered solutions that provided following advantages:
No upfront licensing costs
No deployment hassles
Can be accessed from anywhere
Promised around-the-clock availability
However, some of these promises did not really materialize, such as the around-the-clock availability, as there
were outages at the ASPs. The user experience suffered also from bad response time when the low scalability of
the architecture added up with Internet latency. Therefore, the first generation of ASP solutions did not achieve
much success, due to their limited improvements, compared to traditional software. The correct way would
have been to redesign the applications for providing service over the Internet, which requires completely
different thinking.
In the retail industry, the success of ASP-based solutions was even lower, because the mission-critical nature of
POS operations demands availability of service and local data even during the loss of connectivity. In other
words, offline operations are critical in retail from both business and psychological points of view.
Service-Oriented Architecture (SOA)
Real-time connectivity among store systems, corporate systems, supplier systems, logistics, and other service
providers through the Internet is a great condition that all retailers strive for. Extensive research has been
devoted to overcome the limitations of terminal- or browser-based solutions.
AJAX and other rich Internet application (RIA) technologies are an answer to real-time connectivity and
responsiveness. However, they are not a solution for a POS where only a local application with a local database
can provide the necessary functionality and availability.
To meet this need, there is a new model—based on XML and Web services—that is delivering rich services from
an array of heterogeneous applications in a distributed architecture. Service orientation (SO) is the natural
evolution of current development models. The 1980s saw the object-oriented models; then, there was the
component-based development model in the 1990s; and, now, we have service orientation. Service orientation
retains the benefits of component-based development (self-description, encapsulation, dynamic discovery, and
loading), but there is a shift in paradigm from remotely invoking methods on objects, to one of passing
messages among services. Schemas describe not only the structure of messages, but also behavioral contracts
to define acceptable message-exchange patterns and policies to define service semantics. This promotes
interoperability and, thus, provides adaptability benefits, as messages can be sent from one service to another
without considering how the service handling those messages has been implemented.
Figure 4. SOA architecture (Click on the picture for a larger image)
Service orientation provides an evolutionary approach to building distributed software that facilitates loosely
coupled integration with its inherent scalability and resilience. With the advent of the WS-* specifications, Web
services architecture has made service-oriented software development feasible by virtue of mainstream
development tools support and broad industry interoperability. Although most frequently implemented using
industry-standard Web services, service orientation is independent of technology and its architectural patterns,
and can be used to connect with legacy systems, too.
Unfortunately, the benefits offered by service orientation and SOA have been obscured by the hype and
confusion that increasingly surround the terms. As awareness and excitement around SOA have swelled, the
clear lines that once defined service orientation have been blurred. However SO does offer some specific
benefits when used for the right purpose.
To increase SOA systems scalability, the service should be as stateless as possible. Not having to lookup the
client's state from the previous interaction conserves CPU resources. In addition, the coupling between service
users and providers should be as loose as possible or, in other words, asynchronous. Compared to traditional
client-server architectures (in which each client waits idly for its turn to be served), in SOA architectures, the
client usually switches to other tasks while waiting for the answer.
Smart Client
When an application exhibits the following properties, it is called a smart client and has the following
characteristics:
Utilizes local resources (CPU, GPU, and so on)
Consumes Web services
Operates online/offline where appropriate
Intelligent deployment/update
Figure 5. Smart-client properties
Close examination of these characteristics reveals that these are the same requirements as a POS application.
On the other side, as store's back-office functions are less critical and can, therefore, be designed to work only
when connected to the centralized systems, a rich AJAX-based client can be a good choice. But, especially with
complex applications, there are many benefits of smart clients. They marry the best of the Web with the best of
Windows, lower operation and development costs (especially when offline capabilities are limited), increase user
experience and satisfaction, and align with future technology. Moreover, they can be easily deployed with
ClickOnce, where the cost is as low as browser-based solutions.
Software as a Service
Service orientation brings many benefits with it in building agile, configurable, and scalable services. The
loosely coupled benefit of SO helps in building a centralized service that can be easily configured, can scale
based on the use, and can support multitenancy.
When a service is being built to support many customer needs, it is best to consider building it as configurable
and scalable service that uses metadata to provide different experiences to customers. A centralized service
that can support many customers with different requirements through metadata-based configuration is defined
"multitenant" and offers the best ROI, because it can provide different experiences to different customers
through configuration, reducing the cost of infrastructure. Using a housing metaphor, a multitenant system is
comparable to a block where a number of different flats share land, stairs, roof, and so on.
A single instance of service that can serve multiple customers over the Internet is now known as Software as a
Service (SaaS) and can be broadly defined as "software deployed as a hosted service and accessed over the
Internet." SaaS is going to have a major impact on the software industry, because it will change the way in
which people build, sell, buy, and use software. For this to happen, however, software vendors need resources
and information about developing SaaS applications effectively.
SaaS as a concept is often associated with the ASPs of the 1990s, which provided "shrink-wrap" applications to
business users over the Internet. As mentioned previously, in some ways, these early attempts at Internet-
delivered software had more in common with traditional on-premise applications than with modern SaaS
applications, 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, multitenant 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.
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. Figure 6 shows a sample SaaS architecture.
Figure 6. Sample SaaS architecture
SaaS can include a number of services and applications that are not commonly expected to be found in this
category. For example, consider Web-based e-mail services, such as Microsoft Hotmail. Although Hotmail might
not be the first example that comes to mind when you think of SaaS, it meets all of the basic criteria: A vendor
hosts all of the program logic and data, and provides end users with access to this data over the public
Internet, through a Web-based user interface.
Moving from the general to specific, we can identify two major categories of SaaS:
Line-of-business services (LOB) offered to enterprises and organizations of all sizes—LOB services
are often large, customizable business solutions aimed at facilitating business processes, such as finances,
supply-chain management, and customer relations. Typically, these services are sold to customers on a
subscription basis.
Consumer-oriented services offered to the general public—Consumer-oriented services are sometimes
sold on a subscription basis, but often are provided to consumers at no cost, and are supported by
advertising.
In retail, there are many opportunities in the LOB category, such as back-office inventory-management
applications, payment-processing applications, reporting services, and so on. We cover this in more depth in
the following section.
SaaS Benefits in Retail
SOA and SaaS concepts allow important cost reductions to better serve existing markets and open entirely new
ones. With his article "The Long Tail," in the October 2004 issue of Wired (see the References section), Chris
Anderson popularized the idea of the "long tail" in explaining why online retailers such as Amazon.com are
uniquely positioned to fill a huge demand that traditional retailers cannot serve cost-effectively.
Retail follows the famous 80/20 rule: The most popular merchandise (which is usually 20 percent) is bought by
80 percent of the customers. So, retailers are forced to decide whether to carry the remaining 80 percent of
non-popular merchandise in the store or carry more of the popular merchandise. The traditional "brick-and-
mortar" retailers concentrate on selling the more popular items, because they cannot possibly stock non-
popular merchandise. Online retailers, however, do not have to worry about limited shelf space. Shipping items
to customers directly from large warehouses around the world, they can advertise and sell the millionth most
popular title as easily as the most popular one. Access to this long tail of low-volume sales translates into a
huge amount of revenue.
So, what does this have to do with SaaS? Retailers face several challenges when they evaluate software to run
their businesses:
Upfront investment—The cost of the central system is usually not directly proportional to the number of
stores, weighing more on small or new chains.
Deployment cost—Traditional software must be installed and maintained by competent technicians traveling
from store to store with high cost and limited peak capacity. Also, remote maintenance over the Internet is
usually done one store at a time.
Technical competence—Successful retailers are usually more competent on customer needs and
products/services than on IT operations.
Data-sharing difficulties—It is quite easy to share data with HQ, but complex to do with third parties—such
as independent logistics, product catalogues, and market analysis—or when exchanging customer data with
other non-competing chains for joint-loyalty programs.
Cost of new software-feature implementation—The new feature, even if already available, must be
bought and deployed over some test stores. If acceptable, the general deployment cannot be immediate.
What SaaS offers is an opportunity to provide customized services to many small customers using a single
platform, which cannot be accomplished through traditional means. A widely known example of SaaS is
SalesForce.Com, which is able to offer CRM capabilities to many customers over the Internet using a single
system. This ability to offer functionality to multiple tenants is the biggest advantage of SaaS.
There are many other areas in which retailers can benefit from SaaS applications. For example, a retail
enterprise, switching from old systems to a SaaS POS integrated with their ERP, allows the implementation of
very sophisticated and new fidelity initiatives, so they can securely share data with other non-competing chains
through centralized retail Web services. New features can be tried and adopted only when they fit the business
model and the customer composition, without any spike in internal IT effort or risk. Because of this, with SaaS,
an independent store can use the same software as the large enterprise retailer—eventually, using it in more
creative and effective ways.
There is one key difference in the process of how traditional software is sold, deployed, and used compared to
SaaS-based applications. Selling SaaS is like selling mobile-phone ringtones or downloadable music: It should
be possible for a customer to visit a SaaS provider's site, subscribe to the service, pay with a credit card,
customize the service, and begin using it—all without human intervention on the part of the service provider.
This does not mean that a more personal approach is completely eliminated. It can still be used for larger
retailers with more extensive needs. But designing the sales, marketing, provisioning, and customization
processes from the ground up to work automatically makes it possible to offer an automated approach as a
choice; also, it has the happy side effect of simplifying the work that the support personnel of the service
provider must perform to accomplish the same tasks on behalf of a customer.
Figure 7 shows the SaaS maturity model as mentioned in the SaaS paper (see the References section). According
to this model, as soon as the services architecture is achieved, some of the services can be outsourced to a
SaaS-based service provider over the Internet. In this retail-based example, the fourth model shows that the
end-user application is composed of services—some of which are hosted internally and some of which are
provided by the SaaS-based service provider. This composition layer can be realized using either an AJAX-
based thin client or a smart client. The selection should be based on the business function and requirements for
up time.
Figure 7. SaaS maturity model (Click on the picture for a larger image)
If a retailer decides to use SaaS-based POS, the best option is to be smart-client–based, which can be easily
deployed over the Internet. Local databases must be synchronized, but the effort is paid back with increased
reliability and scalability.
Compared to traditional offline POS, a smart-client–based one exploits fully the online connectivity to central
resources offering additional services and work offline only when connectivity is temporarily lost—and,
therefore, will not upset the delicate POS transactions, as customers will not be affected if the service goes
offline, whereas a traditional offline POS performs always in the lowest mode.
In retail, the availability demand for back-office applications is lower than for front-office and, thus, can be
based on Web 2.0 technologies, such as AJAX and Windows Presentation Foundation/Everywhere (WPF/E); but,
for complex applications, a smart client offers a more robust and optimized development environment.
Key Microsoft Technologies
Key Microsoft technologies that help in realizing this architecture start with Microsoft .NET Framework 3.0,
Windows Communication Foundation (WCF), and Windows Workflow Foundation (WF). These two key
components of .NET Framework 3.0 help in creating Web services and workflows to realize this architecture.
.NET Framework 3.0 is released, and it is available on both the Windows Vista and Microsoft Windows XP
platforms.
Some of the other technologies are highlighted in this section.
ClickOnce
ClickOnce is a technology for application delivery and maintenance over the Internet in a simple and secure
way. The application package can be published on a Web site and installed through a Web page. A ClickOnce
application can operate on the workstation in isolated mode, protecting it from incompatibility and reliability
problems that may arise when a new application is installed on an already working system.
Initial installation and subsequent updates happen only after verification of the software maker and without
administrative credentials from the user, increasing the trust and acceptance of this technology. These and
other features reduce the total cost of ownership (TCO) for the user and allow the developer to distribute the
smart-client application to thousands of workstations with small effort.
SQL Server 2005
Central Web services and local smart clients are based on the Microsoft SQL Server family of databases. SQL
Server 2005 is used on the central retail Web services where native XML data management is very useful, along
with advanced maintenance and storage services. SQL Server Express is used on smart clients, because it is
equally feature-rich, but lighter and installable through ClickOnce.
Windows Communication Foundation (WCF)
WCF is the new unified programming model for communications. It has complete flexibility of:
Transport.
Encoding.
Message-exchange pattern.
Security.
WCF provides a unified software layer for exchanging data with every standard platform and in any condition.
Security is very important, and WCF assures integrity and confidentiality of data exchanged with the retail Web
services. WCF also increases the reliability and efficiency of the available channel.
Figure 8. WCF architecture (Click on the picture for a larger image)
Store back-office applications can be linked to the retail Web services through a WCF HTTP channel supporting
WS-* specifications, to make it interoperable with non-Windows applications. Alternatively, WCF makes
available a high-performance channel based on TCP—fully exploiting improvements in the .NET Framework 3.0.
Store back-office applications can automatically select the best protocol for the available channel; and, inside
the store, WCF allows a peer-to-peer cooperation among the workstations.
Windows Presentation Foundation (WPF)
Another power technology is the Windows Presentation Foundation (WPF). WPF is the new user-experience
platform, and is part of .NET Framework 3.0 for building highly interactive and sophisticated user interfaces
that provided a rich experience to users that was previously difficult with Windows Forms.
Figure 9. WPF architecture (Click on the picture for a larger image)
WPF solves this difficult problem and makes it very easy to build graphically rich user experiences for skilled
and unskilled users. Also, with WPF, it is possible for the first time for interaction designers and programmers to
cooperate using the new language, known as Extensible Application Markup Language (XAML, pronounced
"zammel"). XAML is a declarative XML-based language that is used to define objects and their properties,
relationships, and interactions. XAML is used also as a user-interface markup language to define UI elements,
data binding, eventing, and other features, as well as in WF, in which workflows themselves can be defined
using XAML.
Conclusion
The IT industry is going through a major change and technology is enabling this disruption. The lowering cost of
bandwidth, the availability of computing in new and cheaper forms factors and devices, and the increases in
productivity and usability have caused a massive growth in services over the Internet. The retail industry,
which operates on razor-thin margins, can certainly take advantage of these services to reduce overall cost and
enhance services. Microsoft technologies play a key role in enabling retailers to take advantage of this new
paradigm.
References
Anderson, Chris. "The Long Tail." Wired Magazine. Issue 12.10, October 2004.
Chong, Frederick, and Gianpaolo Carraro. "Architecture Strategies for Catching the Long Tail." Microsoft Developer
Network, April 2006.
Carraro, Gianpaolo, and Fred Chong. "Software as a Service (SaaS): An Enterprise Perspective." Microsoft Developer
Network, October 2006.
About the authors
Wladimiro Bedin was born in 1950; is married, with two sons; and holds a doctorate degree from Padova
University (Italy), performed research at KDD in Tokyo (Japan), and holds a MBA from CUOA Vicenza (Italy).
After some direct experience in retail, Wladimiro founded BEDIN Shop Systems, the first Italian Microsoft
Certified Partner, specializing in software for retail. In 1989, the company released the first store-management
system for Windows and, in 2002, the first .NET POS, achieving several nominations at SMAU Industrial Design
and Retail Application Developers (RAD) Awards.
Moin Moinuddin is an Industry Architect at Microsoft and is responsible for evangelizing Microsoft platform and
products to the Architects in the community. He is passionate about the payments industry and, especially, the
emerging technologies in the payment-processing space. Moinuddin works with Architects at customers and
partners. He is also responsible for influencing internal product teams in development of new products, to meet
requirements from the community. He evangelizes initiatives and developments in the retail and payment
industry to the Microsoft product teams and the Microsoft field. As an Industry Architect, Moinuddin regularly
speaks at payment and retail conferences and generates white papers that show how to build future payment
and retail products by using Microsoft platform and tools. In addition, Moinuddin represents Microsoft at the
National Retail Federation's ARTS group, where he chairs the subcommittee that is working on creating
standards for the retail industry and represents Microsoft on the SOA blueprint committee.
Prior to joining Microsoft, Moinuddin spent 12 years in retail and payment-processing companies. He was a key
member that developed POS solution for the retail industry, and then was part of a startup that built one of the
largest payment gateways for processing credit-card, electronic-check transactions. When VISA first announced
CISP, Moinuddin spearheaded the effort to rearchitect the complete platform to meet the compliance
requirements. Ever since then, Moinuddin has been closely involved with CISP and, now, PCI DSS initiative.
On the personal front, Moinuddin lives in Bellevue, WA (U.S.), with his wife and two children. Moinuddin holds a
B.S in Computer Science from Osmania University, India, and a M.S. in Computer Science from the University
of North Carolina, Charlotte (U.S.).