Approaching the IT Transformation Barrier


Part 1 – The New Steely Eyes of IT

Just like the Star Trek episode “Where No Man Has Gone Before” depicts the wondrous, perhaps frightening aspects of traversing a Big Cosmic Line, we’re likewise coming to a barrier of sorts… a barrier synchronization point, to be specific, in the Information Technology industry.  It’s a juncture where at least six things in confluence are profoundly disrupting IT usage patterns that we’ve built up over the past three decades.

I’ll dispense with the shameless co-opting of the Shrine of Nerdom, and instead turn to those of you familiar with computing in the parallel. I suspect you already get why I’m using the “barrier synchronization” pattern as a metaphor for this change: Many independent threads are running in parallel, but they arrive at a synchronization point (the “barrier”) where they must wait until all the related threads have arrived. Once that happens, they can move forward and make progress in solving the problem together.

But it’s more than just synchronization. There truly is transformation awaiting on the other side of that rendezvous. Here’s my reasoning as to why: In order for “Real IT Transformation” to occur, we’ve been waiting on six related industry threads to come together: 1) containers, 2) the API economy, 3) microservices, 4) composable hardware and software systems, 5) cloud and software defined networking, and 6) a host of use cases that place demands on these things so as to evoke transformative application of them in concert.  These threads and their convergence are shown in the figure below.


What’s interesting about these threads is that each has an origin independent of the others, yet they are all highly interdependent when it comes to maximizing their potential.

Most of these threads have been evolving on their own for decades, following paths to maturation shaped by a number of influencing vectors brought to bear by real world application.  But one point has been exerting gravity on all of them, drawing them toward an inevitable point of union where 2+2 really does equal 5. When put together, these six threads transcend themselves and we see an incredible transformation of how we think about and use “information technology.” Ready to bow to your new god, Jim?


The customer-facing values of this emerging pattern are in providing more choice in sourcing, developing, deploying, and managing applications without requiring the complex dependency requirements that traditional IT departments have solved.  Let me say that in plain English: The system is learning how to automate the bread-and-butter tasks that complex IT departments have grown up over the years to solve.

So, let’s talk about that: Why do IT departments even exist in the first place?  The answer is that IT departments historically solve the dependency requirements chain that stretches from the business needing an IT solution to actually making the solution available to the business.  Their customer (the business) wants an app/functionality that makes the business go. Once identified, IT solves the dependencies:

  1. What application software solves the problem?
  2. What operating system and middleware does that application require?
  3. What hardware will be required for all of that?
  4. What kind of hardware will be needed?
  5. Where will that hardware be housed?
  6. Who will make sure it stays up and running, and the dust is occasionally removed?
  7. Who can explain to the business how to use it and get value out of the solution?

You, no doubt, can come up with many others.  The point is, in order to make that dependency solving task more efficient and scalable within the enterprise, IT departments and business that house them have standardized on things like hardware (x86 servers, Dell vs. HP, SAN vs DAS, etc.) and software (Windows, System Center, etc.) so that the scope of things they must become expert at is tractable. This creates constraints on choices, which counter productively reduces the amount of value the business might get from IT.  “Sorry, we know app X is best for that function, but it runs on Windows and we’re not a Windows shop.”

In the next generation IT scenario at the center of the figure, the dependency requirements-solving function that the IT department has historically provided is now made less onerous for the business. This is because the maturing technologies (around the circle in the figure) automate everything from solving the dependencies as well as sourcing, deploying, and operating the components in solution.  In other words, the system is learning do what IT departments historically have done: given a business request for IT functionality, choose the best path to fulfillment.  As a result, the IT department is becoming more of a broker of services and less a dependency requirements solver.

In my next installment, I’ll start going around the wheel of the figure and describing each of the threads and how it is becoming an essential part of the transformative model.  What will emerge at the end of our tour is a list of characteristics that sets the “Real IT Transformation” apart from similar failed visions that have preceded it, and why this time success of the model is inevitable.

Well, assuming a second super-god doesn’t emerge from the barrier and they kill each other.  But, let’s think positively, shall we?

This entry was posted in Cloud Computing Technology Insights, Uncategorized. Bookmark the permalink.