An Overview of Software as a Service in Retail


Wladimiro Bedin

Moin Moinuddin

May 2007

Applies to:
   Software as a Service (SaaS)

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. (13 printed pages)


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


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.


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.

Click here for larger image

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.

Click here for larger image

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.

Click here for larger image

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.

Click here for larger image

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

Click here for larger image

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

Click here for larger image

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.

Click here for larger image

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.


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.


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