Executive Summary
- The is a shortage of fact checking in software.
- This article covers the issues with fact-checking terminology.
Introduction
A significant problem with the software field is that there is a great deal of hyperbole, which is driven by sales pressure. This page was created to create a list of items that are commonly used in information technology and provide verification.
Why There is Lack of Fact Checking in IT
The following entities most often drive inaccurate statements in information technology.
- Software Vendors: Fanciful, inaccurate, or exaggerated concepts are introduced primarily by software vendors to gain a leg up on sales.
- Consulting Companies: Consulting companies typically promote what are often baseless assertions because they see it as an opportunity to “ride a wave” and to improve their ability to make money and bill more hours.
- IT-Media an IT Analysts: As we at Brightwork Research & Analysis have covered quite extensively, the IT media and IT analyst entities are heavily driven by vendor money. This creates a strong disincentive to perform fact-checking of the type that has recently arisen say in politics at the site Politifact.
Term Sections
- An explanation of the term.
- It’s scoring between 1 and 10, with one meaning the term is either wholly meaningless or deliberately misleading and ten, saying the term is entirely accurate.
- The supporting article link.
The List of Information Technology Terms and Concepts
What follows is our list of trendy terms that are frequently used to market to software buyers. To see a short explanation of the validity of these terms, click the link. Each term has a link to a more detailed description, which will take you to a specific article.
- Digital Transformation
- Re-engineering
- Best Practices
- Column Oriented Databases
- TCO Claims
- Integrated Software Suites
- SOA
- Indirect Access (Type 2)
Digital Transformation
Digital transformation is often used almost synonymously with the term software implementation. It is a problematic term because while software implementation is neutral, the term digital transformation has a built-in assumption of virtue or a positive outcome. It, therefore, qualifies as a term of propaganda as it is designed to influence the listener into assuming a thing being good before it is proven actually to be good. The term is also false, because, in the vast majority of instances where it is used, it describes one digital technology replacing a previous digital technology, which means the modern usage of the term disregards the historical definition of the term.
Score
On a scale of 1 to 10, the term digital transformation receives a score of 1. That is, it is entirely misleading.
The Supporting Article
You can read a detailed explanation of why the term digital transformation is inherently misleading in the article The Problem with Digital Transformation When Applied to IT Projects.
Re-engineering
At first glance, re-engineering may seem to be more of a business term than an IT term. Re-engineering is the evaluation of existing business processes and the redesign of those business processes. However, re-engineering goes hand in glove with IT implementations.
- Re-engineering and Software: Re-engineering often meant adjusting/redesigning business processes to match the functionality in packaged software, and is also highly linked to the term best practices. This is where the current business process is changed to match the supposed best practices that are provided in the packaged software.
- Re-engineering and ERP: Of all the software categories, Re-engineering is most tightly connected to ERP systems. Re-engineering was at its zenith in the early 1990s when ERP systems were becoming the most popular categories of enterprise software to purchase. And re-engineering claims drove many ERP purchases.
Re-engineering claimed that existing business processes were less effective than using more standard processes. The concept in the theoretical sense was that all processes could be redesigned to be better. But practically speaking, the actual outcome in most cases was to discard the existing process to adapt to the standard functionality in the software application. SAP was probably the most aggressive vendor in promoting both the concept of re-engineering and the concept of best practices.
Interestingly, re-engineering was never proven to be true. And it by in large flamed out in the early 1990s as the results from re-engineering was not particularly beneficial to the companies that adopted this concept. Re-engineering became an excuse for what were frequently lengthy and expensive projects that greatly benefited consulting companies.
Score
Some processes can benefit from being re-engineered, but re-engineering proposed that virtually all processes needed to be re-engineered, and the concept was the subject of so much opportunism by vendors (ERP vendors in particular) and consulting companies, that the idea can be considered entirely disingenuous. Ranking such a far-reaching idea is no easy task. Still, the literature on re-engineering is quite critical of the claims of re-engineering (i.e., they were greatly exaggerated), and the benefits are few and far between.
For this reason, we give the concept of re-engineering a score of 2.5 out of 10.
Supporting Article
We cover re-engineering in the article Re-engineering and its Impact on ERP Sales.
Best Practices
Best practices are the concept that there is one best way of doing something. Best practices are very commonly used as a term in consulting. Consulting companies will often state that by using their services, the customer will be exposed to best practices. Some software vendors say that their software contains best practices. This is a widespread claim by SAP. The concept of best practices is used to diminish the requirements that are pre-existing within a company, but they are done so in an evidence-free manner. Both consulting companies and software vendors use best practices as a way of claiming universal virtue to their offerings. This tends to work best in the introductory stages of the relationship. The more exposure the customer or client receives, the less they tend to see the offerings of the consulting company or vendor as best practices, and the more it can appear as purely marketing hyperbole.
Brightwork Research & Analysis does not need to make the argument against best practices because the term has been widely analyzed in the academic literature and been found to lack merit. The findings of the research are that the term is often used, but even experts often will disagree on what the best practice is.
Score
This is not to say that there are not better ways of doing things and worse ways of doing things. However, the term best practices are typically the most intensively used by highly sales-oriented organizations that cannot prove their best practice claims. Claims of best practices should not be taken seriously. For this reason, we give the term best practices a score of 2 out of 10.
Supporting Article
How Valid are SAP’s Best Practice Claims?
Column Oriented Databases
A column-oriented database or column-oriented database store is a database that can have tables where data is stored in columns rather than rows. Both database types are relational; the differentiation is how the information is stored in a relational database.
SAP has put an enormous amount of marketing behind HANA. With the idea that using a column-oriented store, the database can outperform row-oriented databases in all database processing functions. This claim has turned to be untrue. Furthermore, designing the database this way makes the overall database higher in overhead.
Score
Column-oriented databases that are combined with row-oriented databases can have advantages. And the claims made by Oracle and IBM and Microsoft are far more reasonable than those by SAP. However, the claims by SAP, in particular concerning column-oriented databases, move their use of the term into the wrong category. This is not an attempt to communicate the real capabilities of a database type but rather an effort to sell a database using remarkably exaggerated claims.
The overall way the term is used changes depending on the vendor, but for SAP, the use of the term column-oriented database, particularly concerning their product receives a 3 out of 10. For other vendors, the term seems more reasonably used so that the term may rise to a 7 or 8 depending upon its usage.
Supporting Article
The Mismatch Between HANA and ECC and S/4HANA
TCO Claims
In the book, Enterprise Software TCO stated that while TCO is frequently thrown around and vendors claim a lower TCO, in reality, the amount of work that is put into calculating TCO is minimal. Neither consulting companies nor software vendors want customers knowing the TCO of their products and services as it tends to inhibit buying. There is an extreme emphasis on getting customers to focus on the initial cost of the application or service. Interestingly, as part of the research for the book and the online TCO calculators, we found how incomplete any quantification of TCO virtually always was.
What was generally pitched as TCO is what we would call “PCO” or partial cost of ownership? This is one would think a bit shocking, but it comes down to incentives. Who has an incentive to calculate TCO? Most software companies don’t, (although those vendors with a lower TCO should consider it), consulting companies that implement software at least, will ordinarily push customers to software with the highest TCO. A big part of TCO is both implementation and support; the two things that implementation consulting companies make their money from. Our review of Forrester’s TCO study into HANA (which SAP paid for) demonstrated that the faux research was rigged to give the outcome desired by SAP.
Score
The lack of energy put into TCO studies makes it entirely apparent that there is little interest in having buyers know the TCO of the software they purchase. The chasm between the discussions of the importance of TCO versus the lack of effort and integrity that goes into calculating TCO leads us to provide the term of TCO, as used, a score of 2 out of 10. That is in the vast majority of cases, the use of a term is hollow virtue signalling.
Supporting Article (Book in this case)
Integrated Software Suites
One of the most significant trends in enterprise software was ERP vendors acquiring their way into non-ERP applications. In the case of Oracle, it was Oracle moving into applications overall, purchasing both ERP and non-ERP systems.
The presentation of the integrated suite concept is that integration between applications that are not from the same vendor is complicated. The idea is that while it may be acceptable to give up functionality and fit between the application and the business requirements, it is highly desirable to purchase as much software as possible from a single vendor to receive integration benefits.
There is an enormous number of holes with this philosophy, even though it is quite prevalent. This topic became so involved that we needed to move it out to its article, which you can read at The Fallacy of the Benefits of the Integrated Suite.
Score
The entire field of software selection has been undermined by the extensive suite vendors and consulting companies that propose evidence-free platitudes that are 100% self-oriented. Furthermore, the IT media system will never contradict these platitudes because they make a lot of their income from the largest vendors and the most significant software consulting companies.
The integrated suite argument receives a score of 1 out of 10.
Supporting Article
The Fallacy of the Benefits of the Integrated Suite.
SOA, Service Orient Architecture
Around nine years ago, SOA was extremely popular and led to what seemed like an enormous amount of books. The concept was that software vendors would expose their functionality to the Internet, and this would allow customers to virtually mix and match specific functionality into a highly flexible system. What was never addressed are the incentives of the software vendors to do this or what the revenue model would be. Software vendors have to be able to charge for their offering, and SOA seemed to be designed for a 100% open source world. Most amusingly large vendors that base their model on being as close as possible also jumped on the bandwagon. They did so even though their model was 100% the opposite of the SOA model.
Score
SOA died with a whimper. All of the people that wrote books on SOA and entities like Gartner that sang its praises started talking about other things. There is yet to be a post-mortem analysis of how SOA became such a buzzword, even though there was no model for making it financially viable. For these reasons, SOA receives a 1 out of 10.
Supporting Article
Why SAP Will Never Support SOA
Type 2 Indirect Access
Type 2 indirect access is a bastardization of what was the original activity that occurred quite rarely at customers where the customer would create a custom front end to allow their employees to access an application without going through the vendor’s user interface. Hence minimizing the number of users that it had to purchase from the vendor. Type 2 indirect access is only (at this point) applied or enforced by SAP. Type 2 indirect access means that if any non-SAP system is connected to an SAP system that the customer can receive a claim and, if not paid, can be sued by SAP. The overall concept of type 2 indirect access is ludicrous, and as we have written a violation of the tying agreement clause of US antitrust law.
How SAP Indirect Access Violates US Anti Trust Law
If followed to its logical conclusion, all vendors would begin dropping indirect access claims on their customers. SAP could drop indirect access claims on the database that SAP applications reside upon, and customers could start suing SAP because SAP connects their systems to the customer’s “legacy” systems. This is because SAP is leveraging the “IP” of its customers by not paying for the privilege.
Score
Type 2 indirect access is without merit, was not even enforced until around six years ago, and receives a score of 1 out of 10.
Supporting Article
Type 1 Versus Type 2 Indirect Access
Conclusion
Many of the most popular concepts in IT have shown to be without the evidence. They are presented by entities that have a financial reason for supporting the idea. ERP systems propose that ERP systems are necessary and highly valuable. Consulting companies that want to bill for re-engineering suggest re-engineering as being not only essential but required.
No real entity verifies such claims and looks for evidence. The entities that one might think would do something like this are themselves complicit in promoting the bubble in each new concept that comes along.