‍Duping the CIO

We know that fortune favors the bold, but every bold undertaking shouldn’t 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 make a decision that favors a well known product that is less risky on the first sight. Therefore, the choice often leads to 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 their current solution. To get the ball rolling, the CIO has three paths before him/her:

1. Choose the same technology their competitor has (oftentimes a monolith 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 a monolith application).

‍

CIOs need an unbiased approach

All three paths clearly point to a biased preference by all three parties: a monolith 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’ve started development on that solution for much longer than you have).
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 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 multivariate complex statistical analysis to assess the qualitative benefits of different ecommerce solutions. It’s created by the Gartner Institute. They only investigate the mainstream solutions, often they favor the enterprise solution that can serve all generic needs and this changes year after year. Once you pick a solution, and you relied on the Gartner Magic Quadrant to make your decision, and the Gartner chart is updated the following year, what happens when they say that the solution you’ve chosen last year 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 held a linear, conveyor-belt, Fordist and Taylorist methodology that managed software like a company. We used these old ways of thinking to strategise our accounting, management and operational needs of our businesses and it made sense (and in some ways it still does). Not only was every little operational strategy purely based 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 your 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 these proponents of monolith architecture don’t tell CIOs the cost of developing with a monolithic solution:

• Difficult to alter/upgrade: with every new function or feature you develop to the application, the farther it strays away from its original design and its structure becomes something else entirely. With code appearing so dependent from one another, it’s hard to distill it to its pieces and side-effects of improvements can become hard to isolate. With every movement towards functionality and feature development, the harder it will become to upgrade those functions to a more secure state.
• Limited agility: response to customer needs is slower, you can’t deploy to production quick 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 with your current, relatively static solution. This general inflexibility means that it will take longer before CIOs can realise the implementation of 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 so easy to scale and server and infrastructure limitations would continue to tax your ecommerce solution. A CIO constantly demands functionality that have the potential to improve sales and generate leads and if the infrastructure is not able to cope with it, the solution would need to scale. However, legacy systems are not as flexible and require complex hardware and software upgrades. With non-monolithic software, scaling can be much easier realized using different physical or virtual servers.

What is the real cost? The cost to the customer and 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 in that moment and increase features over time?  You should keep in mind: all these cool features and tools need to be patched and maintained in the next years.

Obviously the CIO thinks that this is all that 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 is based on qualitative measures that are not so 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 quadrants, refers to, according to Gartner, refers to a company’s strategy, business model, and overall offerings, but when seen closely, they do not offer a delineation of these subcategories but rather an overall benchmark that’s based solely on reviewer interpretation and not actual facts.
2. Software development and technical innovations move faster than the 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 given to existing solutions. It’s clear that those on the quadrant are named year after year: Oracle, SAP Hybris, IBM, Magento, Intershop (aka “The Big Five”). They think that the Big Five have a forward-thinking resolve, and are dedicated in their future success. The same is true for any other stack of technologies that produce better results than the Big Five.
4. Gartner is a research think tank that relies on stable and available information. The Big Five typically have these, while open source solutions don’t place revenue on the top of their agenda (like 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 are not the future, or desire of a forward-thinking CIO. A future 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 making a decision towards the Big Five.