Notes on packaged applications (including SaaS)
1. The rise of SAP (and later Siebel Systems) was greatly helped by Anderson Consulting, even before it was split off from the accounting firm and renamed as Accenture. My main contact in that group was Rob Kelley, but it’s possible that Brian Sommer was even more central to the industry-watching part of the operation. Brian is still around, and he just leveled a blast at the ERP* industry, which I encourage you to read. I agree with most of it.
*Enterprise Resource Planning
Brian’s argument, as I interpret it, boils down mainly to two points:
- Big ERP companies selling big ERP systems are pathetically slow at adding new functionality. He’s right. My favorite example is the multi-decade slog to integrate useful analytics into operational apps.
- The world of “Big Data” is fundamentally antithetical to the design of current-generation ERP systems. I think he’s right in that as well.
I’d add that SaaS (Software As A Service)/on-premises tensions aren’t helping incumbent vendors either.
But no article addresses all the subjects it ideally should, and I’d like to call out two omissions. First, what Brian said is in many cases applicable just to large and/or internet-first companies. Plenty of smaller, more traditional businesses could get by just fine with no more functionality than is in “Big ERP” today, if we stipulate that it should be:
- Delivered via SaaS.
- Much easier to adopt and use.
Second, even within the huge enterprise/huge app vendor world, it’s not entirely clear how integrated ERP supposedly is or isn’t with CRM (Customer Relationship Management). And a lot of what Brian talks about fits pretty cleanly into the CRM bucket.
2. In any case, there are many application areas that — again assuming that we’re in the large enterprise or large internet company world — fit well neither with classical ERP nor with its CRM sibling. For starters, investigative analytics doesn’t fit well into packaged application suites, for a myriad of reasons, the most basic of which are:
- The whole point of investigative analytics is to discover things that are new. Therefore, business processes are inherently unpredictable.
- So are data inputs.
If somebody does claim to be selling an app in investigative analytics, it is usually really an analytic application subsystem or else something very disconnected from other apps. Indeed, in almost all cases it’s both.
3. When it comes to customer-facing websites, I stand by my arguments three years ago in the post just linked above, which boil down to:
- What I just said above about investigative analytics, plus the observation that …
- … websites have a strong creative aspect that fits badly with soup-to-nuts packaged applications.
Also, complex websites are likely to rely on dynamic schemas, and packaged apps have trouble adapting to those.
4. This is actually an example of a more general point — packaged or SaaS apps generally assume rather fixed schemas. (The weasel word “rather” is included to allow for customization-through-configuration, but I think the overall point holds.) Indeed, database design is commonly the essence of packaged app technology.
5. However, those schemas do not have to be relational. It would be inaccurate to say that packaged apps always assume tabular data, because of examples such as:
- SAP has built on top of quasi-objects for a long time, although the underpinnings are technically relational.
- There are some cases of building entirely on an object-oriented or hierarchical data model, especially in health care.
- Business has some inherent hierarchies that get reflected in data structures, e.g. in bills of materials or organization charts.
But even non-tabular data structures are, in the minds of app developers, usually assumed to have fixed schemas.
Related links
- The refactoring of everything (July, 2013)
- Schema issues for complex websites (October, 2011)
- Workday’s architecture (June, 2012)
Comments
8 Responses to “Notes on packaged applications (including SaaS)”
Leave a Reply
Maybe we can “break on through” (to the other side) of next gen packaged apps with schema-agnostic indexing?
Picture http://cliveboulton.com/post/127606958028/schema-agnostic-indexing-with-dharma-shukla-see
Paper
http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf
Hi Clive,
I think that addresses approximately zero of the concerns I was raising. Applications assume a certain schema. If there’s an easy way to add data outside of (the portion of) the schema that the apps use, great. You can ad-hoc query it. You can write other apps against it. But the first app won’t know how to use the additional data, unless there’s some kind of app design cleverness that has been rarely seen to date.
Hi Curt,
On cleverness rarely seen to date; Michael Rys pointed me to data guides. http://ilpubs.stanford.edu:8090/232/
Aut viam inveniam aut faciam!
My core point in this part of the discussion is that when an application is developed, it assumes a certain schema, and if the schema later is altered, the app has great difficulties taking advantage of any changes.
If new apps or humans making ad-hoc queries can benefit from the changes, great. But the old apps probably won’t.
New metadata-driven apps have cracked schema plus versioned schema add-ons and removals. Acumatica ERP for example.
My old employer sponsored masters students, PhD. Postdoc worked from the database up to figure a path to transition on-prem to SaaS. But through in the towel (old apps appear to be marooned).
The real reason ERPs are so hard to adapt is because they do complicated things, not because they run on premise, or because they run on a relational database. Application logic is the real complexity.
The tradeoff between flexibility and ease of use (or manageability) is nothing new, and shifts in the underlying platform are basically irrelevant to it.
I think the market is creeping forward at a snail’s pace towards a resolution of the trade-off problem, but the syllogism “Google is simple ergo everything is simple in the Cloud, ergo Cloud based ERP is simple” doesn’t impress me much.
In a final note, it is true that employment in manufacturing is falling, but that’s only because the manual labor part is disappearing, not because manufacturing itself is disappearing.
In fact, the processes are getting more and more complex, the number of products and markets is growing, and optimization options are popping up all over the place, so the ERPs are getting more and more complex, not simpler.
This discussion reminds me the need of schema intelligence – the tool which will enable to understand, in effective way – what schema we have, when it changes, what is common denominator etc. Without precise knowledge about schema evolution even human with good ad-hoc query tools is limited in his capability to analyze data.
@david on that schema intelligence – the tool see: http://www.computer.org/csdl/trans/tk/2014/06/06378371-abs.html
Sic Salesforce’s nextgen is SQL-on-NoSQL (schema on low-schema HBase) unlike today’s Force.com SQL-on-SQL Oracle). http://phoenix.apache.org/
Same at Microsoft, SQL-on-NoSQL (.Net 4.5.2 on Azure Data Lake).
“cleverness rarely seen to date”–schema intelligence tool for nextgen apps are hiding in plain site.