How ERP System Was Always a Vendor Provided Trojan Horse

 Executive Summary

• ERP vendors presentation the concept of a single system for everything, and later a fully integrated suite.
• Neither of these proposals ended up being true. Increasingly ERP looks like a Trojan Horse.

Introduction

ERP fundamentally reconfigured the enterprise software marketplace and became a significant software category. ERP had a second impact: it positioned several vendors extremely well to sell other types of software. However, what is rarely discussed is whether the logic used to persuade companies to purchase ERP systems has proven true over time. This is the topic for this article. In it, I will analyze the primary reasons provided for ERP implementations and how that logic has held up.

Our References

See our references for this article and related articles at this link.

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).

A major reason why software vendors have gone on acquisition sprees is due to the resonance of the concept of the single integrated suite.

In this article, we will review the philosophy of integrated suites and get into more detail than is typically done when this term is used, finishing off by getting into the topic of how ERP systems became a Trojan Horse.

The Single System Logic for ERP

The initial idea behind ERP systems was to take many applications and make them a single system – reducing application integration issues.

“Many technical reasons exist including the replacement of disparate systems into a single integrated system (Hitt et al., 2002).”

However, after the significant ERP vendors sold the ERP product to companies, they began to develop specialized products for things like supply chain planning, business intelligence, customer relationship management, etc.. This was done for several reasons. One was that there was simply no way that an ERP system, with its simple approach to all functionality – with the possible exception of finance and accounting, could meet all the needs of companies. Secondly, once ERP companies had sold their ERP applications, they needed to develop more applications to grow their sales. Once they had the ERP system implemented, they had the network effect on their side, as the ERP system is the mother ship application for a company, the application or set of applications to which other applications must all integrate. This allowed ERP vendors to unfairly compete by telling companies that their applications had a head start in integration into the company’s ERP system. Companies like SAP and Oracle promptly took full advantage of this market power.

This means they were in a competitive position to sell more software into these accounts. These applications all have their platforms and adapters to one another, but each is a separate application with a different database sitting on different hardware. This means that companies are essentially back where they started before the move to ERP systems. However, they now rely more on external application development through commercial software rather than internal application development. This leads to the next point.

The Logic of Cost Reduction for ERP

All of these factors undercut one of the primary arguments that were often used to sell ERP systems, which would reduce costs. As is explained above, the main reason for IT simplification-based cost reduction is gone. However, after ERP systems had been sold, that logic conveniently left the building or declined as a point of emphasis because the motivation moved towards selling different types of software after ERP software had been sold. I noticed this change at SAP. Back in the late 1990s, before they had a supply chain planning system, SAP essentially told companies that supply chain planning systems (which duplicated some of the supply chain functionality in SAP R/3 but also offered supply chain functionality, not in ERP systems and provided much more advanced functionality.) were unnecessary. However, after they developed their external supply chain planning system, they changed their tune and proposed that it was now essential.

Business Cost Reduction

The second area where ERP systems were supposed to save companies money was in the standardization of business processes. This has been accepted uncritically, as the quotation below demonstrates.

“It is also one of the most worthwhile initiatives for securing your place in a competitive market. A successful, enterprise-wide implementation will move your company from one with piece-meal business procedures and no overall plan, to a re-engineered organization that is poised to take growth and profitability to a whole new level.”

However, there was never any evidence that this was, in fact, true. Searches for research in this area do not produce studies that show the beneficial effects or the cost-reducing effects of ERP implementations. However, there are several studies in the area. Interesting quotes have been listed below:

“The benefits of ERP systems are usually overestimated by ERP vendors.”

The Best Practice Logic for ERP

How SAP pushes the concept of best practices is extremely easy to ridicule, as I have done in multiple articles such as here and here. SAP took the initial pitch of best practices from their ERP system sales approach and applied it to other products, such as their supply chain planning suite. As an expert in these SAP systems, I can say that any statement regarding best practices in the SAP supply chain planning APO suite is utterly unfounded. Not only does SAP APO not contain best practices, but many of the areas of functionality in APO are the worst practices. After more than a decade of opportunity, very few companies have benefited from buying or implementing APO, with companies having a higher likelihood of failure with APO than success. It makes one wonder if the entire best practice logic for ERP was ever valid. What many vendors call “best practice” is often a code word for “generic” functionality. For instance, many companies would say posting a goods receipt document after a product has been scanned into a warehouse is a best practice. But is it, or is it merely generic? In the same way, is using a steering wheel to steer a car a best practice? Indeed, one could say it is, but it is also now a generic offering.

Furthermore, ERP systems had watered-down functionality. This was acknowledged even by ERP vendors but was counteracted by improved integration. How such watered-down functionality can contain “best practices” is a mystery.

The Integration Logic for ERP

ERP systems integrate some things but not all things. And again, because corporate landscapes have so many applications, a lot of integration work still needs to be done. One of the areas of logic for ERP systems was that the company would be better integrated. However, it is hard to see how that is the case, and wouldn’t this improvement show itself in financial performance? As pointed out in a research study into the benefits of ERP.

“In the end, it could be said that previous research suggest that a mixed result exists when analyzing the effect of IT on business performance where some studies supported a positive relation while others suggested that companies adopting ERP did not perform financially better than non-adopting companies (Nicolaou, 2004). It can be also said that the effect of IT on business performance differs from country to country (Pilat, 2004) and should be considered when measuring business performance gains due to IT adoption.

Therefore, previous research has found contradicting findings regarding the effect of ERP systems on business performance. While some researchers have found that ERP systems can affect overall business performance positively, others have only found ERP systems to affect specific areas communications of the IBIMA 6and not the overall business performance. This can then suggest that ERP systems do not always affect business performance positively and some contributing factors affect this relationship (Kang et al., 2008).”

The Real Benefit of ERP Systems

The only demonstrated benefit of ERP has been to the ERP vendors, not the buyers or ERP software. Purchasing an ERP system is a highly efficient way to lock in a customer to a vendor and allow the vendor to sell them other applications.

The Presentation of the Integrated Suite Philosophy

The presentation of the integrated suite philosophy is that integration between applications that are not from the same vendor is complicated. The concept 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.

This philosophy has significant holes, even though it is quite prevalent.

Virtually All Applications (Integrated Suite or Point Solutions) Are “Integrated”

Here is the standard type of integrated marketing hyperbole offered by integrated suite vendors.

“The SAP NetWeaver technology platform is a comprehensive integration and application platform that helps reduce your total cost of ownership (TCO).”

This sentence is inaccurate. NetWeaver never did anything to improve integration on projects and was more a marketing construct than an actual product, as is covered in the article Did Netweaver Ever Actually Exist?

However, this concept was effectively used to push customers to buy from SAP, and customers found out that Netweaver did nothing to reduce integration overhead. Before Netweaver was offered by SAP, the argument was that all of their applications were already integrated. If that was the case, then why was Netweaver necessary?

Unless the application sits on the same database as another application, all applications require adapters. The only applications that meet this standard are the various modules within an ERP system. For example..

• The sales module of an ERP system sits on the same database as the finance module. In that case, there is no integration.
• But this is not true of any non-ERP application.

The Reality Around Adapters

Sometimes, the adapters are internal to a vendor; sometimes, the adapters are between applications from different vendors.

But, because in many cases, the software that is sold as part of an “integrated suite” is from a variety of different vendors, the adapters that you receive from integrated suites are often nothing more than the adapter the acquired application already had when they were part of the pre-acquisition independent vendor.

Furthermore, the idea that being acquired by a more significant software vendor means better or more complete adapters to be created is also an oversimplification. Many stories of integration still being a problem years after an acquisition. In the case of the SAP acquisition of Ariba, Steve Lucas of SAP made a strange statement that we covered in the article The Problems with Diginomica on Steve Lucas on HANA, Oracle, IBM, AWS, and Microsoft.

Steve Lucas made the following statement to Diginomica: Diginomica allowed to pass without comment.

“We are integrating that (one of that being Ariba) with our logistics applications, our inventory applications.)”

There is a three-year lag between the acquisition of Ariba and this comment by Steve Lucas. How many years are necessary for SAP to integrate an acquisition into SAP’s ERP system?

While researching the book The Real Story Behind ERP, I found interesting information regarding the tactics used to sell ERP software. One of the central arguments used to sell ERP was that it would decrease the need for integration. This turned out to be false but was a primary motivator for many ERP purchases.

A Better Course for Achieving Integration

A much more effective solution than what has been described above would have been if ERP companies had never been allowed to procure other vendors, and if ERP vendors had not created external products, and instead if they had worked to publish to an integration standard and approved the middleware vendors, those that were skilled at creating middleware to create the adapters.

Why ERP Vendors Invested Nothing in Publishing Standards

ERP companies were not interested in doing this. Instead, they intended to use their position with their customers to sell more software, which was often poorly integrated and uncompetitive with best-of-breed applications. This way, the ERP companies put their interest ahead of their customers’ attention.

This is explained in the quotation below:

Of course, as soon as companies began buying these products, it became clear that enterprise software was another chunk–a much larger and better integrated chunk to be sure, but still a chunk–of software in a complex architecture of IT systems that desperately needed to talk to one another and exchange information. The vendors created clunky, proprietary methods of connecting their systems with others that have improved over the years, but that misses the point. The architecture of these systems, in a broad sense, was just like the ones that they were intended to save you from–monolithic, highly integrated and difficult to change.

After the Acquisition of a Vendor, How is The Integration Story “So Much Better?”

Applications tend to have adapters to the significant ERP systems both to ease the sales process and to speed the integration process. Therefore, giving an integrated suite so much preference over applications from different vendors is a vast oversimplification. If a vendor is acquired and already had an existing adapter to the company that acquired it, what changed from the integration perspective due to the acquisition?

We cover this topic in the book Enterprise Software TCO: Calculating and Using Total Cost of Ownership For Decision Making.

“…while many companies like SAP and Oracle lead executives to believe that they will incur minimal integration overhead if they purchase one of their non-ERP applications to connect to their ERP applications, this is untrue. All of SAP and Oracle’s applications sit on different hardware, and while they may have adapters, they are not actually integrated – they have different databases (the term “integrated” is colloquially used to mean any connected systems, but most accurately it means that the systems sit on the same database – when systems have adapters between them, they are not actually technically integrated). The quality and ease of use of these adapters is often not actually superior to the adapters that are written to connect best of breed applications to the ERP system.”

Integrated Suites Tend to be More Expensive in Multiple Dimensions (i.e., Have a Higher TCO)

Integrated suite vendor tends to charge more than point solutions. For example, when IBM acquires an application, one of the immediate effects is for the price of that application to rise significantly. However, the change in the price of the application license is only one part of the increased TCO.

Large consulting companies also implement an Integrated suite more often, increasing their TCO. This is the truest of the most oversized integrated suites, and consulting companies will typically only build consulting specialties around these most prominent vendors. As soon as the application is implemented by a consulting company, a consulting company makes a practice around the software, and the costs vary significantly. Consulting companies charge more daily than the consultants of software vendors (not in all cases, but in most cases), and they also lengthen the implementation duration.

And they do this often against the wishes of the software vendor. This extra cost quickly overwhelms any increased integration costs from integrating point solutions to the existing systems at the account.

Integration Suites as a Way to Reduce Competition?

It is no secret that software vendors do not acquire other vendors to increase their competition. Our research into the growth of ERP vendors other associated applications, after ERP vendors told customers that ERP systems were the only applications they would ever need, is covered in our book The Real Story Behind ERP: Separating Fact from Fiction.

“…this has meant that the business does not get the software it needs. Software selection based on software suites does not emphasize each application (emphasis added) but instead emphasizes the suite. As explained in this quote from Christopher Koch of CIO Magazine, software suites themselves are mechanisms that reduce the competition a vendor must face.

“Indeed, integration standards interfere with ERP vendors’ traditional ways of gaining and keeping customers and market share. Before the Web came along, your integration strategy was simple: Buy as many pre-integrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long- term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.”—ABCs of ERP

How well is that working for companies that bought ERP systems? Did companies find they could eliminate all legacy systems and not use non-ERP systems?

Integration is Not a Primary Driver of TCO

No one else has performed as much work into TCO as Brightwork Research & Analysis. Our free TCO calculators are available for anyone to use. The poor state of TCO research was uncovered as part of our investigation into TCO, the literature review we performed before creating our calculators, and writing the only book on the TCO of enterprise software systems. We were not able to find any reliable studies on TCO. Most TCO calculations, for instance, those we analyzed from Salesforce, are created by the marketing department of the software vendor. And “shockingly,” in each case we examined, the TCO estimation released by the vendor showed them as having the lowest TCO in 100% of the occasions.

One of the conclusions from our research is that integration is an overestimated cost by the most prominent software vendors and consulting companies that align with integrated suites for their financial reasons. By recommending an integrated suite, consulting companies can drive their “client” to the highest TCO outcomes.

Consulting Companies Focus on TCO or Set About Maximizing TCO?

It should also be remembered that large consulting companies do not want their customers to know the TCO of different solutions. This is because consulting companies like Deloitte or Accenture drive higher TCOs significantly. In our calculators, the highest TCOs routinely came from the purchase of large software suites implemented by the largest consulting companies. The major consulting companies are a primary reason why the ROI on so many application implementations are negative as is covered in How Consulting Firms Parasitized enterprise Software.

An extra benefit of using smaller vendors and more point solutions is that companies like Deloitte and Accenture don’t have trained resources available in those applications, and the vendor’s consultants typically implement the applications.

How Consulting Companies Undermine Any Intelligent Software Selection Process for Their Ends

Consulting companies like to create “uni-crop” software environments that allow them to have large numbers of consultants in a relatively minor number of applications. Consulting companies overstate their software coverage and resource specialization to their clients routinely. They will often hire independent consultants off of the market (as the client could have done) and then present the independent consultant as if they are a full-time employee, and that represents, furthermore, the consulting company was somehow responsible for developing their skills. The consulting firms demand a significant margin on the resources even if they met the resource a week ago.

Hypothesis Testing

Our risk research into software risk which calls into question the quality and objectivity of the information provided by large IT consulting companies are covered in the book Rethinking Enterprise Software Risk. The following quotation is from this book.

“Is there a way to test this hypothesis?

The question we had was whether clients that followed the advice of major consulting companies would receive the benefit of lower risk implementations. As it turns out, there is a way to test this question. The applications recommended by the major consulting companies are rated for risk (among other characteristics such as maintainability, usability, functionality and implement-ability) in the Brightwork Research & Analysis MUFI Rating & Risk evaluation. We compared the MUFI Rating & Risk evaluation for applications in ten software categories and compared them to software that the major consulting companies typically recommend.

The research shows that the applications recommended by the major consulting companies always have a high or the highest TCO (total cost of owner-ship) in the respective software category, along with the highest risk. The reason is simple: not a single major consulting company that provides IT services is a fiduciary. This means Accenture, IBM, Deloitte, etc., have no legal responsibility to place their client’s interests ahead of their own. And the internal incentives laid out within each consulting company, where sales is far more esteemed than implementing the software successfully, or even implementing the best software (there is no measure for this whatsoever) means that the customer’s interests are a distant second to the profit-maximizing interest of the consulting company. It is in the financial self-interest of these major consulting companies to recommend software for which they have trained resources ready to bill—therefore it is this software that is recommended.”

How to Misunderstand the Risk of Purchasing More Software From One Vendor

After a detailed analysis of this topic, it is clear that the standard approaches to managing risk on enterprise software selection and implementations, such as hiring a name brand consulting company, purchasing name brand software, or paying for IT analysts like Gartner, do not work. This should be entirely obvious at this point.

Some journalists will mourn the high failure rate of IT projects but fail to point out the precise reasons. Most of the advice they give and the issues they highlight seem to be just nibbling around the edges of the problem. (Most of them can’t because the entities most responsible for the high failure rate of IT projects are significant advertisers in the publications they write for). However, the failed approach to risk management is still the dominant approach to managing project risk. This chapter explains why each approach does not work. We will start with one of the most commonly followed strategies.

Purchasing More Software From One Software Vendor

This is an augmentation of the strategy above. However, its logic is primarily based upon integration, which has been historically the “fool’s gold” in the enterprise software area.

The concept is that the buyer will benefit from improved integration if they buy more software from a single vendor. This is covered in the article SAP’s Position on SAP to Non SAP Application Integration. This is one of the most important ways that companies end up with inappropriate and low-functionality applications – and in fact, it is one of the primary methods by which large software vendors and mediocre applications compete with and win out against far superior applications. Integration benefits were instrumental in the growth of ERP systems. I quote from my book The Real Story Behind ERP: Separating Fiction from Reality.

“Enhanced integration was one of the major selling points of ERP. The hours of PowerPoint presentations that have been created since the first ERP systems were sold describe the great cost savings and integrative benefits that implementing companies would receive from a “solution” where all the main applications used the same database. One of the assumptions about purchasing an ERP system was that the buying company would implement all of the modules and decommission their current software.

The fact is, some of the company’s pre-existing applications could not be replaced by ERP, and for a variety of very good reasons.

Contrary to most assumptions, ERP systems provide no advantages in terms of integration to other systems, and in fact present several disadvantages:

Here is a much more effective solution than I have described above: ERP vendors should never have been allowed to procure other vendors. They should not have created external applications, and instead should have published an integration standard and allowed the middleware vendors (those that were actually skilled at creating middleware) to create the adapters.”

ERP technology does not offer an integrated solution but amplifies the need for integration. — ERP and Application Integration

Although ERP is touted as a single architecture, ERP applications usually contain different generations and sources of technology. Third-party applications are acquired and amalgamated into the platform, sometimes by name only. In total, this makes the environment complex for the customer and difficult to change over time. ERP suppliers have become system integrators. [emphasis added] The sheer size and number of applications makes moving all the applications forward a difficult task. Application functionality often lags. — ERP Alternatives

The Validity of the Hypothesis

It turns out that the hypothesis, which was never anything more than an untested hypothesis, no matter how confidently it has been asserted, of selecting more software from one vendor to reduce the integration costs, has not worked in practice. Those that make the assertion have no research to support their contention. (a hint: we did perform the research, and the assertion turned out to be widely incorrect.) Furthermore, the approach places unnecessary shackles on the software selection process. It has been a primary way that SAP and Oracle have grown to their dominant position. It has caused many software vendors such as JDA, Sage, and Infor to perform software acquisitions to provide a full suite of products to customers, steering them to purchase other applications, often based on the software vendor who provides the ERP system. These vendors see the ERP system as the pathway to achieving more monopoly power and, therefore, the ability to increase their prices.[1]

The Most Important Feature in the Software Correlated to Implementation Success

This has led us to conclude that the most crucial feature of the success of an implementation is the match between the business requirements and the selected software. Not whether the software comes from a single vendor. There can be cases where more than one application purchased from one vendor meets a customer’s business requirements. Still, each application should be able to win in each area on its own merits without relying on the “crutch” of being part of a suite of applications offered by one vendor.

The degree of match is a significant determinant of the overall risk of the implementation. That is, pushing for an integrated solution at the expense of fitting with business requirements will result in a higher risk that the project either never goes live or that the value it provides to the company will be minimal after it goes live.

An Often Repeated Evidence-Free Assertion

The integrated suite argument, most prominently from ERP vendors, is at its essence and the evidence-free assertion put forward by integrated suite vendors and reinforced by consulting companies with a financial interest in repeating and companies like Gartner. They receive the most vendor income from the most significant vendors and slant their Magic Quadrants toward the most significant vendors.

To provide evidence would require a little work, and the outcome would go in the opposite direction of the assertion. We have provided more evidence against the integrated suite argument in this one article you are reading than has been provided to support the integrated suite argument.

This says a lot about how little assumptions are verified in IT.

IT buyers have proven highly susceptible to misleading simplistic platitudes that are promulgated not because they are true but because they fit the financial incentives of those who promote these concepts. The most prominent IT analyst companies have proven useless in educating IT buyers on these inaccuracies because, in part, they are paid by the most prominent software vendors and consulting companies to perform well in their various published ratings. 

How ERP Systems Were a Trojan Horse

Enterprise software is an area with an enormous amount of hype, and while some of the hype works out and becomes real, most of the hype does not. That means that most hype people are exposed to will not work out. And when I say “work out,” I don’t only mean won’t become popular — because some things can become popular but don’t work out in that they don’t add value over what they replaced. After purchasing the enterprise resource planning system, it started gobbling up the IT budget.

It also narrowed the buyer’s options significantly and put a series of false assumptions into place. That was that the purchaser needed to perpetually consider and give preferential treatment to the enterprise resource planning system when making all other enterprise software purchases.

Using the enterprise resource planning system to preference purchases for other software, the enterprise resource planning vendor offers what I call horizontal competition, as it is competition within one layer. (For those with an economics background, you will recognize the relationship to horizontal integration.)

How Competition in Enterprise Software Works

However, competition for software sales moves vertically as well as horizontally.

• For instance, Oracle has used its high market share of the database market as a wedge to get into applications (by acquiring many applications vendors and by leveraging its already account management).
• SAP is currently using its dominance in many of its customers in the application space to push Oracle (and others) out of the layer below by introducing its database.

A great deal of misinformation about the centrality of enterprise resource planning systems has been built up over time, which was never proven but merely became part of a set of unexamined assumptions that continue to drive enterprise software purchases. These are unmet promises that are virtually undiscussed.

The ERP System and Horizontal Enterprise Software Competition

In my view, one of the worst things in the history of enterprise software decision-making was the introduction of enterprise resource planning systems in the mid-1980s. Before this time, systems that made up enterprise resource planning were sold by different vendors.

Industry Consolidation

Enterprise resource planning software caused lots of consolidation, so much so that after the 1980s, it was uncommon to find MRP vendors that had not been gobbled up and incorporated into an enterprise resource planning suite.

Ignoring The Reduction in Choice

This was sold as a good thing. However, it reduced the choice available to customers because they now had to select an enterprise resource planning suite where the various selections had been already made for them. This feature of enterprise resource planning systems went seemingly unnoticed by IT analysts. A tremendous amount of money was paid to analysts like Gartner, and they never provided a 360-degree view of the implications of buying so much functionality from a single vendor. Gartner and other analysts promoted the trend to the moon. 

What is the Specific Comment

Now, I am not commenting” here as to whether enterprise resource planning systems are necessary or not necessary. Instead, I am commenting on how enterprise resource planning systems have been and continue to be used in what is referred to as “account control.”

What is Account Control?

Account control is a term coined by IBM decades ago, which describes how IBM would use a customer’s previous IBM purchases to control its future purchases and steer them towards buying more IBM products. It’s not something IBM talks about in public, but it is part of the public record that they discussed this strategy on many internal documents.

The ERP System as the Queen

Quickly following their introduction, ERPs became the queen of the enterprise software chessboard, and once captured, the software vendor who captures this piece could dictate much of the rest of the game.

At its essence, this is anti-competitive behavior because the enterprise resource planning company is no longer merely competing on a level playing field but is proposing that its other applications be given preference because they “integrate better” with the already purchased enterprise resource planning system. Since before John D Rockefeller, every monopolist has used control of one area to establish control in another, most often connecting area.

ERP-Centric Strategy?

Enterprise resource planning vendors used these systems to steer purchases to applications that would have never been bought in a freely competitive arena. In our book The Real Story Behind ERP, which was a meta-analysis of every single academic study into the ROI of enterprise resource planning software since the category was first introduced, the book outlines how we could not find a single study that demonstrated a positive ROI of enterprise resource planning systems after go-live.

Overall, this has set back the enterprise software decision ever since. While it did this, it established a faulty thought pattern in enterprise software decision-makers — and ERP-centric thinking is a consequence.

I ridiculed this way of thinking, which I likened to a medical condition in the article Do You Suffer from (ECS) – ERP-Centric Strategy?

Conclusion

Those vendors that offer integrated suites universally attempt to make their customers overestimate the degree to which their applications are integrated into one another, and push their prospects to overstate the impact on TCO of application integration. Furthermore, they also minimize the adapters that the point solution providers have created for the major ERP systems.

Therefore, the most prominent software vendors, consulting companies, and IT analysts (by and large) push the integrated suite concept as improving implementation outcomes, not because it is true, but because they find it to be profit-maximizing.

The enterprise resource planning system has not lived up to its promises. The entire software category was promoted by and for the vendors and consulting companies that benefited from ERP sales. These entities created the impression that companies “had to have” enterprise resource planning software. However, there was never any evidence presented that this was true. Instead, it was proposed through endless conferences, articles, consulting, and vendor presentations.

Based upon pretenses, these systems became the queens on the chessboards of enterprise software, where they promoted the sale of more software that the vendor often acquired. This created higher degrees of concentration in enterprise software and more lock-in and account control than could have been obtained without these systems.

Our research at Brightwork Research & Analysis shows that buying a large quantity of software from one vendor is the worst strategy a company can follow, resulting in the highest costs and lowest functionality of all available solution architecture strategies. We also measure the riskiness of applications, and again, the more applications purchased from one vendor, the higher the risk to the buyer – because it means a higher likelihood of implementing weak applications. Prominent software vendors with many applications are universally not strong in all of their applications. The more a buyer purchases from any one vendor, the higher the likelihood that they will purchase an application that has a far more competitive application in the marketplace – that can be implemented more quickly, at lower risk, and with a higher ROI.