Software as a Service is the most mature of the three cloud service models. Early pioneers like Salesforce.com have perfected the execution of delivering complete applications in the cloud that cloud service consumers can access over the Internet with a browser. The SaaS providers have total control over the infrastructure, performance, security, scalability, privacy, and much more. SaaS vendors typically offer two ways for their customers to use their applications. The most
common method is a web-based user interface that usually is accessible on any device that can connect to the Internet. The other way is to provide APIs to their customers so service consumers can integrate features into their existing applications or with other SaaS solutions.
A company should use SaaS to outsource all applications, features, and services that are not a core competency, assuming it meets its needs and is affordable. For example, if a company is not in the business of writing HR, payroll, customer relationship management (CRM), and accounting software, it should not build these applications. Buying these applications and running them on-premises is not cost effective with the emergence of SaaS alternatives. Why buy the software and servers, manage the servers, and pay people to manage, patch, secure, and provide other non-value-add tasks to keep these services running?
SaaS solutions fall into many different categories. The most popular are enterprise business applications like CRM, enterprise resource planning (ERP), accounting, human resources, and payroll. There are a number of IT infrastructure SaaS solutions that deal with security, monitoring, logging, testing, and so on. The data category includes business intelligence, database as a service, data visualization, dashboards, data mining, and more. The productivity category includes collaboration tools, development tools, surveys, e-mail campaign tools, and much more.
Because SaaS providers cater to many customers they often do not provide the same level of flexibility that a company would have if it built its own application. Sometimes
companies choose to build their own applications because there is a feature or a configuration that they want but can’t find from the SaaS vendors. Before a company decides to build it itself, it should consider all of the tasks that SaaS vendors perform on their customers’ behalf and factor them into the total cost of ownership:
• Vendor is responsible for security updates and patches.
• Vendor manages all infrastructure and data center. • Vendor usually provides mobile compatibility for
majority of phones and tablets.
• Vendor provides compatibility across all major browsers and versions.
• Vendor frequently updates features and updates are seamless to end user.
• Vendor manages databases, including capacity planning, backup recovery, and so on.
Before a company decides to write the application itself, it should compare the value of the feature(s) that the SaaS tools cannot provide against the TCO of building it itself. Another part of the equation is to consider the opportunity cost for shifting the resources to another project or reducing the number of resources to lower costs. Once a company builds an application it must pay ongoing to keep it current and fix bugs. The speed of change in technology is amazingly fast. Can a company continue to invest precious IT resources upgrading legacy applications to work on the next new phone or tablet? When the next social media darling, like Pinterest, appears out of nowhere, can companies quickly react and integrate with the API? To stay current with technology, companies will have to invest a substantial amount of
resources to make these upgrades. Every hour spent keeping up with technology changes is an hour a company is not using to build the next new product or an hour it is not using to reduce costs.
AEA Case Study: Use Case for SaaS
Let’s take another look at the business architecture for Acme eAuction’s future PaaS platform inFigure 5.2.
Here are some of the constraints (organized in the five categories we discussed previously) that Jamie collected in Chapter 4:
1. Technical. Dynamic traffic loads from third parties, increase security.
2. Financial. Reduce infrastructure costs.
3. Strategic. Increase revenue via third-party integration. 4. Organizational. Lack of cloud and SOA skills.
5. Risk. Must get to market quickly (six months).
As Jamie looks at the constraints on his project, it is obvious that speed is important. The ROI of the entire initiative is based on an aggressive time frame. Time is a major constraint on the architecture. There is a risk of opportunity costs if the project is late. The team has been asked to reduce the infrastructure footprint. Another critical constraint is the lack of skills. Here is Jamie’s assessment of the constraints on the architecture:
We have very little time to get this high-priority project to market. We lack the skills at the current time, and we need to find ways to get to market with less hardware than in the past. Jamie decides that based on these constraints he needs to evaluate where within the business architecture he can leverage SaaS solutions to address the constraints. He knows from his studies that anything that is not a core competency is a good candidate for leveraging SaaS solutions. After reviewing the business architecture, he writes down the following components as SaaS candidates for his team to research and validate:
API layer. His team has limited experience writing Representational State Transfer (RESTful) APIs in the cloud. They have to support multiple third parties, resulting in the need to support multiple stacks, manage API traffic performance, quickly integrate new partners, and so forth. An API management SaaS tool looks like a good solution.
My cart. There are many shopping cart SaaS solutions available.
Payments. If they offload payments to a Payment Card Industry Data Security Standard (PCI DSS)-certified SaaS solution, the entire platform will not be in scope for PCI DSS audits. This will save a lot of time and money.
Utility services. All of the utility services are candidates for SaaS because they are not core competencies. However, they may be provided from a PaaS or IaaS solution, as well.
Enterprise systems. The ERP, financial system, and CRM systems are perfect candidates for SaaS as they are not core competencies and there is no added business value for managing them internally. They are not in the critical path for the first phase (integrate with third parties), but they may have a significant contribution to the goal of reducing infrastructure.