Getting Ahead of the SaaS Sprawl Curve
The promise of platforms– one solution to do everything within a business unit– really fell short in many ways. However, that doesn’t mean platforms shouldn’t be employed nor does it mean we should allow SaaS point solutions to sprawl out of control. Rather, the goal should be to design a SaaS ecosystem which is both stable and accommodating of change. This is achieved with a planet-and-satellites design pattern.
SaaS Vendor Promises
In the high-stakes tournament to win your SaaS budget, some companies take the approach of differentiation. These firms tout their best-in-breed solutions are the way to go because they provide highly specialized functionality aimed at solving specific problems. Example product companies are Greenhouse for applicant tracking, Anaplan for FP&A, or Sprinklr for marketing. Such tools go by many names: the point solution, the one-trick pony, and of course best-of-breed.
Then we have the platform players: the Oracle and Salesforce players of the world who promise a one-vendor-solution to all your problems. Examples include SAP’s ERP stack, Saleforce’s Marketing Cloud, and ServiceNow’s ESM platform.
The reality is that both worlds– platforms or point solutions– represent extremes. While any enterprise can live on either end of the spectrum, it’s best to devise a strategy that balances these two approaches into a cohesive technology ecosystem.
Stages of SaaS Maturity
Many companies begin their life cycle with a handful of mission-critical systems. Then, various departments procure additional apps to meet specific needs. A point solution for this, an app for that.
Within a relatively short span of time, SaaS application sprawl becomes a very real problem for multiple reasons. First, multiple applications with similar functionality confuse end users. Should they use Skype or Slack? Box or OneDrive?
Then there’s the issue of cost, which effectively amounts to paying for many different solutions. Security is also a concern as with each solution we spin up, a copy of our corporate data gets a new home. Finally, we start to see shadow IT functions start to emerge; groups that offer cross-functional services to other groups. For example, a marketing analytics team offering data integration services to finance. Or perhaps HR offering authentication services from the HRIS cloud.
At some point, the pain becomes unbearable, and a formal IT department is established. Assessments are made, some systems are consolidated, and centralized services are initiated to serve cross-functional needs.
The final stage of SaaS evolution is the ongoing care and feeding of planets and satellites. That is, keeping the lights on for core platforms, and managing the perpetual flux of smaller “bolt-on” (satellite) systems which inevitably come and go.
Planets and Satellites, Explained
Platforms are analogous to planets. They have gravity to them, they’re stable, and they are long-lived. The platform (or “planet”) is a cornerstone system, meaning it becomes the source of truth for key business objects such as employees, inventory, or financials. It provides a stable foundation you can plumb data in and out of, authenticate to, and generally govern with maturity.
Satellites, on the other hand, are systems that bolt-on or “orbit” around your platforms. A common example would be adding Greenhouse to Workday. Greenhouse may provide managers with a delightful recruiting user experience, but in a year or two, such a solution may be replaced; perhaps with something like Lever or Workable; who knows! The point here is that you don’t want to reshuffle your entire HRIS stack (and associated data flows) for a change in recruiting tooling. With satellites, downstream systems which consume (and possibly alter) employee records are none-the-wiser that an applicant tracking system was replaced as they’re still connecting to the planet– Workday.
Balancing Platforms and Point Solutions
Moving from point solutions to a platform isn’t necessarily easy. One must create a sunset plan for point solutions and embark on a business process reengineering journey to fit the platform view of the world. When moving to a platform, it’s wise to use as much of the default functionality as possible, and customize only when there’s demonstrable value in doing so. I’ve seen several ERP and CRM platform deployments fail, primarily because they were over-customized.
Once platforms are fully utilized, there will certainly be a shortcoming here and there. Perhaps the mobile experience for approving purchase orders in Oracle is lacking, or checking on applicant status in Workday is cumbersome for new managers. Point solutions (satelites) will invariably churn, and that’s ok. The idea is to keep satellite systems on the periphery, and not on the critical path of core enterprise workflows. This balances departmental decision-making autonomy with enterprise governance by allowing managers to make satellite system decisions while minimizing the impact such a change has to the world around it.
About Procurement Pragmatism
It’s true that some solutions simply don’t cut it, and need to be either replaced or augmented. However, there’s a very fine line between objective functional fit and subjective preferences. I’ve seen dozens of solutions introduced into enterprise settings, simply because the requesting manager used the solution with their former employer. Other times, managers believe that releasing shiny new tools is somehow a “quick win” that will save time, money, or add efficiency. To that, I say: “prove it.”
The real motivation behind a new SaaS solution should be quantifiable business value. If a manager cannot put together a one-page deal summary which forecasts some type of ROI, then is the new addition to the enterprise SaaS ecosystem actually warranted?
