Twenty-five years ago, Charles Morris and Charles Ferguson published a paper titled “How Architecture Wins Technology Wars” in Harvard Business Review. While many of the examples in the article are hardware-oriented and outdated, the key findings and insights are not. In fact, the article’s key findings offer important insights for the competitive dynamics of the SCM software market 25 years later.
Over the course of the past 25 years, the fragmented nature of SCM problems has led to highly-specialized software solutions with specialized architectures. Thus, there have been no clear architecturally-driven winners when you look at the space as a whole. However, over the course of the past five years, interesting developments portend architecturally-driven winners and losers in certain areas of the fragmented market. Morris’s and Ferguson’s paper may offer some clues to emerging market dynamics.
With that in mind, let’s take a look at the five key points of “How Architecture Wins Technology Wars” and apply them to the market for SCM software.
1. Good products are not enough.
Architecture is increasingly important in a company’s decision to choose one software solution versus another. Functional parity or near-functional parity has been achieved in many areas of the SCM software market. (And, of course, PowerPoint parity has been around for years).
Thus, even if you are a narrow niche vendor (of which there are many), CIOs want to know that you have an architecture that allows them to plug you in and plug you out as business dynamics change. In the annals of enterprise software, this has proven very difficult. People in the software and other businesses talk about the “stickiness” of a product. This is a codeword for the barriers necessary to switch to another solution. In any industry, software or otherwise, when the barriers (or pain) associated with switching are high, and your product is essential to the business, then you have a very sticky product and you have some power in the vendor-customer relationship. If the barrier is because users love your product, then that is a very good barrier indeed. If the customer is indifferent about your product but switching would be like organ transplant surgery, this is a still a good barrier for the vendor but not necessarily for the customer. In this case, if you are the provider, you know you have a long runway before switching occurs. That said, even if the customer cannot live without your product but at the same time does not like to deal with you or your product, eventually they will try to find a way to switch. I am sure you can think of many situations like this.
2. Implementation matters.
The Morris and Ferguson paper discusses this in the context of hardware manufacturing. (Here, implementation does not refer to implementing software, but rather how technology and architecture have been implemented in the software design). In the context of software, it means that two different software companies can take the same technologies, or technological techniques, and implement them in completely different ways.
Too many enterprise software purchase decisions are based on check-the-box analyses to determine whether a given solution provider does or does not have a certain technology. Most providers will have the technology, thus check-the-box analyses result in razor-thin margins of victory for one provider over the other. In the meantime, under the covers, the margin may be significant and only discovered during the design or deployment phases.
What is very important is how technology has been implemented to solve certain problem sets, how clean and elegant the design is, and how flexible the underlying architecture is. Let’s take in-memory computing, for example. Most companies will check the box on having it. However, the most important thing is how they have employed in-memory computing to solve the problem at hand. Is the design new, clean, elegant, and flexible, or is it monolithically tied to use cases?
3. Successful architectures are proprietary, but open.
SCM software is inherently proprietary, with each solution provider having its own data model, algorithms, and user experiences. This does not mean, however, that they are necessarily “closed” architectures. Many have ways by which data and functions can be easily accessed from other software programs.
Furthermore, the “app economy” and “API economy” are slowly seeping into SCM software. This allows the software provider and third-parties to more easily provide extensions in a controlled way. If software has not been explicitly designed to support APIs, retrofitting can be a large, labor-intensive rewiring effort (an entire area of the enterprise software market has been built up around this problem).
Older architectures were driven around physical databases in which data was monolithically tied to the application. In-memory-computing-based architectures are inherently API-based, since accessing data must be done through processes that are only accessed via APIs. Of course, new solution providers typically have no issues here, with many of them built from the ground up for the cloud, using microservices- and API-based approaches with explicit ways to plug into existing enterprise application environments and explicitly-defined ways by which ecosystem partners can consume APIs to add value for enterprise customers.
4. General-purpose architectures absorb special-purpose solutions.
The SCM enterprise application space has historically been characterized by built-for-purpose solutions highly focused on individual problem areas. Demand planning, supply planning, S&OP, scheduling, transportation, and warehouse solutions were all built on different architectures. Solutions are starting to emerge that have architectures that are more “stretchable” across different problem sets. Previously, companies had to pay a functional-depth penalty when employing such a stretchable architecture. In other words, the architecture provided the ability to solve multiple SCM problems, but the depth to which it could solve any individual problem was limited; there was a trade-off between depth and breadth. For certain problem sets, these trade-offs have now been reduced to zero.
Anaplan, Kinaxis, and Llamasoft are examples of companies that have “stretchable” architectures that provide the ability to solve multiple planning problem sets with the same underlying architecture. This “stretchability” greatly benefits both the end-user company and the solution provider. Single architecture solutions reduce integration, support, and training costs for user companies. For software providers, they greatly reduce the need for specialized consulting, sales, presales, training, and development resources, leading to significantly higher operating margins. In other words, they provide significant operating leverage for both user companies and solution providers, not to mention the ecosystem that supports both.
While this stretchability has started to enter the planning side of the SCM market, it has not yet arrived for the execution side; for example, multiple architectures still exist for transportation, warehousing, and order management and while providers have done some level of integration, the underlying architectures of the individual areas are still fundamentally different.
5. Low-end systems swallow high-end systems.
This point is essentially the same as Clay Christensen's disruption theory, as expressed in The Innovator’s Dilemma and subsequent work. This posits that most markets evolve in such a way that incumbent players evolve over time to solving more and more complex problems, while new players focus on simpler problems, differentiated by lower total-cost-of-ownership, or ease of use, or ease of doing business. Over time, however, the lower-end solutions evolve to take on ever greater capabilities but do so in a much more appealing way, eventually “disrupting” the established players. This dynamic is playing out in many areas of the SCM software space right now.
This point is also a corollary to point number 4. A general-purpose, stretchable architecture may start out providing less-than-necessary depth of solutions in any given area, but gradually over time, as depth is added to the solutions, these lower-end solutions start to eat the lunch of the higher-end solutions. The classic example of this is the iPhone, which has a general-purpose architecture that provides the ability to perform myriad functions, including internet connection, phone, music player, and camera (not to mention the functions of the innumerable apps, which is good example of point 3 – successful architectures are proprietary, but open). In the beginning, the depth to which the iPhone solved any one problem was limited, but over time each function has become deeper such that no one any longer carries around multiple devices when one can do them all.
A number of these points are discussed in my recently-published Supply Chain Quarterly paper titled “10 technologies that will reshape SCM software.” This paper offers a high-level blueprint for the future of SCM software solutions. These points will also be covered by Worldlocity in more detailed analysis of the SCM software market forthcoming later in 2018.