Merging Local Data Acquisition with SaaS
Generally speaking, I’m opposed to introducing different terms to describe the same thing. In the SaaS space, Microsoft has taken the position of using “Software + Services” rather than “software as a service.” To some degree, there is a level of correctness captured in “Software + Services” that you don’t find in SaaS, particularly when taken in the context of this post.
Traditional SaaS examples generally follow a theme where end users access their application online, produce data online, and then consume artifacts of that produced data online. Take using Salesforce.com, for example. Individuals save leads, contacts, etc. only to come back and use data they or others in their organization have added. What if a business domain relies heavily on or could experience huge value from exploiting geographically bound data? Software for the food industry could exploit this. Being able to near real time monitor things like refrigerator temperatures at a warehouse or refrigerated truck temperatures can reduce spoilage and lost revenue, reduce liability burdens, and even save energy. SaaS, at least in most people’s current conceptual model, doesn’t account for local data because of SaaS’ relatively centralized nature. Microsoft’s “Software + Services” approach is a touch closer to what I’d like to see. Local software agents essentially make up the on-premise software side of the equation, where the agents might be connected to things like temperature monitoring hardware. That data is coordinated and reported back to the food warehouse management SaaS offering, which can correlate the data to a tenant’s standard data model. This gives a tenant a local and deep view of their operations as related to the business function managed by the SaaS offering.
(bigger)
This concept is not revolutionary and I’ve seen it done, but I think it should be part of standard SaaS conversation. I rarely hear discussions pop up regarding how to exploit customer premise data. It allows for situations like a food distributor recognizing drastic temperature changes in a refrigerated truck while enroute to a customer, or other situations like temperature fluctuations due to an overstocked freezer at a warehouse, and merge that with the inventory control functions of the SaaS offering. Decisions like “move the following stock from freezer A to B” are possible while maintaining most of the SaaS benefits. We live in a connected world, so what can SaaS do to exploit this connectivity? The creative boost that comes from local data acquisition is immense and shouldn’t be discounted.
What role do you think (if any) blurring the line between SaaS function and locally acquired data will play in the short term? The long term? Are security implications too grand to achieve success in this sort of play?
(2 votes, average: 4.5 out of 5)
Loading ...
What you describe is in my understanding the fact that SOA and SaaS are finally moving closer and closer.
Front-end, Back-end, Data’s should be all decoupled in future SaaS offerings.
I think we are already there in a certain way.
The apparition of SaaS platforms is already a sign. It is front-end aggregation of Data’s from different points.
Back-end integrations are coming too.
In the short term I think we will see a lot more integration coming in but in a chaotic way.
What I would hope for the future is that a certain standardization of Data format will appear or that we will see an extension of Data Portability projects.