Building Strategies for Mitigating Technology Transitions

Building Strategies for Mitigating Technology Transitions

Chris Evans Cloud, Enterprise, Opinion

It was interesting to see some feedback on several comments I made recently on Twitter relating to the VMware acquisition and strategies for moving away from the technology.  Rather than continue a prolonged Twitter discussion, I’ve put my thoughts here, as an attempt to structure some thinking and examine how businesses might devise a mitigation strategy that seeks to reduce dependencies on any single technology.

Background

First, it’s probably worth me explaining my background in a little more detail.  Although many people think of me as a “storage person”, over the past 35 years of my career, I’ve been what might best be described as a “consultant for hire”, working on many different aspects of technology.  I started in the mainframe world, co-founded a music start-up (which we took public), returned to consulting working on midrange (Sun, HPE, IBM) and x86 platforms, and gradually moved towards being an analyst and doing less consulting.  During that time, I have:

  • Designed, built, and implemented ½ a dozen data centres (as part of various teams).
  • Written application software, including the development and implementation of an entire suite of solutions to automate custom CD order taking and creation (single handed).
  • Written mainframe assembler, both for application and systems code.
  • Written a distributed filesystem (proof of concept) in C.
  • Written many scripting framework tools across all the major programming languages and scripting platforms. 
  • Been part of a team involved in countless transformation programmes, moving and consolidating applications either as part of new DC builds or technology refresh and consolidation.
  • Deployed, managed and de-commissioned dozens of storage arrays from all the major vendors (and others)
  • Designed, deployed, and managed many SAN fabrics.
  • Designed, deployed, and operated data protection solutions across many diverse platforms.
  • Project managed transformation and technology refresh programs.
  • Co-founded two start-ups, one in the music industry, one to implement a data mobility solution.
  • Founded or co-founded over ½ a dozen companies.
  • Provided support (including out of hours) across all technology platforms, as well as working on internal problem solving and performance management.
  • Acted as a consultant to technology vendors, providing product advice and developing consulting practices and solutions.
  • Aside from the “day job”, I’ve also written hundreds of articles for mainframe printed publications, TechWorld, TechTarget, Network Computing and others. I’ve blogged since 2003 and run Architecting IT since 2007.  I continue to run a successful podcast called Storage Unpacked
  • I’ve also occasionally presented at technology events since the mid 1990s.  I’ve worked on both the vendor and customer side of the market.

My work has taken me all over Europe, the USA and further afield.  I’ve been lucky to see many ways in which technology can be implemented.  More importantly, I’ve seen how IT teams have done things right and how they’ve sometimes gone badly wrong. 

The VMware Challenge

Enough about me, let’s talk about VMware, transformations, and lock-in.  The impending acquisition of VMware by Broadcom has sent shockwaves through the IT industry, with many opinions highlighting the positive and negatives for customers and employees.

Broadcom is acquiring VMware as it sees the company as a mature, cash-generating business that will provide ongoing revenue for many years.  The Broadcom strategy is well-known and has precedence.  The company acquired Computer Associates (CA) in 2018 in what was seen as an “unusual” acquisition.  However, CA has a long history of itself acquiring products and solutions which are generally legacy but have a long tail of customer usage.  This is usually because there are no other suitable alternatives and moving off the underlying platform is not an option. (I worked to replace many CA products at consulting gigs in the 1990s).

Broadcom followed the CA acquisition by picking up Symantec and now intends to do the same with VMware.  The parallels are obvious.  VMware has a strong business that generates cash (which we know was used to reduce Dell’s debt).  VMware customers are generally heavily invested into the vSphere platform and associated products. 

Although I’ve highlighted CA products as legacy, that’s not what I’m saying for VMware.  There is a difference, though, between growth and maintenance.  Arguably, VMware’s business is moving into a maintenance phase, as future IT growth trends towards the public cloud and/or containerisation.  For Broadcom to make $8.5 billion in revenue within three years (the company’s stated goal), either the top-line revenue needs to be increased, the bottom-line expenses need to be reduced, or both.  The expected path to this target will be to increase licensing charges, reduce the research budget and make administrative savings where “synergies” exist with divisions of Broadcom’s existing business. 

Future

Customers of VMware will have looked at the news with some trepidation.  In current times, licence price increases won’t be welcome, nor a desire for Broadcom to move customers to recurring rather than perpetual licence agreements where large estates are in “perpetual” mode. 

The scenario of increased costs must be balanced against two metrics – the perceived increase in value that comes with the change in cost structure (if any) and the cost of refactoring or rewriting applications on a new platform.  In many cases, do nothing might be the right answer, because new features/functionality can be exploited – depending on how much R&D the new VMware intends to do.  Alternatively, the cost of transformation to another platform may be high and difficult to justify, especially finding someone within the business willing to pay.  We’ll come back to this point again in a moment.

Diversity

Most businesses of any longevity or size will have a wide diversity of technology.  Some of the IT departments I’ve worked in claim (jokingly) to have one of everything (and probably do).  Diversity in technology happens because strategies come and go.  CIO/CTOs like to place their stamp on things, so in many instances transformations or new strategies get established with regime changes. 

Businesses get acquired and bring their technology along with them.  Invariably, the acquirer and acquiree will have differing standards and processes in everything from application design downwards through database choices, platform choices, operational processes, and hardware vendors.  I’ve worked on many projects to bring multiple (initially separate) organisations in line with consistent IT standards. These can be interesting pieces of work where both sides believe they have the best technology strategy.

Lock-in

IT departments and business units get locked into specific technologies for lots of reasons.  I’ve seen technology choices based on the “favourite” company of the IT manager or CTO.  I’ve seen platform choices based on curtailing legal action.  I’ve also seen technology choices dictated by 3rd party vendors of connected hardware like medical scanners and other healthcare equipment. 

Skills play another important factor.  After many years working with one set of technologies, staff may be reluctant to reskill, or at best take months or years to be fully competent with a new solution.  Reskilling isn’t just about learning to use new platforms; it also encompasses building enough knowledge to create best practices.  Of course, on the flip side, staying on legacy technologies can make it difficult to find skilled staff, as the incumbents retire or move on. 

Infection Point

Generally, IT strategy continues on a straight line until an infection point is reached.  Sometimes a change is driven by people and politics (as above), sometimes by new technology or cost.  Everyone has probably worked in an IT organisation with “skunkworks” projects.  These teams try out new technology, develop processes and generally work on understanding the potential value of new technology to the business.  Remember, every piece of technology should be adopted by a business to either reduce costs (improve efficiency) or gain a business advantage.  Everything else is a vanity project.

Choices

So how do the points raised in this discussion reflect on VMware and strategy?  Businesses have three choices:

Stay on VMware technology.  In the short term, VMware may change very little, or may change a lot.  It’s a massive unknown at this point.  VMware may experience a mass exodus of key staff members or may choose to cut staff numbers quickly.  We simply don’t know.  In a worst-case scenario, product costs go up, development stops, and support gets worse.  In the best case, nothing changes. 

IT organisations must keep an ear to the ground, communicate with their sales channels and try to gain an understanding of what might happen going forward.  At the same time, it makes sense to look at the depth of dependency on VMware and start initial planning to choose an alternative platform.

Migrate to another hypervisor.  The simplest part of the VMware ecosystem is the hypervisor.  The process of migrating existing workloads to another platform is relatively easy.  There are many tools in place to move to Nutanix AHV, Hyper-V or Scale Computing.  However, the hypervisor is only one small part of the ecosystem.  In practice, most of the VMware investment will be in tools and supporting services.  Businesses will have built infrastructure dependencies on features like NSX, vSAN and the vRealize suite.  It can be very challenging to understand the degree of dependency, as IT has a history of poor documentation. 

It’s worth planning a potential move to another ecosystem.  This includes doing initial feature/functionality comparisons, cost comparisons and the associated skills matrix development.  Partial mitigations might make sense, for example, unpicking dependency on VMware-integrated storage or transferring less critical workloads to other solutions.  A short-term investment in some hardware or services may prove valuable over the long term.

Pivot.  The third option is to pivot entirely and choose a completely different strategy, such as wholesale migration to the public cloud or implementing a hybrid approach.  A big change in technology will introduce additional risks but could already be in place in a limited fashion somewhere within the business.  The change of VMware status might simply be an incentive to accelerate the transition.  A pivot to the public cloud will take longer and will normally involve more training and investment.  Applications may need to be rewritten or refactored for the new platform.  New cost models for internal charging will probably be needed, as businesses learn to pay in an opex, rather than capex fashion – depending on the level of service catalogue already in place.

Remember, every piece of technology should be adopted by a business to either reduce costs (improve efficiency) or gain a business advantage.  Everything else is a vanity project.

It Depends

It’s clear that creating hard and fast rules for all businesses is almost impossible.  IT is notorious for the “it depends” message, because every business is unique and has a diverse set of technologies and requirements.  As such, making general recommendations is almost impossible.  However, we can say IT organisations should:

  • Have a good understanding of their IT infrastructure.  Understand the technology in use, the growth profile, the costs and commitment in licensing and hardware from both a depreciation and amortisation perspective (servers & storage will depreciate, whereas the cost of developing a scripting solution may be amortised, for example).
  • Have a strong service-based internal delivery model, with mature service catalogues.  If this doesn’t exist within the business, then many other challenges will arise, especially with internal LOBs that feel they’ve “paid” for pieces of infrastructure.
  • Build a model of risk and lock-in, versus alternatives.  Whilst our discussion looks at VMware, businesses could become as easily locked into the public cloud as an on-premises solution.  There’s a fine balance to make between building a multi-vendor strategy and using unique technology from a single provider.  This decision becomes one of risk management – or risk documentation. 
  • Build strong internal relationships with business teams.  In my experience, having good connections into the business always helped mitigate problems and gain an insight into future application development plans.  Internal LOBs don’t like unexpected costs or change (meaning risk).

Overall, an IT organisation needs a plan, with a vision that looks as far forward as practical.  Exactly how far is (as usual) a question that depends on appetite for risk, cost available to the IT teams and requirements of the business.

The Architect’s View®

Ten years from now the technology landscape will be very different from today (look ten years back to see how things change).  VMware will be a transformed company, with only the name remaining the same.  When the VMware news was announced, my immediate thought was to imagine the long-term impact of VMware in different hands.  It’s certain that Broadcom wants to increase costs and reduce overheads.  But only those customers with massive investment in VMware technology will need to worry about the risk resulting from change of ownership. 

For the rest of the customer base, simply setting a different path (like cloud) and using attrition to whittle down the dependency on VMware, might be the best strategy. 

Very few (if any) businesses of any size can change their entire IT solutions within a few years.  Instead, the general approach is to adopt a new long-term strategy, move applications to the new solutions through rewrites or re-platforming.  Then the remainder of the legacy infrastructure is mopped up through remediation programmes.  At this point, the dependency on a legacy technology is vastly diminished. 

I see this as the route for most VMware customers that want to move away from vSphere and associated technologies.  After all, it’s been a recognised process since the days of the mainframe and likely to be the same for decades to come.    

Copyright (c) 2007-2022 – Post #13e5 – Brookend Ltd, first published on https://www.architecting.it/blog, do not reproduce without permission.