- 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.
ERP fundamentally reconfigured the marketplace of enterprise software and became a significant software category. ERP had a second impact in that it positioned several vendors extremely well to sell other types of software. However, what is rarely discussed is whether the logic that was used to persuade companies to purchase ERP systems has proven to be 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.
See our references for this article and related articles at this link.
One of the largest 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 that integrated suites and gets 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 that it would 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 major ERP vendors sold the ERP product into 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 application must all integrate. This allowed ERP vendors to unfairly compete by telling companies that their applications had a head start in integration to the company’s ERP system. Companies like SAP and Oracle promptly took full advantage of this market power.
This means that they were in a competitive position to be able to sell more software into these accounts. These applications all have their platforms and do have adapters to one another, but are each 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. Except, 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 they would reduce costs. As is explained above, the main reasoning 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 after ERP software had been sold, the motivation moved towards selling different types of software. 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 provide 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 which 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 a worst practice. After more than that, a decade of opportunity, very few companies has 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 ever had any validity. What many vendors call “best practice” often seems to be a code word for “generic” functionality. For instance, many companies would say that 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 say 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 it was counteracted by improved integration. How such watered down functionality can also contain “best practices” is a mystery.
The Integration Logic for ERP
ERP systems integrated some things, but not all things. And again, because corporate landscapes have so many applications, there is still a lot of integration work that 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 to the buyers or ERP software. A purchase of an ERP system is an extremely efficient way to lock in a customer to a vendor and allowing 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 into order to receive integration benefits.
There are significant holes with this philosophy even though it is quite prevalent.
Virtually All Applications (Integrated Suite or Point Solutions) Are “Integrated”
Here is the standard type of completely 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 marketing construct than an actual product as is covered in the article Did Netweaver Ever Actually Exist?
But this concept was effectively used to push customers to buy from SAP, and customers found out that Netweaver did nothing to reduce integration overhead. The argument before Netweaver offered by SAP 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, and 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 better or more complete adapters to be created is also an oversimplification. There are 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, that, of course, 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 to 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 in any case.
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 actually skilled at creating middleware to create the adapters.
Why ERP Vendors Invested Nothing in Publishing Standards
ERP companies had no interested in doing this. Instead, they intended to use their position at their customers to sell in more software, which was often poorly integrated and uncompetitive with best of breed applications. In 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 it is a vast oversimplification to give an integrated suite so much preference over applications that are from different vendors. 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 specifically 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 significantly rise. But the change in the price of the application license is only one part of the increased TCO.
Integrated suite is also more often implemented by large consulting companies, which increases their TCO. This is the truest of the largest integrated suites and consulting companies will typically only build consulting specialities around these largest vendors. As soon as the application is implemented by a consulting company, an consulting company makes a practice around the software, the costs vary significantly increase. Consulting companies not only charge more daily than the consultants of software vendors (not in all cases, but most cases) but 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 that come 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 the competition that they face. 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 that they were able to eliminate all legacy systems and not use any non-ERP systems?
Integration is Not a Primary Driver of TCO
There is no one else that 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, that is 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 both the largest software vendors and the consulting companies that align with integrated suites for their financial reasons. Through recommending an integrated suite, consulting companies can drive their “client” into 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 what the TCO of different solutions is. This is because consulting companies like Deloitte or Accenture are significant drivers of the higher TCOs. 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 resources trained and 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 which allow them to have large numbers of consultants in a relatively smaller number of applications. Consulting companies overstate their software coverage and resource specialization to their clients on a routine basis. 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 represent furthermore, the consulting company was somehow responsible for developing their skills. The consulting firms demand a significant margin on the resources even if they just met the resource a week ago.
Our risk research into software risk and 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 Software Decisions 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 will fail to point out the precise reasons as to why. Most of the advice they give and issues they highlight seem to be just nibbling around the edges of the problem. (Actually, most of them can’t because the entities that are 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 “fools gold” in the enterprise software area.
The concept is that the buyer will receive benefits through 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
This turns out, the hypothesis, and it was never anything else 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 at all in practice. Those that make the assertion have no research to support their contention. (a hint at we did perform the research, and the assertion turns 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, and it has caused many software vendors such as JDA, Sage, and Infor to perform software acquisitions in the hope of providing a full suite of products to customers, steering them to purchase other applications, often based on the software vendor which provides the ERP system. For these vendors, they see the ERP system as the pathway to achieving more monopoly power, and therefore the ability to increase their prices.
The Most Important Feature in the Software Correlated to Implementation Success
This has to lead 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 the business requirements of a customer. Still, each application should be able to win in each area on its own merits without having to rely upon 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 the fit with business requirements will result in a higher risk that the project either never goes live or that after it goes live the value it provides to the company will be minimal.
An Often Repeated Evidence-Free Assertion
The integrated suite argument, most prominently from ERP vendors is at its essence and the evidence-free assertion that is put forward by integrated suite vendors and reinforced by consulting companies who have a financial interest in repeating and companies like Gartner. They receive the most vendor income from the most significant vendors and who slant their Magic Quadrants in the direction of 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 the IT space.
IT buyers have proven extremely susceptible to misleading simplistic platitudes that are promulgated not because they are true but because they fit the financial incentives of those that promote these concepts. The most prominent IT analysts companies have proven useless in educating IT buyers on these inaccuracies because, in part, they are paid by the largest 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 of the hype people are currently exposed to now will not work out. And when I say “work out,” I don’t only mean won’t become popular — because some things can come popular, but don’t work out in that they don’t add value over what they replaced. After the enterprise resource planning system had been purchased, it started gobbling up the IT budget.
It also, and very importantly, narrowed the options of the buyer and put into place a series of false assumptions. 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 is 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 continues 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 due to the introduction of the enterprise resource planning systems in the mid-1980s. Before this time, systems that made up enterprise resource planning were sold by different vendors.
Enterprise resource planning software caused lots of consolidation, so much so that after the 1980’s 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. There was a tremendous amount of money 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 making a particular comment as to 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 to 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 was in a position to dictate much of the rest of the game.
This is at its essence anti-competitive behaviour because the enterprise resource planning company is no longer merely competing on a level playing field, but is proposing that it’s other applications be given preference because they “integrate better” with the already purchased enterprise resource planning system. Every monopolist going back since before John D Rockefeller has used control of one area, to establish control in another, most often connecting area.
Enterprise resource planning vendors used these systems to steer purchases to applications that in a freely competitive arena would have never been bought. 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. And while it did this, it established a faulty thought pattern in enterprise software decision-makers — and ERP-centric thinking is a consequence of this.
I ridiculed this way of thinking, which I likened to a medical condition in the article Do You Suffer from (ECS) – ERP-Centric Strategy?
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 largest software vendors, the consulting companies, and the IT analysts (by in 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 an endless number of conferences, articles, consulting and vendor presentations.
Based upon pretences, these systems became the queens on the chessboards of enterprise software where they promoted the sale of more software that was often acquired by the vendor. This created higher degrees of concentration in enterprise software and more lock-in and account control that 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 that 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 that are purchased from one vendor, the higher the risk to the buyer – because it means a higher likelihood of implementing weak applications. Large software vendors that have 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, which has a far more competitive application in the marketplace – that can be implemented more quickly, at lower risk, and with a higher ROI.