skip to main |
skip to sidebar
I'm a huge fan of primary research, especially when it is paired up with great analysis. Some Enterprise Software and Solutions (#EnSW on twitter) analysts base too much of their commentary and advice on what they read in the news, see at user conferences, and hear from other analysts.Computer Economics is an #EnSW analysis firm with a difference. Frank Scavo and the folks at Computer Economics do great research - quantitative and qualitative - on the #EnSW world. If you are an IT executive, or an #EnSW vendor, you owe it to yourself and your enterprise to check out their research.The latest published research from Computer Economics is a study called "Go-Forward Strategies for Oracle Application Customers." In the spirit of full disclosure, I should mention the following, and you should bear these facts in mind as you consider my comments:- I have been in the #EnSW world for around 25 years now, including long stints in executive product roles at Oracle and SAP.
- My company, C3, may someday be competing with Oracle (and other #EnSW vendors).
- Computer Economics provided me with a copy of this $995 report at no cost for my review.
Here are some key findings from the report, followed by some of my thoughts about the results:- Finding: Dissatisfaction with the cost and benefits of support runs high across the Oracle Applications customer base, with 42% of respondents reporting dissatisfaction with the quality of Oracle support, and 58% reporting dissatisfaction with the cost of Oracle support.
- My thoughts: That is a very surprising result, showing an astonishingly high level of dissatisfaction!
- Finding: Customers generally expect Oracle to grow as a share of their IT spending, despite their level of satisfaction.
- My thoughts: There are a number of obvious reasons for this result, including vendor consolidation, customer expectations of growth in their business coming out of this continued weak economy, and the difficulty of moving from one application product set to another.
- Finding: Third party maintenance and support is attractive to a substantial fraction of Oracle Applications customers.
- My thoughts: A far smaller percentage of Oracle Applications customers are considering third party maintenance and support as compared to the fraction who are dissatisfied with support quality and price. It is not clear to me that any third party can really deliver bug fixes, patches, and legislative and regulatory updates. Nonetheless, #EnSW vendors are increasingly dependent on maintenance and support revenue, and thus they are increasingly vulnerable to customers using third parties, or going off maintenance and support entirely.
- Finding: Despite - of perhaps because of - their dissatisfaction with the current applications support, Oracle Applications customers are not planning a rapid migration to Oracle Fusion Applications, with 5% planning to migrate away from Oracle, 24% researching or planning to migrate to Fusion, and the remainder with no plans to migrate to Fusion. e-Business Suite has the largest percentage of customers considering Fusion Applications, and JD Edwards has the largest percentage of customers considering moving away from Oracle.
- My thoughts: Oracle is just beginning to roll out information about Fusion Applications, with the first big "reveal" coming at this year's Oracle Open World. Many Oracle Applications customers have only a limited understanding of the benefits and features, and limitations, of Fusion Applications. Over time, you can expect this result to change dramatically.
- Finding: The report includes information about the staff required to run various Oracle Applications products, including e-Business Suite, JD Edwards, Peoplesoft, and Siebel. JD Edwards requires the smallest number of support staff, with e-Bueinss Suite and Peoplesoft at the other end of the spectrum to operate.
- My thoughts: There is significant value in this section, and in the report recommendations, for Oracle Applications customers.
Computer Research has done the industry another mitzvah in sponsoring and executing this research and analysis project. Oracle Applications customers, and #EnSW vendors, would benefit from reading this insightful report.Links:
Gartner recently set off a new industry debate when it released its piece Measure and Manage Your IT Debt.
Vinnie Mirchandani (@dealarchitect) has a typically pointed, incisive, insightful response, called Gartner's "IT Debt" Scare (I guess you can tell from the title where this piece is going ;-) ).Both Gartner and Vinnie make excellent points, but I have a somewhat different point of view.First, Gartner was very creative to once again bring a new perspective to an emerging problem. However, there can be more than one perspective on this issue, as Vinnie's piece points out.
What is Technical Debt?
Technical debt is a term apparently coined by Ward Cunningham in 1992 to describe the shortcuts, compromises, and mistakes made in developing software. For example, many times a software project is on a deadline, and a "good" approach would take too much time or cost too much in resources, so project members take note of the problem and use a quick hack to just get by for now. The quick hack introduces costs later in the project that build up over time if the "technical debt" is not paid off. For some great overviews of technical debt, see here and here, plus the infographic here.
Technical debt is commonly used to describe architectural shortcuts made in software product development in start-ups, but can be applied as a concept (as Gartner has done) to many other related areas - for example, IT lapsed maintenance, deferred maintenance on a home or public utilities, or failure to invest in areas that give a long-term payoff.Technical debt - TO or BY the software vendors?Some technical debt has little or nothing to do with enterprise software vendors; it's the same kind of technical debt accrued by large and small software vendors where shortcuts are taken during IT projects.However, as Gartner positioned this problem (according to other reporters such as Vinnie and Larry Dignan, as I have not read Gartner's article on this topic), at least part of this debt is a debt to enterprise software vendors - forgone upgrades, or even going off maintenance. The theory is that firms will skip an upgrade from time to time (or, worse, a patch), or go off maintenance on enterprise software, creating some amount of technical debt; after all, upgrades get progressively harder to apply as more upgrades are skipped over, and going off maintenance can lead to missed security patches as well as costly "relicensing" fees in the future. One way to look at this technical debt is that it is a technical debt owed to enterprise software vendors.However, another way to look at this is as technical debt owed BY enterprise software vendors to their customers. After all, if these updates, upgrades, and patches had enough value in them, and cost little enough to apply, then the ROI (benefit/cost ratio) would be sufficient to justify keeping up with the vendor's software releases. The gap between the ROI needed and the actual ROI for each release is a form of technical debt - but its a debt owed by software vendors to their customers.There are two ways vendors can increase the ROI of these releases - by increasing the numerator (return or benefit) or decreasing the denominator (investment or cost). Simple, right? Increasing the benefit can be accomplished by planning periodic usability or functional updates that can go along with emergency fixes when needed, or by reducing the frequency of patch releases. The cost can be reduced by reducing the frequency of patch releases, creating tools that determine whether a particular release is needed by the customer, by handling the updates on the customer's behalf, by avoiding schema changes, and thoroughly testing every upgrade.SaaS versus on-premise
Any enterprise software discussion these days has to include a discussion of SaaS (or cloud) versus on-premise deployments. What does the cloud have to with this topic? SaaS-delivered applications change the economics of software in many ways, and technology debt is yet another case of this. SaaS-based applications may not automatically result in greater benefits related to new releases, but they do offer the opportunity to reduce the costs of upgrades - because most of the infrastructure upgrade costs are borne by the vendor, so SaaS vendors have developed techniques and a body of knowledge that minimizes those costs.
Often, this is not the case with on-premise software. Customers have a very diverse landscape of systems, integration points, operating system versions, and set of applied patches; as a result, it just isn't possible for vendors to sufficiently test upgrades for all these permutations. Of course, customers are also responsible for the costs and efforts of each upgrade, not benefiting from the economies of scale when many customers are on identical environments simultaneously upgraded - as in a SaaS deployment.On-premise software vendors generally do not optimize for low cost of upgrades, at least not to the same extent as SaaS vendors. By definition, on-premise software vendors cannot test every customer's upgrade with every release; in the SaaS world, such testing is standard operating procedure. These days, SaaS vendors even give customers some time to test upgrades before switching over to a new release, allowing customers time to test any custom extensions or integration points, as well as to test new features and develop new work processes to benefit from the new functionality of each release.Many times, software upgrades go along with infrastructure upgrades - the new version may not be available for a particular brand of previously-supported hardware, a previously-supported operating system, or perhaps an outdated database. When this is the case with on-premise software, the customer has to bear the cost of upgrading to new infrastructure, testing other related systems on the new infrastructure, and training employees who manage the infrastructure and the new software. These costs are, again, not borne by the customer in a SaaS environment; the SaaS vendor takes on this burden. Incidentally, this burden is lower for the vendor in the SaaS world, since only one (or two, when multiple versions of applications are supported simultaneously for customers) configuration needs to be supported and tested, and because the SaaS vendor controls the upgrade cycle to minimize costs and disruption.Do SaaS applications completely eliminate technical debt?No. But SaaS applications significantly reduce technical debt, primarily by eliminating a backlog of unapplied patches and upgrades, eliminating costly infrastructure upgrades, and eliminating the "death matrix" of supported platforms and infrastructure.
(c) Oracle Corp.
I'm a huge fan of primary research, especially when it is paired up with great analysis. Some Enterprise Software and Solutions (#EnSW on twitter) analysts base too much of their commentary and advice on what they read in the news, see at user conferences, and hear from other analysts.
