For those that have been planning IT architectures long enough, we can all remember the days. We used to look at the hottest technologies on Gartner’s Quadrant, and that was a reference. I no longer believe that. Times have changed, and so has the market. Here are 10 reasons why a best-of-breed approach can breed catastrophe only.
10. Contract Management
Some larger IT departments need to have specialized resources to manage vendors. How much money is your company spending to ensure that the contracts are adequately taken care of? If you have 30 technologies deployed, are you sure they are used to their full potential? Or are you using them like most people use MS Word, 10% of its potential? I once ran the numbers for a ministry, and if we went best-of-breed, they were looking at 45 contracts. If they were willing to focus on interoperability and ecosystems, we were down to 2. I did this not by selecting solutions from anywhere but from the leadership quadrant. Just not systematically choosing the leader.
9. Recurring costs
Consider the operations costs of all those solutions; what do you see? I see that for a majority of companies, most of their budget is used to keep the lights on. What does that mean? Keep the systems deployed running to pay for all those recurring costs. What does it mean for your business? The more technologies, the less oxygen your IT teams have. The less they can innovate.
8. Cybersecurity favours simplicity
Here’s a great question: How can you secure something which you don’t understand? We can dig this deeper; how can you follow an attack with just a partial view of your systems? Are some of those systems outsourced, meaning not even under your team’s management?
That’s precisely my point. The foundations of cybersecurity require that awareness of your various systems and data.
To have visibility into the various systems, they need to be journalized. Can you imagine the complexity of bringing all different logs into a unified view? And after all this work: make sense of what it shows. Complexity is killing your cybersecurity mojo.
7. Data residency, compliance and audits requirements
All organizations to differentiate themselves from the competition will want to be audited. Might it be to be ISO certified, demonstrate the solidity of its security, or even show it’s well managed?
Also, depending on your market, you may need to be compliant. No matter the market, it all has rules, and rules need to be validated. If your data is spread through numerous systems, how do you make sense of it? How do you expose it to the said auditors?
Even more common are now the rules that require your systems and data to stay in the country. So, all those cloud services coming in from left and right, do you know where the data resides?
6. Vendor relationship depth
I would like to ask the following: do you believe that long, profound relationships are born out of Tinder?
Then why are you treating vendors relations as if they were single-use transactions?
The best partnerships I have built in my career were based on respect, trust and transparency. If you are making it for the long term, the relationship should reflect this.
The lowest price will most likely result in the poorest relation—a mutually destructive relationship with no value-added in the end.
5. Integration nightmares
Have you ever heard of fitting square pegs into round holes?
In technology, this happens every day, especially with diverse vendors. There are minimum standards and a ton of proprietary models.
What does that mean to you?
- It means that you can’t easily integrate the data into your monitoring systems
- It means that the security model will not have all the data you need to hunt threats on it
- It means it will require a different security model
- It means it will not be able to be fully backed up by your corporate systems. Unless an add-on exists, which you’ll need to purchase
And so on.
4. Diverging requirements
Let’s say you are a Microsoft shop and have a normalized database backend that runs on SQL Server.
What happens when another division goes to the market for an ERP, and the winner requires Oracle? The following day, you end up with two backend databases that you need to maintain, backup, and operate.
Oh, and need I say, you now need an Oracle DBA because you’ll have critical data on this platform. Your SQL Server DBA may be excellent, but he doesn’t speak Oracle.
And that’s just one example. It can be diverging operating systems, platforms, browsers, name it.
3. Incompatibilities sprout instabilities
When bringing in systems that are not compatible in the fields, it brews problems.
Let’s take the same case as before, a Microsoft shop with a normalized desktop image. You bring in a new mission system that is not compatible with Windows. You will then need to deploy a client onto those desktops that come from a foreign ecosystem.
What do you think will happen? It will destabilize the desktop environment. Whether in the short or long term, it will come in and pollute the ecosystem.
One morning, out of nowhere, an anomaly will appear on your desktops. The same ones that worked great the week before, for no apparent reasons, start to misbehave.
2. Building without a plan lacks harmony
Have you ever built a house or even an IKEA piece of furniture without a plan?
It’s like someone gifts you the Millennium Falcon in 3d puzzle but took out the instructions.
Then let me ask you this: Why are you trying to build it without proper blueprints.
When I look at some IT environment, it seems like a thrown-together catalogue. Everything, including the kitchen sink, is custom.
How are we supposed to build harmony out of this?
There are three factors to this problem.
- The best-of-breed approach
- The lowest bidder approach
- I could also add the fact that all vendors must be treated equally.
That’s a great law of free trade, but it makes for poor IT infrastructure.
1. Talent shortage
IT groups within companies aren’t able to hire any more. The more technologies, the more people you need. There is no way a normal human being will be able to master 30 technologies.
“Expertise is like jam; the more you spread it, the thinner it gets.”
Then why are we asking our IT operations teams to do it?
You cannot retain talent by asking them to maintain 30 technologies, especially if they are going towards obsolescence.
Would you consider putting Novell 4.11 in your resume today? Would you want a job offer that asked about your Novell talents? I rest my case.
But what about vendor lock?
What about it? You are already locking yourself in with dozens of vendors. The only difference is that you are spreading your favours to many.
Are you going to stop yourself from getting married because there are other women in the world?
In the end, it becomes a choice, and it has to be an operational one. For all the reasons mentioned above, you need to start your modernization efforts with a plan, a plan that will bring harmony to your systems. That will drastically reduce your instabilities and make your systems more secured. It will also be simpler to manage as your team will have only a few manufacturers to master. A single language to learn.
Conclusion
The past does not equal the future, and I sincerely do believe that. But you also need to be smart and learn from the future.
You need to modernize and transform your IT infrastructure, and to do it, you should apply the lessons-learned rule. And please, do not repeat the same mistakes.
Consider the following: what if you put in place rules and principles that protect you. What if you could ensure that your environment stays normalized for at least the next 5-10 years. What if you could enhance the life of your IT operations team by training them on exciting technologies. By providing them with an exciting project. By empowering them to make a difference.
I am excited to see what kind of comments and feedbacks this article will bring.
And yes, I am aware that I am going against dogma, but even dogma must learn, grow and change.
Have a great week.