Doing what everyone does won't give you an advantage

‍Duping the CIO

We know that fortune favors the bold, but no bold undertaking should be done idly: we need to investigate what options exist and what ecommerce applications can actually do for you. In our meetings with clients, we learned that they have way too many choices to make and risks to take. What would a CIO do? We know decision makers often tend to favor a well-known product that seems less risky at first sight. Therefore, the choice often falls on an “industry standard”. A CIO also looks for ways to statistically prove the value of his/her IT investments and whether or not these investments serve a greater benefit to the organisation.

Before the CIO decides on the bold undertaking, management gives the CIO a deadline. At this point the CIO might not have the specifications prepared, i.e. not knowing exactly what he/she wants, but something better than the current solution. To get the ball rolling, the CIO has three paths:

1. Choose the same technology their competitor has (oftentimes a monolithic application).
2. Request information from agencies about what solution they would recommend. This approach will almost always end in the recommendation of what the agency provides as development services as well. What a surprise.
3. Launch an internal investigation that inevitably lands in front of a Gartner Magic Quadrant (which favors monolithic applications).

‍

CIOs need an unbiased approach

All three paths clearly point to the same biased preference: a monolithic solution. Why are they biased?

1. Doing the same thing as your competitor is not a competitive advantage. You’ll just have the same problems that they have, and money will be lost resolving the same issues. You won’t get ahead; you’ll likely be light years behind your competitor, since they started development on that solution much earlier than you.
2. Service providers want to sell a solution that they favor, not what is better for your needs. A Magento service provider will sell you a Magento solution, because they argue that it’s the best and can do anything you want. The same goes for Hybris, Elastic Path, etc. They don’t really care about what you want; they know these applications and that’s what they can develop for you. You’re basically already defining your options when you select the service providers to ask.
3. The Magic Quadrant is a diagram using complex multivariate statistical analysis to assess the qualitative benefits of different ecommerce solutions. It’s created by Gartner. They only investigate the mainstream solutions, often favoring the enterprise solution that can serve all generic needs, and this changes year after year. What happens if you relied on the Gartner Magic Quadrant to pick a solution, and the following year Gartner says that the solution you chose is obsolete? What do you do now? What do you tell management?
   

Using a monolith made sense in the past: we needed to “put together” a whole host of functionality in a single system because it was easier to manage. We followed a linear, conveyor-belt, Fordist and Taylorist methodology that managed software like a company. We used these old ways of thinking to plan the accounting, management and operations of our businesses, and it made sense (and in some ways it still does). Every little operational strategy was based purely on cost-efficiency and organisational models that best suited production, distribution and financial growth. We extended these ways of thinking to software. We put all our eggs in one basket, and that made software vulnerable. Thus, the old ways of working are becoming increasingly risky, since attackers know your monolith just as well as the developers who try to secure it. The old ways of working (and thinking) also make your priorities, initiatives and services predictable (if not identical to your competition).

‍

‍

Often the proponents of monolithic architecture don’t tell CIOs the cost of developing with a monolithic solution:

• Difficult to alter/upgrade: with every new function or feature you add to the application, the farther it strays from its original design, until its structure becomes something else entirely. With code so dependent on itself, it’s hard to break it down into its pieces, and side effects of improvements can become hard to isolate. The more functions and features you develop, the harder it becomes to upgrade them to a more secure state.
• Limited agility: response to customer needs is slower, and you can’t deploy to production quickly enough. Additionally, even a small alteration requires a full production redeployment. It’s harder for developers to see all effects of their change, and when multiple teams are involved, a complex release plan is required to synchronise deployments and production delivery.
• Difficult to incorporate new technologies: with the proliferation of new and improved technologies, it can be difficult to integrate them with your current, relatively static solution. This general inflexibility means that it will take longer before CIOs can implement these new technologies. And by then, the decision to use a new technology often leads to a rewrite of the better part of the whole monolith.
• Difficult to scale: monolithic applications are not easy to scale, and server and infrastructure limitations continue to tax your ecommerce solution. A CIO constantly demands functionality that has the potential to improve sales and generate leads, and if the infrastructure is not able to cope with it, the solution needs to scale. However, legacy systems are not as flexible and require complex hardware and software upgrades. With non-monolithic software, scaling can be realized much more easily using different physical or virtual servers.

What is the real cost? The cost to the customer and to the organisation’s ability to respond to consumer needs in a rapidly evolving B2B ecosystem.

Why do CIOs choose these monolithic applications anyway? The reality is that these solutions provide a package, tightly packed and ready to go! Imagine buying a gift: it’s sealed and it’s got everything you could possibly need. The question is: do you really need all that? Wouldn’t it be more cost-effective to buy only what you need at the moment and add features over time? Keep in mind: all these cool features and tools need to be patched and maintained in the coming years.

Obviously the CIO thinks that this is all the market has to offer. After all, who disagrees with the Gartner Quadrant anyway? It’s magic, after all! Well, we do!

‍

The CIO and the world beyond the Magic Quadrant

The Gartner Magic Quadrant is a fantastical depiction of bias, we argue, on the grounds that the criteria for each quadrant are based on qualitative measures that are not clearly defined or precisely explained. Here’s why the CIO shouldn’t care what’s written in the Magic Quadrant:

1. “Completeness of vision”, one of the two axes, refers, according to Gartner, to a company’s strategy, business model and overall offerings. But when seen closely, there is no delineation of these subcategories, only an overall benchmark that’s based solely on reviewer interpretation and not on actual facts.
2. Software development and technical innovations move faster than Gartner can accommodate in its quadrant. The quadrant is updated once a year, and by the time you read it, its analysis is no longer relevant.
3. Preference is given to existing solutions. It’s clear that the same names appear on the quadrant year after year: Oracle, SAP Hybris, IBM, Magento, Intershop (aka “The Big Five”). Gartner believes the Big Five have a forward-thinking resolve and are dedicated to their future success. The same is true for any other stack of technologies that produces better results than the Big Five.
4. Gartner is a research and advisory firm that relies on stable and available information. The Big Five typically provide this, while open source solutions don’t place revenue at the top of their agenda (unlike the Big Five). Thus, relying on existing data and solutions simplifies Gartner’s research approach.

The Big Five use monolithic architecture, the same architecture that we know is neither the future nor the desire of a forward-thinking CIO. A forward-thinking CIO isn’t going to simply rely on a so-called “Magic Quadrant” written by researchers who likely never implemented any of the Big Five, like we have. They don’t know the cost of implementing those solutions and the risks that a CIO needs to avoid when deciding on one of the Big Five.