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)