Enterprise application software — generalities
This is part of a three-post series on enterprise application software over the decades, meant to serve as background to a DBMS2 post on issues in enterprise apps.
- The first (this one) lays out very general issues in understanding and subdividing this multi-faceted sector.
- The second calls out characteristics of specific application areas.
- The third discusses application software products’ underlying technology.
1. There can actually be significant disagreement as to what is or isn’t an enterprise application. I tend to favor definitions that restrict the category to (usually) server software, which manages transactions, customer interactions, financial records and things like that. Some other definitions are even more expansive, including personal productivity software such as Microsoft Office, computer-aided engineering systems and the like.
2. Historically, application software has existed mainly to record and route information, commonly from people to machines and back. Indeed, one could say that applications are characterized by (up to) five (overlapping) aspects, which may be abbreviated as:
- Database design.
- Workflow/business process.
- User interface.
- Social/collaboration.
- Analytics.
The first four of those five items fit into my “record and route information” framework.
That categorization ties into a number of my previous posts. In particular:
- Last August I reviewed some important examples of application databases. That post also links back to several things I wrote about enterprise application history.
- In February, 2013 I reviewed some difficulties around analytic applications.
- In September, 2011 I wrote (over-)optimistically about the integration of social technology into enterprise applications.
- Back in 2006 I laid out a kind of data/UI/business process trichotomy.
3. Application software can live either in suites or as point solutions. Reasons for the suite choice can include:
- Vendors like to sell more to any given customer.
- Customer like to deal with fewer vendors, and hence to buy more from any given vendor.
- There are many real reasons to integrate applications at the database and/or workflow levels.
- There are training and usability advantages when applications have a common user interface.
4. Acquiring application software is usually a big deal, especially in the case of suites. After all, the main point of getting application software is to change the way you do business. Indeed, the cost of application software commonly includes:
- Costs for software license/maintenance/whatever.
- Costs for underlying technology (hardware/data center/whatever).
- Costs for (re)training your employees to use the software.
- IT personnel costs.
Choosing SaaS (Software as a Service) delivery can obviate some of these issues — but only some.
Sometimes the previous paragraph is actually a great understatement; adopting software can involve major changes in how you run your business, well beyond what can be covered by a bit of employee education about new software features. To pick a couple of historical, generic examples:
- Before MRP* software, manufacturers commonly didn’t have business processes to track every part they used. They literally had to put parts behind locked doors and so on to use the application software.
- Business process reengineering (BPR) was a major trend of the 1990s.
The difficulty of adoption leads not just to high costs, but also to long projects and high project failure risk as well.
*MRP = Materials Requirement Planning. MRP II = Manufacturing Resource Planning.
5. With the software itself often being only a small part of the pie, there’s naturally a lot of interest among vendors in capturing other revenue as well. For starters I’d say:
- Semi-custom software for large enterprises, bundling packaged applications with a lot of professional services, is a great idea that succeeds surprisingly rarely.
- Oracle, SAP, and Microsoft all want to sell you DBMS and other “platform” software to run their applications. Oracle wants to sell hardware too. And they all also want to sell you BI.
- Smaller enterprises are commonly served by VARs (Value-Added Resellers) that sell complete systems, including application software (proprietary or relicensed), hardware and so on. If the software is proprietary, it’s commonly built on a rich stack. Providing that stack is the traditional main business for Progress and Intersystems. It’s also a secondary business for most of the large-enterprise-focused vendors, and perhaps a primary business for Microsoft.
- SaaS vendors of course want to sell you a bundled remote service.
Comments
6 Responses to “Enterprise application software — generalities”
Leave a Reply
[…] The first lays out very general issues in understanding and subdividing this multi-faceted sector. […]
[…] The first lays out very general issues in understanding and subdividing this multi-faceted sector. […]
[…] with this post, I’m putting up a three post series on the history of enterprise apps. Takeaways include but are not limited […]
[…] A significant fraction of my posts, in this blog and Software Memories alike, are probably at least somewhat relevant to this sweeping discussion. Particularly germane is my 2012 overview of Oracle’s evolution. Other posts to call out are my recent piece on transitioning to the cloud, and my series on enterprise application history. […]
[…] One of those (the same month) briefly surveyed actual choices in technology support for enterprise apps. […]
[…] This also all fits with the “route” part of my claim that “historically, application software has existed mainly to record and route information.” […]