CIOs at large and small organizations have embraced the trend of moving their application portfolios to the cloud, many with stated “cloud first” and “SaaS first” principles. Keeping pace with this demand, Software as a Service (SaaS) vendor offerings also continue to mature at an exceptional rate.
Corporate users are increasingly aware of vendor offerings in their business verticals. In many cases, vendors are reaching out directly to business users and “selling” their SaaS offerings; which is not necessarily a bad thing. More power to users!
In my role of an Enterprise Architect for a multinational, I routinely engage with corporate stakeholders to evaluate new solutions, and generally come away impressed with the maturity of their SaaS offerings. Many times, however, these evaluation sessions turn out to be knowledge sharing exercises where I end up having to educate and guide business sponsors and users, and even SaaS vendors on aspects of our corporate ecosystem.
Business stakeholders are often surprised to learn that even “service on the cloud” need additional design and integration before they can be seamlessly used in our corporate setting. An analogy is perhaps that of water or electric utility providing service to a large manufacturing plant. The utility provides the “service” for the electric wires with power to come coming up-to the plant. The plant’s Engineers and electricians need to draw a blueprint, design for the conduits, wires, switches etc down to individual rooms, workstations and equipment. Only after that can the users flick a switch.
Drawing from the same analogy, if we think of the SaaS as yet another “utility,” providing a new service at the manufacturing plant, one still needs the internal architecture and design - wiring and conduits - to ensure that the proposed SaaS platforms co-exist, and operate seamlessly with other capabilities that business users expect from the organization. The themes that seem to recur in SaaS conversations include:
#1. Configurations and customizations can add to cost and complexity
Bottomline: Corporate users need to be aware of incremental hidden costs!
================================
Repost from my LinkedIn Pulse post
Corporate users are increasingly aware of vendor offerings in their business verticals. In many cases, vendors are reaching out directly to business users and “selling” their SaaS offerings; which is not necessarily a bad thing. More power to users!
In my role of an Enterprise Architect for a multinational, I routinely engage with corporate stakeholders to evaluate new solutions, and generally come away impressed with the maturity of their SaaS offerings. Many times, however, these evaluation sessions turn out to be knowledge sharing exercises where I end up having to educate and guide business sponsors and users, and even SaaS vendors on aspects of our corporate ecosystem.
Business stakeholders are often surprised to learn that even “service on the cloud” need additional design and integration before they can be seamlessly used in our corporate setting. An analogy is perhaps that of water or electric utility providing service to a large manufacturing plant. The utility provides the “service” for the electric wires with power to come coming up-to the plant. The plant’s Engineers and electricians need to draw a blueprint, design for the conduits, wires, switches etc down to individual rooms, workstations and equipment. Only after that can the users flick a switch.
Drawing from the same analogy, if we think of the SaaS as yet another “utility,” providing a new service at the manufacturing plant, one still needs the internal architecture and design - wiring and conduits - to ensure that the proposed SaaS platforms co-exist, and operate seamlessly with other capabilities that business users expect from the organization. The themes that seem to recur in SaaS conversations include:
#1. Configurations and customizations can add to cost and complexity
- SaaS solutions are like a Swiss army knife - designed for many scenarios, but require to be configured before they can work for complex and global business functions. In the analogy, the utility company might supply an agreed “standard” - units of Volts and Watts - that will need to be transformed for specific needs and machines in the plant.
- Most SaaS solutions support configurations; like changes to UI templates, basic workflows, role based authorization and authentication etc. However, even seemingly small configurations done together might cascade into a considerable piece of work.
- SaaS platforms for complex business needs – like CRM, Financial Services, Supply Chains, HR, Talent Management, Legal matter management, Contract Management etc. - rarely work out-of-the-box (OOTB), especially given the requirements for larger companies with hundreds of users spread across geographies.
- Configurations need to be done by product experts with the right functional and technical skills, and knowledge of corporate ecosystem. (In our analogy, one would need an electrician - not a plumber or carpenter – with the plant’s wiring diagram to do the wiring.)
- The technical and functional skills required to configure SaaS solution may need to be sourced at a premium. Just try searching for “workday consultant” or “salesforce project manager” on LinkedIn jobs section and see the number of hits. Technology consulting firms have sensed an opportunity, and developed entire practice areas with armies of consultants focused on specific SaaS solution.
#2. Synchronizing upgrade calendars
- SaaS solutions continually undergo change as vendors enhance capabilities and offerings. Such changes are generally kept transparent to end users, which is really attractive to IS executives.
- Vendors try to manage most of the changes to SaaS solutions “behind the scenes” but some changes may need end-user communication - for instance, they may need to be informed that on Monday morning the screens may look and feel a bit different after the weekend’s software upgrade! (in the utility analogy, the electric utility might notify the plant manager if a transformer is being upgraded in their neighborhood; and the plant supervisor will plan tests with machines prior to the following shift.)
- SaaS solutions that integrate with other corporate applications will need to be tested after major upgrades. This is typically done as User Acceptance Tests (UATs). Before planning such upgrades, the organizations’ IS team will also verify upgrade calendars. The calendars also track business seasonality, peak sales periods, financial account closing etc. System changes and upgrades are generally “frozen” and disallowed during such periods. Such business driven calendars need to be orchestrated with the SaaS vendor’s upgrade calendars.
- Back to our analogy, the manufacturing plant might subscribe to several utilities – power, water and sewage, network phone etc. In the same way, organizations continue to consume SaaS services for critical functions - e.g hypothetical MyCorp in Figure-1. The challenge in tracking upgrade calendars of all service providers, synchronized with internal calendar is not a trivial one.
( Figure-1: MyCorp integrating SaaS)
#3. Don’t underestimate integration complexity
- Technology solutions designed to enable complex business functions will require corporate data from different sources before they can provide consistent and meaningful results to business users.
- SaaS services for such functions will also require such corporate data and information from the “backend” corporate platforms. Depending on the existing technology landscape, such interfaces and integrations may not be trivial or cheap to implement.
- The promise of Service oriented Architectures (SOA), when done right should help mitigate the impact of ongoing changes, but will still require testing and validations. [Point #2 above]
#4. Do not underestimate the need for a “service” to manage the SaaS service
- Corporate technology consumers and users are promised a certain service level to ensure their productivity. The manager at the manufacturing plant expects his lights to turn on, his phones to work and perhaps also coffee in the break-room. All these utility “services” are orchestrated and managed with well-defined service levels (SLAs/OLAs). Likewise, organizations design internal help-desk and support organizations to provide consistent “service” and user experience. If there issues with the power or phone, the plant worker knows to call the corporate help desk and not the utility directly.
- A SaaS solution introduced in a corporate environment will require a service “wrapper,” for example designed into the existing help-desk to make the support experience seamless.
- Service management is generally not free. SaaS Service providers offer corporate users a variety of service levels that sound like frequent flyer program’s tiers - Bronze/Silver/Gold, Standard/Enhanced/Premium etc. The tier come at increasing cost with distinct implications on service levels, support hours and terms, which may not be obvious at the outset. A business group signing up for “Bronze” service might think of “Support hours: 8 hrs/ day” as reasonable, not realizing that the “service” will be required to support colleagues across three-four time-zones in the US alone, not to mention Europe and Asia! (ref example in the chart below)
(Figure 2: Illustrative SaaS Support model)
#5. Watchout for the TCO
- At the outset, SaaS service and licensing costs may seem inexpensive. There is perhaps a grain of truth to it, since SaaS offerings are cheaper and perhaps faster to deploy than solutions developed by in-house teams. However, the business stakeholders sold on the promise of no-touch deployments and “light” service models need to be informed and educated of the total cost of the solution deployed – this may include configurations, customizations, integration, integrating service model etc.
Bottomline: Corporate users need to be aware of incremental hidden costs!
================================
Repost from my LinkedIn Pulse post
