What This Article Covers
- The History of the Term Legacy System in IT
- The Definition of the Term Legacy System in IT
- SAP’s Relationship with the Term Legacy System
- Misuse of the Term Legacy
- Towards an Accurate Usage of the Term
- Best Practice as a False Construct
So as part of my series on SAP as legacy which began with How SAP is Now Strip Mining Customers, I wanted to write an article to describe how SAP and other vendors deliberately misused the term legacy over the past several decades. In this article, I will show how important the adoption of words like legacy are and how they shape opinions and can influence purchase decisions.
So to begin, let us review the term legacy as it applies to systems.
The Definition of the Word Legacy or Legacy System in IT
In computing, a legacy system is an old method, technology, computer system, or application program, “of, relating to, or being a previous or outdated computer system.” Often a pejorative term, referencing a system as “legacy” means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. By the 1980s it was commonly used to refer to existing computer systems to distinguish them from the design and implementation of new systems. Legacy was often heard during a conversion process, for example, when moving data from the legacy system to a new database. While this term may indicate that some engineers may feel that a system is out of date, a legacy system may continue to be used for a variety of reasons. It may simply be that the system still provides for the users’ needs. In addition, the decision to keep an old system may be influenced by economic reasons such as return on investment challenges or vendor lock-in, the inherent challenges of change management, or a variety of other reasons other than functionality. Backward compatibility (such as the ability of newer systems to handle legacy file formats and character encodings) is a goal that software developers often include in their work.Even if it is no longer used, a legacy system may continue to impact the organization due to its historical role. Historic data may not have been converted into the new system format and may exist within the new system with the use of a customized schema crosswalk, or may exist only in a data warehouse. In either case, the effect on business intelligence and operational reporting can be significant. A legacy system may include procedures or terminology which are no longer relevant in the current context, and may hinder or confuse understanding of the methods or technologies used. – Wikipedia
The term legacy should not be confused or commingled with the term obsolete. Secondly, a legacy system does not have a specific timeframe for replacement. This is explained by more of the quotation from Wikipedia:
Organizations can have compelling reasons for keeping a legacy system, such as:
The system works satisfactorily, and the owner sees no reason to change it. The costs of redesigning or replacing the system are prohibitive because it is large, monolithic, and/or complex. Retraining on a new system would be costly in lost time and money, compared to the anticipated appreciable benefits of replacing it (which may be zero). The system requires near-constant availability, so it cannot be taken out of service, and the cost of designing a new system with a similar availability level is high. Examples include systems to handle customers’ accounts in banks, computer reservations systems, air traffic control, energy distribution (power grids), nuclear power plants, military defense installations, and systems such as the TOPS database. – Wikipedia
All of this illustrates the fact that a legacy system can still be adding a great deal of value.
However, through time SAP never applied this concept to the term. Instead to SAP, designating a system as legacy was seen as a way to identify it as the replacement, and as a replacement by a SAP system of course.
The final portion of the definition from Wikipedia on legacy demonstrates that the term legacy evolved over time.
Alternative view There is an alternate point of view — growing since the “Dot Com” bubble burst in 1999 — that legacy systems are simply computer systems that are both installed and working. In other words, the term is not pejorative, but the opposite. Bjarne Stroustrup, creator of the C++ language, addressed this issue succinctly:
“Legacy code” often differs from its suggested alternative by actually working and scaling.
— Bjarne Stroustrup
IT analysts estimate that the cost of replacing business logic is about five times that of reuse, and that is not counting the risks involved in wholesale replacement. Ideally, businesses would never have to rewrite most core business logic; debits must equal credits — they always have, and they always will. New software may increase the risk of system failures and security breaches. The re-examination of attitudes toward legacy systems is also inviting more reflection on what makes legacy systems as durable as they are. Technologists are relearning that sound architecture, practiced up front, helps businesses avoid costly and risky rewrites in the first place. Poorly designed systems often don’t last, both because they wear out and because their reliability or usability are low enough that no one is inclined to make an effort to extend their term of service when replacement is an option. Thus, many organizations are rediscovering the value of both their legacy systems themselves and those systems’ philosophical underpinnings. – Wikipedia
And in fact, many of the systems designated as legacy by SAP were never replaced by SAP. This was one of the common disappointments on the part of companies that purchased SAP, particularly SAP’s ERP system, who often purchased SAP ERP, and other ERP systems to obtain a simplified system landscape and to drive down costs.
However, the proposition was never particularly accurate as SAP ERP never maintained the breadth of functionality necessary to decommission so many legacy systems. And the concept of best practices contained in SAP was also similarly oversold. This is explained well by a quote from KC Richards, a consultant with decades of development experience.
My first encounter with term “Legacy Systems” was during the adoption period of RDBM systems, mid to late eighties. Yes, there was a time when you could put your job in jeopardy in even suggesting that you would include a “Relational Data Base Management System” in a software architecture. ISAM, flat files, and other creative indexing techniques where the safe way to go. In the decade before, Dr. Codd (IBM System R – “In Codd we Trust”) and Michael Stonebraker (Ingres) where competing over definition of what exactly made up a relational database and what was the most logical data manipulation languages. SQL or QUEL?
Each of the pioneers of relational theory were working on their own products. Larry Ellison was porting his RDBMS on every hardware platform her could find. Sybase was working with Microsoft to license “Data Server”, a database product originally built to run on UNIX computers. That work led to a product called Ashton-Tate/Microsoft SQL Server 1.0 (I remember being a beta user). Anything on a RDBMS was Avant-guard, everything else became “legacy”.
I found this point of KC Richard’s quotation, particularly of interest. Here is why and it is quite pertinent to SAP. According to SAP, relational (actually row oriented) databases are now legacy and column-oriented databases are recommended by SAP. As I have covered in multiple articles on HANA such as When Articles Exaggerate HANA’s Benefits, this is an oversimplification. Column-oriented databases have a specific purpose and their benefits do not generalized to all usage types. Let us continue where KC Richards states:
Then came the next generation of “legacy” markers. “If you were not GUI, you were chewy” Then “Legacy Systems” were those not written in “newer” object oriented languages to take advantage of newer hardware platforms. “Legacy Systems” became those that didn’t have GUI screens. Windows 3.1, Macintosh, and OS/2.
Legacy has become that term used to conveniently play on the fears of a company that get define where its sunk costs rest, usually because they have lost track of what they expect of a system. Oddly enough, data entry is still more efficiently on green screens than GUI applications. Legacy systems are simply what you have when you get them.
This gets to a great point by KC Richards.
What is legacy?
Is legacy a term that we simply accept as what is trendy at the time? Is it about usage or about what is new? Are software vendors using this term honestly or is this marketing and perception?
SAP’s Relationship with the Word Legacy
They would simply declare all systems that were developed in-house as legacy. But that it not a correct use of the term. Legacy systems are the systems for which companies want to reduce their maintenance and future investment. But they are not necessarily systems that can be economically replaced. For example, there were many things that home built systems did that still were required and that SAP would never do.
Porting the functionality to SAP does not solve this basic issue. You are simply porting code to SAP, but that does not mean SAP is “actually doing it.” That is just ported code.
Also, as we are on the topic, why port code to SAP in the first place? Why not simply keep the existing system working and integrate these systems to SAP. When porting to SAP, it means portion what was in most cases an open language like C to a proprietary language of ABAP which does not have a similar development efficiency. This means that the maintenance and costs invariably increase.
Misuse of the Term Legacy
There is a distinction between legacy and obsolete.
Let me provide a specific example, which is the US rail system.
The US Rail System
The US has roughly 98,000 miles of railroad track. This track is old, but it is not legacy. And why not provides important insights as to how the term legacy should be used.
Rail is far more fuel efficient and cost effective than motor transport. The US would have a very difficult time delivering freight without this rail system. Maintenance should not be minimized on the US network of rails, in fact, maintenance should be kept to a high level. The US should not shrink the total number of miles of track (as we have in the past) but should expand them to take freight off of the roads, which is a highly energy intensive and polluting way to move freight.
Now let us look at another system.
The US Road System
The US has around 4 million miles of roads. Most of these roads were built after the rail network. There have most likely been too many miles of roads created. This is primarily because they were created during a time of low-cost oil. Due to global consumption versus attainable supplies, this looks sure to not be the case in the future.
Therefore, while some of the 4 million miles of roads are needed, some are probably going to be legacy as auto travel will need to come down in the coming decades.
So while the road network in the US is partially legacy, none of the rail networks would qualify as legacy. Thus, the age of the items is not the primary driving factor in determining whether something should be considered legacy. Legacy is all about usage or expected usage.
Legacy is all about usage or expected usage. Not age.
Towards an Accurate Usage of the Term
In this article, I am attempting to describe the term legacy by its objective definition. I don’t make more money if people use it correctly, I don’t make less money if people use it correctly. However, the same cannot be said for software vendors. I don’t know how all the software vendors use the term legacy, but as I study SAP documentation and SAP statements and I know how SAP uses the term legacy. When SAP uses the term legacy, they mean any applications that were built by their customer. SAP used the term inaccurately and in a self-centered and negative sense to diminish the systems that the customers already had. SAP very much pushed forward the concept and the highly dubious concept of best practices which seeks to propose, and to propose falsely that all business processes either fall into SAP’s software flows, or they are illegitimate. In fact, SAP continues to make this argument regarding customizations for their new ERP system, S/4HANA.
Another key “how” question we hear S/4HANA adopters frequently debating is their approach to customization. Typically, customers have tended to heavily customize their existing SAP ECC on-premise deployments and, in moving to S/4HANA, organizations can rethink their business processes, which may result in more simplicity and avoid the need for a lot of customization. – ASUG
*This quote is from ASUG, but as ASUG is simply a marketing arm for SAP, I do not draw any distinction between statements from ASUG and statements from SAP. This is SAP’s position on customizations. SAP was wrong when it proposed that customers would be able to move to “best practices” with earlier versions of their ERP system, and they will be wrong again when S/4HANA is broadly implemented.
Best Practices as a False Construct
I covered SAP’s incorrect usage of the term best practices in the following article How Valid are SAP’s Best Practice Claims?
The idea that SAP contained best practices was never true. SAP often offered many ways to configure a system, so SAP contradicted itself as this would have to be called best practices, or multiple best practices per process. There are many ways of doing things that aren’t even very good practices much less “best.” My conclusion of SAP’s best practices is that they are just a marketing concept that looks good in powerpoint presentations. The less you know about SAP; the more best practices seem like they may exist in SAP.
My conclusion of SAP’s best practices is that they are just a marketing concept that looks good in powerpoint presentations. The less you know about SAP; the more best practices seem like they may exist in SAP.
The fundamental problem with the concept of best practices is there can be not final agreement as to what a best practice isn’t a best practice. Secondly, when SAP or any vendor for that matter declares that they have all the best practices, it must be understood that this is a self-bestowed title. Self-bestowed titles don’t have any meaning. It would be like me naming myself the best dancer in Atlanta. But at least there is some competition I could enter to prove such a thing. There is no best practices competition that is held and no official body that approves certain practices over other practices and names them “best.”
I am still waiting for the software vendor to advertise the fact that they only have the worst practices in their software.
Therefore, part of the reason that SAP used the term legacy was to criticize the existing systems of their customers and to do so without specifically analyzing any of them. And SAP’s solution?
Well, this is two fold.
- In as many cases as possible simple eliminate the in-house software and move to SAP’s “best practices.” In SAP’s considered opinion, none of them were necessary as SAP’s software did everything correctly anyway, and anything the customer had come up with was the wrong way of doing it. This was true even if SAP did not have the specialized functionality that was developed over what was in many cases decades by the customer.
- Port all the logic from open programming languages to their ABAP programming language.
SAP misused the term legacy on countless sales engagements. They used the term as a term of propaganda. So what does that mean? When a term is used this way, it is used not to describe something accurately, but just the opposite. The intent of the user is to describe inaccurately and to make the listener more amenable to what the message.
A second important characteristic of what defines when a term is used as propaganda is that and often without having to provide evidence to support the claim. And if we observe how SAP used the term legacy, there was never a case by case analysis at companies whether the functionality could be replaced by SAP, whether it was a good idea to customize it into SAP if it could not be replaced, etc.. That would have taken a lot of work, and in many cases the outcome would have been both that SAP did not have the functionality and that it made no sense to port the functionality to SAP.
It was much easier to simply use the blanket term legacy, to paper over or obscure all of that analysis. Rather than being analytical, the use of the term legacy seems specifically designed to appeal to emotion and to fashion. To a concept of there being an “in crowd ” and and “out crowd.” Companies wanted the new great stuff that SAP offered, and did not want to be stuck with “legacy.” One wonders how many decisions to go with SAP or other similar vendors when this term was in its heyday, simply to present the impression that the company was hip and with the times.
The fashion industry is based upon a premise that its customers need to get the new items, which have a higher social status. If you don’t buy the newest items, you are stuck wearing legacy garments. Companies are presented in business school textbooks as highly rational, and one would generally not think that decisions work the same way. However, the term legacy is essentially the same strategy to motivate purchasing behavior as the fashion industry