I’ve been investigating lately the world of SaaS based WMS (warehouse management systems). This has led me smack into the whole “everyone has their own definition” conundrum. It seems that most of what I’m encountering is a marketing wrapper touting the SaaS aspects of what is really an ASP (Application Service Provider) business model.
To try to be more clear on what I mean, Brian Sommer, an associate of mine, has published as good an explanation of the SaaS marketing hype and scam as I have heard in his ZD Net blog post, SaaS-querade: When On-Premise Vendors Try to Pass as SaaS Vendors. “An on-premise vendor, seeing softness in new license sales numbers, starts to (finally) realize that Software as a Service (SaaS) is real. So, the vendor decides that a ‘hosted’ ERP application is a close enough facsimile to a SaaS solution. All the hosted product needs is a bit of SaaS marketing and it’s a done deal. Right? Wrong!”. This style of solution is really more of an ASP. The solution is still the vendor’s on-premise solution running as a single instance in its own real, or virtual, server environment, just not in the customer’s data center.
Despite this masking of reality by many vendors, one issue has continued to bother me about a true, fully in the cloud, fully multi-tenant, SaaS solution. What about business environments where very high speed decisions with very high speed communication between systems are required. The interaction between automation control systems and warehouse house management systems like automated material handling equipment is a perfect example (high speed conveyors, sorters, tilt trays, AGVs, ASRs). Depending on how they are implemented, these systems require decisions in response to specific events in millisecond time frames (typically 100-200 milliseconds for bilateral communications and the decision making). It is difficult to rely on a LAN/WAN connection to a cloud based system to support such an operation. Another environment would be a high volume automatic data identification and capture environment (autoID). This type environment could have 1000’s of RFID tags moving and reporting their locations and/or events every minute of the day. Many of these transactions are meaningless/mindless duplications and passing such repetitive messages to a cloud system needlessly clogs the LAN/WAN pipe.
This is not a slam at SaaS, on-premise solutions, or the internet. It is a fact of life that there can be contention for band width. A delay in the decision making process (communicate to SaaS, get a decision, communicate back) can often cause a process failure in the warehouse. Imagine in the conveyor/sorter situation that a scanner reads the bar-code on the tote, the communication to the SaaS WMS is made asking which lane is the tote to be diverted into, the SaaS decides and communicates back. Meanwhile, the tote was moving at 600 feet/minute (not an unusual speed for a high speed sortation system), the first diversion lane is 15 ft. from the scanner, the SaaS system decided that the tote needed to go into that first lane, the full communication and decision timeframe because of bandwidth contention took 2 seconds. The result is that the tote had moved 20 feet in the two seconds and cannot be diverted into the first lane as necessary. The worst impact here is that the tote will be sent to a reject lane and then have to be moved by hand, the best is that it will be recycled back on a return loop and getting another chance to make that first lane. I know of at least one SaaS WMS that installs their own dedicated network LAN/WAN connection so that they can have control and avoid all the other possible sources for bandwidth contention.
For such environments as these, a synthesis of a SaaS based solution and a local on-premise solution is necessary. There is some expectation that HTML 5, smart clients, or faster communications links could eliminate this but until they are real and pervasive, we will continue to see a need for a local server that deals with the limited, yet intense functional requirements. I call this type of solution SaaS-Plus.
While discussing this with Brian, he pointed out that we are also seeing an On-Premise-Plus solution model. This is evolving in the large on-premise ERP world where the ERP solution is off loading from the on-premise environment to the cloud the transaction or analysis/number crunching associated with analytics, price optimizations, and scheduling. This is done to bring to bear expensive yet very high performance in memory data base computing without having such overhead resident locally where it would be cost prohibitive.
Thus our SaaS definitions are expanded to include:
SaaS – a software delivery model in which software and its associated data are hosted centrally (typically in the cloud) and are typically accessed by multiple users and organizations (multi-tenant) at many locations (multi-site) using a thin client, normally using a web browser over the Internet. The solution provided is often highly configurable while sharing a common central code base. Customizations for any one tenant are really configurations applicable only to that one client. Any solution that is a single instance of the software for a single client (tenant) or that requires on-premise computing and/or solutions is not SaaS.
SaaS-querades – Vendors that sell a software as a service (SaaS) solution that really is their on-premise product running in a hosted environment.
SaaS-Plus – a marriage of SaaS with a limited function on-premise solution is required to meet very high speed of very data intensive requirements like material handling automation control in a warehouse or a very high volume autoID collection and alerting environment
On-Premise-Plus – a marriage of a full function on-premise solution with a limited function SaaS solution to cost effectively use high performance computing or data base power to solve calculation and data intensive business requirements like analytics, price optimization and scheduling.
Solution vendors should not be timid about identifying what type of SaaS solution they are offering. After all, high volume or high speed environments are real and relatively common as are intense computational/optimization environments. Brian writes further in his article “Purists, Pragmatists, and others re: Cloud” that SaaS solutions should really be across a distribution of SaaS types, not just purist or not at all. Describing your solution correctly and for the right reasons helps your customers have assurance that you understand and can satisfy their requirements.
