An Expert’s Take on the Converged Infrastructure Learning Curve – Part 2: The Trouble with “Agility”

January 17 2013 | By | in Converged Infrastructure

Bullet Trains - East Shinkansen Lineup at Niigata DepotTaking new products and customers into production has always felt like jumping onto a speeding train to me. It has to reach its destination on time and without a mishap. When I was a New Product Introduction engineer, and then later a Project Manager in charge of launching new SaaS customers, I always felt I was mid-journey on multiple trains (sometimes laying track “just in time” along the route) when I would receive another assignment…on another track, headed elsewhere…with instructions to jump aboard & ensure success. A deep breath and a brief burst of adrenaline almost always accompanied such news, and I doubt I’m the only one.

So when I watched my colleague Kent Erickson’s interview regarding Converged Infrastructure’s learning curve, I couldn’t help but think about the increasing frequency of introductions of new products, projects, and customers, juxtaposed with a new type of infrastructure. And about how, contrary to what I was taught in engineering school, Converged Infrastructure means there’s no such thing anymore as testing one variable at a time. With shared infrastructure, multiple things are changing at the same time.

 See More of This InterviewContact UsWant to See a Demo?

With “convergence” comes interdependency. IT’s getting more like medicine. Medical professionals are always prescribing new drugs, recommending therapies, or suggesting environmental changes be applied to a complex, interdependent system that CANNOT be isolated into silos where one variable can be controlled by itself. Sharing resources like air, water, and energy between the human nerve system, the immune system, and the digestive system leads to potential side effects that – even in small print – take up easily half of the accompanying instructions, for instance.

Yet here we dive into this more complex Converged Infrastructure, whether built loosely from the VMDC reference architecture using Cisco UCS or on pre-packaged solutions like NetApp FlexPod, VCE Vblock, EMC VSPEX, or others, our businesses and organizations MUST ask us to introduce new applications and new clients, faster than ever. It’s no wonder stress levels are high. Nobody has time to read the small print, where hundreds of interactions and side effects are described.

We’re expected to manage risk with every new introduction, while being agile. It can be hard to predict how much time it will take to figure out the new normal for any new product or application. Or new customer with unique needs. A new and as-yet-undetermined baseline must be learned, and the indicators you’ve relied on before (that tell you when you’re “off the rails” – going back to my train analogy) must be set in such a way that they don’t cry “wolf,” but don’t miss anything, either. This requires that a cohesive team iterate quickly, learning and adapting faster during the introduction phase than at any other time.

Meanwhile, it’s asking for trouble if you DON’T launch right away with the controls your team and management is used to. The further someone is from responsibility for a new launch, the less understanding they are, and the less leeway they will give you; they are resourced to conduct “business as usual,” and have no patience your team’s learning curve.

And it’s not as if any of the existing services you provide (the other trains I was riding before a new introduction was dropped in my lap) don’t need the normal sustaining work. Existing infrastructure (and the services delivered thereby) will often live on for ages, along with the tools and processes that were designed and deployed for them – and were right for them at the time. I can’t remember ever getting to rip out everything at once & start over. That’d be way too big a business risk. So we partition our brains, doing tasks one way for existing stuff, and another way for new stuff.

That’s no recipe for efficiency or quality work. That’s “convergence” in name only. Not in operation. The sooner the operations converge, the better.

So take a look at Kent’s interview, where he addresses key obstacles to achieving the agility that businesses and organizations increasingly demand. You’re not alone in thinking everyone expects everything more quickly than before, not to mention, in a more complex, shared environment. Your leadership is probably making dire warnings about what will happen if the competition gets their introductions done more quickly, at lower cost, and with fewer mishaps than you. It’s time to talk openly & honestly about the trouble with agility.

Click Here to See the Full 20 Minute Interview

 Other Posts in this Series

Image Credit

 

 


[adrotate block="1"]