Monthly Archives: June 2016

Modernization or Transformation: Which Is The Right IT Fix For Your Business?

Much of IT terminology is often misused and misapplied. Modernization and transformation are two such terms. They are often used interchangeably even though they mean different things and have very different connotations. Indeed, it is somewhat safe to assume that in IT any transformative effort is likely to also have a modernizing effect, and thus, we can see these as levels of improvement efforts. However, many businesses are being led to believe if they don’t transform now they risk becoming irrelevant when they would be equally well-off to simply modernize existing IT services saving millions over transformation.

I often witness solution architects using the term transformation with regard to their designs, and upon review I see that the solution doesn’t affect how the IT organization is operating. Ultimately, they have new tools and modern capabilities, but the same “towers” that are there now remain in tact in the to-be architecture. In these cases, I question the architect, “where is the transformation?” The transformation should result in a fundamentally different working organization post-transformation than when it started, otherwise, it’s simply a modernization effort.

To be clear, there’s nothing wrong with a modernization approach if the business is achieving it’s goals with the current IT systems and processes. I’m working with one such client right now that is struggling with service management quality issues. We don’t need to transform the client’s data center environment to succeed, we simply need to modernize and consolidate some of the tools and approaches in order to incorporate more automation and more predictive monitoring. Alternatively, I asked Tim Crawford, CEO, AVOA, and well-respected CIO advisor, to provide an early review of this blog to wit he pointed out that it’s also important not to adopt a mantra of modernize when transformation is required or to avoid the complexity that transformation entails. That is, all too often, IT organizations use modernization as a replacement for undergoing a longer and more expensive transformational effort meanwhile the cycle of deterioration of their systems continues.

A great analogy that captures this home renovations. If the structure of the house is sound, but the style of the home is dated, then modernization efforts will update the look of the home without replacing critical infrastructure. For example, replace carpets with laminates, update kitchen and bath with new appliances and fixtures, and provide a new coat of paint. Essentially, the home space may be more maintainable and support a simplified lifestyle, but the flow and layout are still same.

In contrast, transformation incurs changing the physical structure of the home. Perhaps tearing out a wall to enlarge a living space, adding an extension or finishing an unfinished space. In each of these examples you’re changing the use and flow for how the house is lived in.

There are extreme variation in costs between these two approaches. Modernizing a home can be done for a fraction of the cost for a transformative effort, while still providing great enhancements to the living situation. And, the same is mostly true with regard to delivering IT services. For example, if you provide compute infrastructure on an application-by-application basis and you switch to cloud computing, you are undergoing a transformative approach, however, if you are already using virtualization software and you move to cloud, the way you think about resource management, governance, deployment, etc. all remain fairly similar, but there may be a need to learn new tools to support these processes.

So, when is transformation required over modernization? When change becomes too high of a risk, then modernization is no longer an option. Many businesses are caught in this pattern right now where they’d like to be more agile and responsive to business requirements, however, are limited by a multitude of factors that unknowingly work together to lock IT in this state of immovability. Examples of these factors include:

  • A culture of fear to contribute (or keeping your head down)
  • Failure results in severe penalization
  • Loss of too much tribal knowledge with no documentation
  • Year over year reductions in IT budgets
  • Business stopped paying annual maintenance on software and/or running software versions that are no longer supported by vendor
  • Forced to extend end of life for hardware beyond reasonable limits
  • Little to no investment in training and/or modern IT skilled individuals

While many academically talk about undergoing IT transformation or are one of the small percentage of inspirational success stories, there are tens, if not hundreds, of thousands of businesses that live this existence everyday. To make matters worse, the executives of these businesses are now being told by the market that they need to “digitally transform” or they may be gone in ten years. In turn this pressure to transform is then cast upon the already immovable IT organization.

In these cases, modernization should be considered “putting lipstick on a pig.” The key business processes and underlying systems of record have become so complex and difficult to change that changes are enacted usually only once annually and the period for actual development on these systems is shortened significantly due to the need to ensure thorough testing.

One may wonder, couldn’t these businesses institute a parallel transformation effort? Sure, which is from where recommendations, such as Gartner’s Bi-modal strategy, emanate. However, I view Bi-modal strategies as an approach to take when between a proverbial rock and a hard place. They are required because nothing else will work given the current operating environment. Moreover, it would require that someone be empowered to lead a parallel effort, which is unlikely given the current conditions. Unfortunately, for many of these businesses, they will be required to have a “rock bottom” moment as motivating event to invest in transformation.

If Everything is DevOps, Then Nothing is DevOps

Tom Healy of Jama Software published a blog entry entitled, “DevOps is Dead, Long Live DevOps” as did Andrey Akselrod and also Nir Cohen. Interestingly, I find these pieces to have related concerns but different reasoning. Clearly, there are naysayers within the IT community that don’t buy into the DevOps fanboi messaging; and that’s okay!

Personally, I believe the IT industry is notorious for taking a good concept, like DevOps, and twisting and contorting it until it fits a consistent model that highlights tooling (product) over outcomes, specialization over generalization, and engineering prowess over simplification. We have seen this same pattern occur with Java, Service Oriented Architecture (SOA), Cloud Computing, and now we see it with DevOps. Ultimately, the downside negative impact is that we lose the support and interest of business as these efforts become more and more technical in nature. Moreover, it feeds an ever increasing cost of operations for IT and minimizes the available pool of candidates for jobs.

DevOps is already well-along the path of being molded to the model outlined above. From the outset has been plagued with dissention that embodies my aforementioned characteristics. The first major point of dissention was about the viability of Enterprise DevOps—was the nuances about the needs of DevOps in the enterprise different than those of startups. Debate is good, when it helps to hone a new concept for the benefit of all. But, this was not a healthy debate with much of it devolving into personal attacks on individuals’ credibility as a means of one perspective being perceived as “the right way!”

As Nir points out in his presentation, linked above, the label DevOps is being attached arbitrarily to roles, jobs, tools, etc. Again, if everything is DevOps, then nothing is DevOps. Each day DevOps become more strongly molded in the aforementioned model and further from the reason the DevOps conversation arose in the first place. That is, we are losing sight of the value that could be derived from recognizing and correcting the hurdles and problems that exist in currently delivering and running systems for the purpose of running a business.

What are those problems again that are limiting our abilities to be perfect (as a goal, not a requirement) in our delivery of IT services to the business?

  • Lack of automation means more human intervention and greater chance of error and outages
  • Lack of collaboration between those who build and those who operate leads to greater opportunities for inconsistencies between environments and outages
  • Lack of automation and collaboration in addition to out-of-date policies limits the ability for IT to respond to business needs faster

There are some learned practices that seem to greatly help some IT departments respond to these problems. There are some tools that improve configuration management and allow automation of complex, distributed environments. There are tools, policies and procedures that help to improve collaboration and communication between those who build and those who operate. There’s still a need to manage up to help senior management understand that this is not solely a “below the waterline” problem and needs executive sponsorship to succeed.

Let’s not allow DevOps become so mired in a need to be molded to some idea of a geek fantasy project that we lose sight of the good that come its origins. Allow the knowledge of and experience of those that have mastered moving their business to a more agile and high-quality environment guide your own efforts, but don’t get caught up in whether or not it’s “DevOps”. Are you addressing the key problem areas identified above? If so, then your business will benefit from the improvements in IT service delivery.