Understanding saa s

Editor's Notes

• #2: So, what is SaaS? In simple terms, SaaS, which stands for Software as a Service, is a software distribution model where a provider, such as Oracle, hosts applications and makes them available over the internet. The origins of SaaS are broad, but there were three primary reasons why SaaS became popular back in the 90s: There were some great software packages available from companies such as Hyperion, PeopleSoft, SAP, and Oracle, but these packages typically required vast amounts of hardware. Additionally, client-side requirements in terms of processor speed and storage continued to rise, yet client-side storage was still expensive. Customers often had to upgrade their user’s workstations to support the new software, which was often impractical and very expensive software contracts were very restrictive, often locking in expensive support costs for long periods of time. Additionally, because the software was expensive, both in terms of the licenses and the hardware required to support it, many smaller companies simply couldn’t afford to take advantage of improved software packages. The internet, and even more importantly network speed, continued to gain ground. It was now possible to render data and a rich user experience strictly over the internet
• #3: There are several advantages to SaaS. Some of them include: SaaS means less hardware is needed, both from a back end or server perspective as well as a client or end user perspective SaaS also means there is little or no software for organizations to maintain and upgrade From a licensing perspective, SaaS is sold via a subscription, which is typically three years in length, and that subscription contains all software costs, including Support. This makes it easier for companies to predict their software costs and gives them a regular opportunity to renegotiate their subscription or consider other providers. SaaS is scalable as there are no real client-side requirements and the provider is hosting the application. New features can be accessed quicker, and the application can support more users at a moment’s notice vs. having to roll out client-side software and possibly increase server capacity.
• #4: For updates, in SaaS, the provider is doing all the upgrading and patching vs. the customer having to perform this function, and new functionality becomes available almost instantly vs. the customer having to perform an often expensive upgrade. Accessibility is improved because SaaS does not have client-side requirements, thus the application can be accessed from a variety of devices at any time, such as a mobile phone or a tablet. Customers implementing SaaS tend to go live sooner than on-premise because many of the usual phases of a typical software implementation are reduced under SaaS. For example, customers don’t have to wait for procured hardware to arrive, and since the functionality is more or less fixed, design times are reduced. And finally, because no or very little extra hardware is needed to support the SaaS implementation, overall operational costs are lower.
• #5: SaaS also carries with it a set of implications. Because the application is hosted, the customer is relying 100% on the vendor to provide access to the application at any time. The vendor takes all the risk from a security perspective, both in terms of access to the application and the data housed on the vendor’s servers. Some customers have difficulty not having full control over their application and their data.   The customer is also relying on the vendor to provide functionality that the customer wants and needs for their business. In on-premise, and we’ll cover this more later, customers have a high ability to customize the software to their liking, so if out of the box, the software doesn’t meet the customer’s business requirements, they can add or change functionality as needed. In SaaS, customization is almost non-existent, so the customer has to be willing to accept the delivered functionality. Additionally, the vendor can choose to add, modify, or even remove functionality in future releases, which can have a material impact on the customer’s business.   Now, here’s Rob Gover to tell you about SaaS architecture and Oracle’s release cadence:
• #6: TRANSITION and WHY IMPORTANT: Now that you know about the data regions and the architecture within Oracle Clouds, let’s talk about the Releases Cadences for our SaaS Applications. Understanding our Release Cadences and how to request and plan for the appropriate patching is CRITICAL for Customers’ Success in SaaS. Not only is it important to get things fixed closer to the timing that you need it, but the patching cadence may also impact a customer’s availability to do things like refreshes (because environments may be out of synch for periods of time) NO MORE ANNUAL UPGRADES: Gone are the days of annual upgrades with significant functionality changes pushed out to users all at once. Instead, Oracle SaaS applications now employ Quarterly, Monthly, and Emergency One-Off Updates. Quarterly Updates are the norm for most of our customers. In fact, many of our SaaS applications require Quarterly Updates at a minimum. Quarterly Release methodology allows customers to make more frequent, smaller changes to the application over time. What’s more, All SaaS applications now follow consistent naming conventions and release timing – so no matter if you are the Administrator for HCM Cloud, CPQ Cloud, Service Cloud, or Marketing Cloud, all the releases are available within the same timeframe and using the consistent naming and development methodology. Quarterly Updates contain both New Product Features and Code Fixes, while both Monthly and Emergency or EOO updates only contain Bug fixes – no new features. EOO patching is reserved for 24x7 Sev 1 Bugs that do not have viable workarounds and requires a request for Executive Approval. DIFFERENT PROCESSES/PILLAR Each SaaS Application may differ slightly in its processes and Policies around which updates are required and which are optional. However, each SaaS pillar is consistent in the release cadences that are available and the naming conventions for those releases.
• #7: A strong relationship between the customer and Oracle is imperative. Understanding how to navigate the various groups responsible for SaaS applications is crucial to a customers success. The various groups can help customers understand their roles and responsibilities and answer any questions they might have. Application Sales owns the overall commercial relationship with the customer and many other groups work together to support Sales. ASRs are responsible for the initial sale as well as any changes or expansions within the term of the license subscription. The sales group is key in presenting new features and functionality that may be of interest to the customer and driving overall strategy. A good relationship between Sales and the customer will drive a successful renewal of the account. Global Product Support is responsible for 24/7 technical support for the application (Product). Support maintains the knowledgebase whereby customers can self serve or choose to submit product service requests for break/fix issues. They work as the liaison to development/product management for enhancement requests and delivery of fixes to the applications. Cloud Hosting Operations manages a “Nerve Center” staff in a follow the sun configuration. They also have a Dedicated Security & Compliance management staff that is responsible for monitoring and governance. CHO is responsible for network administration which includes oversight for the servers, switches, firewalls, and load balancers in support of a stable environment. CHO drives the implementation of service architecture, service life-cycle management and works closely with product development to promote stability in the infrastructure. Product Development is the backbone of the core applications. They are experts in the design, delivery and overall maintenance of our various SaaS applications. Product Development is responsible for each individual product roadmap and new feature delivery through updates and upgrades. They are also responsible for defect remediation and the delivery of maintenance packs. Customers also have specific responsibilities in order to ensure their implementation is running smoothly. Customers have the flexibility to choose from a number of configuration options in order to modify their application to meet their business requirements. They can choose to work in-house on changes or partner with a third party in order to align their business processes with their functionality. Oracle products are constantly changing and the customer is responsible for being ready for the new releases. They will be notified in advance of any changes to their environments, and the customer needs to prepare for them. They may need to modify configurations or consume training prior to the update. Ownership and ongoing maintenance is vital to success for the customer. Another customer responsibility throughout the Oracle SaaS ownership is keeping up with end-user training. Ensuring that their employees understand how to use their Oracle product will lead to seamless operations. Oracle provides many pathways to training and ongoing education for end users and administrators to keep pace with Oracle Cloud applications. Staying ahead of the curve is important for our customers. Whether the customer is looking to define a change-management process to discover new functionalities or create a communication plan to keep users informed, customers are accountable for continuous process improvements. Customers are also responsible for a data retention policy and execution. Understanding what data needs, how they are using it and what they plan to do with it long term is key.
• #8: Each organization has its own, often unique, business processes. These processes differentiate one organization from other businesses. Customizations are designed to modify the core functionality and usually require code level changes. Customizations lead to more maintenance and higher risk. Stepping into a SaaS model, particularly with the on premise mind-set, there may be a temptation to believe that you can change core application to accommodate such unique processes. Customizations of the core product in SaaS model are not possible. However, it does not mean that SaaS applications are limited to their out of the box offering. SaaS applications offer a wide range of out of the box features and functionalities - some may have to be CONFIGURED to meet business requirements or to achieve a desired application behavior.  
• #9: Configurations are easily achievable in the SaaS space. Configurations are modified via a predefined set of parameters which are available in the user interface. Configurations are intended to be simple and smooth to implement and are often performed by non-technical type resources. What comes 'out of the box', the core functionality, cannot be changed or customized. It can be extended or integrated with third party systems. The core product is a closed environment that is 100% owned and maintained by Oracle. The technology of the core products is not exposed externally therefore the actual term customization is often used to refer to Frameworks and APIs. Extensibility frameworks will differ in their scope between SaaS applications. But they all serve the same purpose - to accommodate a business requirement, that cannot be implemented through configuration, but with no need to alter the core product. Extensibility has many different forms - it can be a web service, such as REST or SOAP, a scripting framework that allows creation of widgets, plugins or back-end processing or even something as simple as flat file transfers. Extensibility frameworks can be used by a single organization to implement their own unique requirements or by third parties to develop modules or components intended for a wider market reach.
• #10: It’s important to note that SaaS implementations carry many of the same complexities as on-premise implementations. Just because the application is hosted does not mean that many of the standard implementation questions do not need to be answered: How should the application be set up? How will data get in and out of the application? How and what reports will be run? Are custom reports needed? How will users react to the new system? How will they perform their jobs in the future? How will the system be administered? How will more functionality be enabled? How will the system be supported, both functionally and technically?   All of these questions, and more, need to be answered for both SaaS implementations and on-premise implementations.
• #11: Through acquisition and in-house development, Oracle has a complete suite of SaaS applications for businesses of all shapes and sizes. Applications can generally be grouped into back-office, such as HCM, ERP, and SCM, or front office, such as Service Cloud, CRM, and Marketing Cloud. Oracle’s SaaS focus is currently on ERP. In the most recent quarter, ERP accounted for 38% of all sales. Oracle is the acknowledged leader in the SaaS ERP space with only Workday offering a marginally competitive product.