October 7, 2015

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:

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:

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:

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:

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:

But even non-tabular data structures are, in the minds of app developers, usually assumed to have fixed schemas.

Related links


8 Responses to “Notes on packaged applications (including SaaS)”

  1. clive boulton on October 7th, 2015 8:52 pm

    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


  2. Curt Monash on October 7th, 2015 10:25 pm

    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.

  3. clive boulton on October 7th, 2015 11:51 pm

    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!

  4. Curt Monash on October 8th, 2015 2:00 am

    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.

  5. clive boulton on October 8th, 2015 4:43 am

    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).

  6. Barney Finucane on October 8th, 2015 5:45 pm

    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.

  7. David Gruzman on October 9th, 2015 4:08 am

    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.

  8. clive boulton on October 9th, 2015 1:35 pm

    @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.

Leave a Reply

Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:


Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.