Can we reach the promised land of tool rationalization, or is this a never-ending struggle? Find out in this latest installment of The CTO Perspective with BigPanda CTO Elik Eizenberg.

Read the skinny for a brief summary, then either lean back and watch the interview, or if you prefer to continue reading, take a few minutes to read the transcript. It’s been lightly edited to make it easy for you to consume it. Enjoy!

 

---

The Skinny

It’s on the agenda of almost every CIO, COO and CFO, and sounds like a great idea in general: tool rationalization, often trying to standardize on top of a single vendor. It can reduce costs and provide a streamlined IT Ops process through data consistency, a single pane of glass and a single source of action. But experience shows that it’s not a “one-off” project with a final destination, but rather a long – and often never-ending process, where conflicting motivations create a seesaw between consolidation and specialization. 

While management strives to rationalize for the reasons just mentioned, innovation and technology migration drive specialization: With new possibilities come new, specialized vendors and tools that are the choice of the engineers doing the work. Additionally, the growing trend of M&As means that different IT operations (with different tools and processes) are often joined together under the same leadership – creating instant fragmentation. 

This does not mean we should give up trying to consolidate. We simply need to understand that consolidation is an ongoing, constant state of transition – and manage it as best we can, balancing the benefits of both consolidation and specialization in parallel. How? Watch the interview to find out.

 

---

The Interview

 

---

The Transcript

Yoram: Hello and welcome to the CTO Perspective, where we discuss unique perspectives about the most current issues in IT operations. And here today to speak with us is, once again, Elik Eizenberg, Chief Technology Officer and co-founder at BigPanda. Hi, Elik.

Elik: Hi Yoram, great to be here again.

Yoram: Always great talking to you. I really enjoy conversations. Today we’ll be talking about a topic that actually surprised me a bit when we first discussed it. And that is the reality behind the so-called “promised land” of tool rationalization. It’s top of mind for CIOs, CFOs, COOs everywhere, because it supposedly allows you to reduce costs and streamline your IT operations. But experience shows there is no end state of tool rationalization. There is no reachable promised land. It’s actually an ongoing process. Somewhat never-ending, isn’t it?

Elik: Exactly. Some problems in IT are meant to be solved. Some problems are meant to be managed. For better or for worse, this is one of those problems that you just have to manage. It’s not a problem you can really solve.

Yoram: When we talked about it, you mentioned that you can easily see it’s not only in IT operations, it’s everywhere. For example – if we’re talking about collaboration, there’s always the issue of “do I use everything that’s Microsoft or do I use specialized tools”, right?

Elik: Yes. If I’m a big enterprise, I can say: “Hey, I’m going to be a Microsoft shop and I can use Microsoft for all things collaboration. I can use it for emails, I can use it for office, for file storage, I can use it for ticketing. I can use it for so many purposes”. But then when you talk to every single enterprise out there, even ones that have selected Microsoft as their vendor of choice, you see a lot of JIRA, and you see a lot of Trello, and you see a lot of Slack and Zoom and other vendors around collaboration. All that just proves the point that even if you make this directional choice to standardize on top of one vendor, it’s not really something that’s that easy to convert into reality.

Yoram: And it’s the same thing in IT operations. We see the same thing across the board.

Elik: Yes. In IT operations, traditionally people said “let’s be an HP shop, let’s be an IBM shop”. But, fast forward to today, show me one company that really uses just one of these vendors for their entire IT operations stack. Obviously, that’s not a reality at all.

Yoram: And why is that? It’s always the leading marketing messaging: single pane of glass, one vendor etc. And obviously the reasons for doing that are there. But why is the reality different? Why do these conflicting forces exist, forces that actually create a seesaw between the two states of consolidation versus specialization?

Elik: I think rationalization versus specialization, or versus fragmentation, is a situation where you have two opposing forces. Both of them exist for very good reasons, neither is actually right or wrong.

On the one hand, if you want to consolidate, what’s driving you is probably the need to reduce costs. A certain drive to create more consistency in your processes and your data sets. If you are fragmenting and creating more specialization, there are normally three different aspects to that:

Number one, it’s around developer autonomy. One of the main things we learned in the last decade is that if you want to drive better velocity in development, if you want to drive better innovation, developer autonomy is probably the foundation for all of that. You want to give developers the ability to make their own choices. And perhaps an unfortunate side effect of that autonomy is that developers choose their own tools and that creates more fragmentation. So that was number one.

Yoram: Just on that point: so management might want to consolidate for cost’s sake, or for ease of use or for standardization. Let’s try to do everything with this vendor’s tools. But the people in the field doing the actual work say “Hey, things are moving. Here are all these new tools. We really want to use them because we can be more innovative. We can move faster”. And so they influence the organization to purchase that tool as well, or to work that way as well.

Elik: Exactly. If I am in a development team building an application in Java, and there’s another developer in another team building an application in, say, Node.js, we might find that different monitoring tools would serve each of us better in each one of these different environments.

As a manger, if I allow these developers to have more autonomy, the flip is the fact that they’re going to have two different monitoring tools. Each one is better adapted to solving the respective problem.

That was number one. Number two is M&A. If you look at the trend line over the last 30, 40 years, you’ll see that M&A activity, the number of deals happening around M&A, is accelerating. In the last decade we have seen an explosion in the number of M&A deals. And what happens to a bigger enterprise that acquires a new company is that essentially they inherit the entire tool stack of that company. Now, to consolidate all the tools of that acquired company can easily take you five years, even if you’re very much focused on that. So more M&A activity essentially means more fragmentation for most enterprises. That is number two.

Number three is actually a good thing. Companies are migrating to new tech stocks. They’re migrating to the cloud. They’re adopting container technology, Kubernetes. They’re adopting serverless infrastructure. And who knows what will come next.

When a new technology comes along, it often takes a long time for the traditional vendors to adapt to them. So you might have a vendor of choice that is your standard tool for monitoring your traditional stack. But then it might take them five years to catch up with container technology.

What do you do during that gap time? During those five years? You now have to buy a new tool that is specializing in container monitoring. So that is one more aspect that is driving companies towards more fragmentation and specialization.

Yoram: So if I look at the common denominator of the three things that are driving specialization or fragmentation, depending on which side of the coin you’re looking at, it’s actually a good thing: it’s innovation. If you want to move fast, if you want to adopt new technologies, if you want to acquire companies and merge them into your existing offering, you eventually will have to use new, specialized tools that are not part of your monolith stack.

Elik: I think that’s a great observation.

I think what happens often is that when companies are more focused around cost reduction and introducing efficiency, that’s where consolidation and rationalisation become top of mind. But then in times when they are actually more focused on innovation, on introducing new business lines and new new applications, that’s when companies are actually more focused on fragmentation and specialization.

And that’s one of the reasons why we see that seesaw that you described earlier.

Yoram: It sounds a bit tiring, doesn’t it? You’re going into a process that you think will eventually end, then suddenly you realize that this is a never ending process, a never ending seesaw. So what do you do? Do you just give up trying?

Elik: No, certainly not. I think a company that doesn’t attempt rationalisation is essentially attempting suicide. I think that in the end, over-fragmentation, over-specialization can kill any IT organization. You have to rationalize, but you also have to realize that you will never reach that promised land. I like to give the metaphor of taking care of yourself. If you eat healthy, that doesn’t guarantee that you will be healthy forever and live forever. But if you don’t eat healthy, then you’re going to pay for it very quickly. So likewise, I think that with IT operations you have to think about consolidation, rationalisation, but you also have to realize it’s an ongoing thing.

Yoram: Right. It’s sort of like a one-off diet versus living healthy. It’s not a diet, you’re living healthy.

Elik: Exactly. And unfortunately, I think some IT Ops leaders have this idea that they can, in a very focused fashion, replace their entire tool stack A to Z with one vendor. And the day after it will be amazing. But, you know, that day after never arrives. You have to take a very disciplined, long term view on rationalisation, consolidation. You have to enable the forces we discussed around specialization, and developer autonomy, and M&A and all that we discussed, but at the same time thrive to be more consolidated and rationalized in your stack.

Yoram: So what’s the recipe for healthy living? How do you keep that ongoing process and manage it as you seesaw between the two?

Elik: One: embrace the state. Don’t seek to be at that promised land, embrace this in-transition state, there’s no other way. It’s just the fact of life in IT operations. That is number one. Number two: You have so many tools, and as we just discussed, this is going to be a long term state. So you have to put in place some abstraction layer on top of that, that would take all of the data from the different tools, consolidate them into one place, correlate them together, and service this single point of action, single point of engagement on top of that.

Once you have that abstraction layer, you have more control around which way you lean. You can lean more towards specialization some of the time, and more towards rationalization in other times.

Yoram: And I’m assuming that’s one of the philosophies behind BigPanda’s event correlation and automation platform.

Elik: Yes, that’s the premise of BigPanda. Essentially, embracing this best of breed world where you have so many different tools, putting in place that abstraction layer and powering that using AI technology, so it’s not hard to maintain. So it can work with all the different heterogeneous data sources in one place. And once you have a tool like BigPanda, what we see with many of our customers, is that it actually makes it much easier to decide which way you lean. It makes it easier to rationalize, it makes it easier to specialize, because now you have that one layer that enables all of that.

Yoram: Do customers actually talk to BigPanda about this? Are they aware of this, that this is what it allows them to do?

Yoram: Yes. I think the main reason people would acquire a BigPanda, is because they have a lot of data coming from many different tools, and they want that data to be enriched and correlated. But once you put that in place, you start asking yourself – what is the high level problem this is solving for me? And one of the main hi-level problems is that of tool fragmentation.

Yoram: Cool. I think this would be a great place to stop. I want to thank you so much for taking the time to speak with me.

Elik: Thank you so much. This was great.

Yoram: And if you want to hear more CTO perspectives or learn about the BigPanda platform, please visit us at bigpanda.io. I’ll see you next time.