This past Wednesday (May 16) NetSuite CEO Zach Nelson responded to a Phil Wainewright blog on Appirio’s completely on-demand business infrastructure. His comments highlighted a myopic, Netsuite-centric view of the universe:
“How much would it cost to do what you described, and how much does it cost to maintain it, what sort of resource do you need on staff to address re-programming when you want to exchange different data than was originally envisioned, or when one of the 10 vendors decides to change their API?”
Despite his clear self-interest and agenda to promote NetSuite, the questions above have merit. In fact, we ask these questions, and many others, when helping clients incorporate broader SaaS adoption into their organizations. Our Services 2.0 piece describes our view of how systems integrators will work differently with clients in the Internet-enabled SaaS era.
The integration among SaaS solutions described in Phil’s initial blog could be built by an integrator for a specific customer, or provided as an “integration as a service” offering to the market, by Appirio or another third party. We take a similar neutral approach in evaluating “best of breed” vs. “suite” arguments. Factors favoring one over the other include capabilities and scope of the solutions involved, business needs of the client, complexity of integration (which drives total cost of ownership, or TCO), and the characteristics of the consuming organization such as size, industry, and structure.
Yet the questions Nelson raises, when combined with the NetSuite agenda, reveal a poor understanding of enterprise level needs – and highlight precisely how SaaS vendors should not look at integration. There are two primary flaws in Nelson’s thinking.
1.The Enterprise Flaw
As Phil’s initial blog described, we at Appirio “eat our own dogfood” to make sure we can relate to the issues faced by our target customers – medium and large enterprises. For these organizations, integration is a must. No single solution covers the scope of their needs. Any non-trivial enterprise has dozens of existing systems that aren’t going away anytime soon. Even NetSuite is missing many functional capabilities like extended HR (e.g. recruiting, and performance management), materials management, supply chain, and a host of others. Last we checked, they offered APIs to their system to address these types of shortcomings.
Undoubtedly, an integrated suite offers great benefit; however, a more specific solution that can be easily plugged into an environment – offering strong integration – also has broad appeal. For enterprises, “No Software” is not an end state, but a process and a path. The ability to smooth the path, one application or module at a time, is compelling for organizations reluctant to undertake big-bang simultaneous change to all systems.
Bottom line, whether you are discussing a suite or individual applications, strong integration capabilities are a must for SaaS solutions in the enterprise.
2. APIs and Integration in the Internet and SaaS Era
API change is a common problem that makes upgrades expensive in the on-premise software world. Integrated solutions must all adjust when APIs upgrade and lose backward compatibility. That’s the logic that drives Nelson’s comment, “what if a vendor decides to change their API.” Yet, the SaaS world should be different. For example, salesforce.com has retained backward compatibility through each of their 9 API versions. One hopes NetSuite and other serious SaaS vendors do the same.
By offering a single instance multi-tenant solution, vendors benefit from managing the API stack in a single environment. Customers benefit too, because future API versions are always supersets of earlier incarnations. Therefore incremental effort to adjust to new APIs between well-architected SaaS solutions focus on adding new capabilities, not keeping the existing ones from breaking. Can you imagine how many mashups would break if Google simply decided to change the Google Maps API without backward compatibility? Good Internet and SaaS solutions are engineered differently. Instead, Google adds to their API without breaking everyone already relying on it today. In the SaaS world, API clients often specify the API version they are written against, to ensure backward compatibility for each call. This is one example of how SaaS implicitly increases vendor accountability – since customers have no choice but to upgrade, vendors have no choice but to aggressively maintain backward compatibility.
Nelson makes a good point regarding addition of incremental functionality. If, Google offers new capabilities tomorrow – say, the ability to get real-time data on current pollution levels for a location, existing integrated solutions would have to change to take advantage of it. The costs and benefits of adding that capability would be independently evaluated. In Nelson’s world, NetSuite would own the maps capability, and simultaneously update both the maps and everything that relied on the maps, eliminating the need to maintain the integration.
We choose this example deliberately, to be provocative. We certainly hope that NetSuite doesn’t try to take over Google Maps. Is integrating Financials to HR an example of the same principle? The answer is, it depends. Every company will have to consider many factors in order to evaluate suite vs. integrated solutions in the on-demand era.
Suites can certainly provide great value as solutions in the SaaS era, but their scope of applicability (customer complexity) and path to value cannot simply mimic that of legacy on-premise predecessors. On-premise suites offered poor external integration to force customers into either/or choices. The Internet and SaaS suites or solutions cannot and should not seek to mimic that approach.
Fleshing out the suite vs. best-of-breed debate is a topic for a future blog. The bottom line here is that integration in the SaaS era cannot be evaluated or thought of using the on-premise paradigms of the past.