Everyone does work that they try to make the best they can because most of us take pride in our work. It’s that pride that instills passion in our debates when we defend what we have done or our concept of what we have done against criticism. While I am as guilty of this pride in my work as anyone else there are times where a debate is justified.
This is one of those times.
The concept of bi-modal isn’t a new one, and in fact has been around since before I was working in IT. However, books like the Lean Enterprise and others have lauded bi-modal as the defacto method for running an IT shop to enable Developers and Operations to each be efficient. This concept has matriculated in recent years to the analyst community to the point where even Gartner has adopted the conceptual notion of bi-modal, and if Gartner says it, it must be true.
Now I am not trying to punch up at the bigger folks here, just merely my opinions and views based on what I have read and experienced.
Let’s first dive into what bi-modal is, “bi” means 2 and modal means modes (you expected that sarcasm didn’t you?). So if you have 2 modes one would be operations and one would be developers. Each mode has it’s own unique set of requirements, not to pick on Gartner here but they use the analogy of Sprinters and Marathon runners.
Marathon runners on the other hand are more methodical; they play a long game, and worry about endurance. This sound familiar? Yeah, that’s the Operations side, concerns about maintaining the environment they are charged with, and the longevity of success for application and hardware therein. Availability, reliability and a solid foundational plan are key. It can take months or more to fully implement a project for enterprise operations folks.
Now you may be saying to yourself sure this makes perfect sense what’s wrong with that? Well bi-modal goes a step further, because these two modes have different requirements, the belief than is that they need to different infrastructures to support each. Yeah I get I work for one of those infrastructure companies, but I don’t necessarily support this view. Because what this means is new gear hits the floor and say it’s for Mode 2 the Sprinter’s who is going to get strapped with doing that management? Yeah Mode 1, because Developers can’t be bothered to maintain their own hardware or if they do have to they get dinged on security compliance issues (been there done that).
It just doesn’t make sense it’s like how Twix builds the left and right Twix in different factories. I mean sure Right Twix has that cool steampunkesque packing tape dispenser but it seems like a huge waste of resources and how did it ever get that far? Was there not someone overseeing manufacturing expenditures?
Hey that’s a great Segway and no I am not complimenting Woz on his localized form of mobility. If bi-modal isn’t right what is? Let me answer that question that you didn’t ask with a question that you won’t really answer, what is missing in bi-modal?
I will give you a second.
That’s right you are smart, we are missing an architectural planning element. You see while bi-modal is conceptually right about the needs of these two groups, what they miss is that if you let either go off on their own never the two shall meet. That misses a huge mark when it comes to trying to converge Devs and Ops to ensure the goals of the organization are achieved don’tchathink?
Enter someone who I tend to agree a great deal with in Simon Wardley, who presents the case that Bi-modal is more of the same archaic silo’d approach to meeting business objectives which have stagnated and caused discourse in IT organizations for decades. He poses that tri-modal IT would be far more effective as an approach. Laying it out in the analogy of Pioneers, Settlers and Town Planners. This got a chuckle from the NMVMUG crowd the other day when I brought it up, as most East Coasters don’t really understand the concept of how vast the homesteading territory actually was. But I digress. In a tri-modal approach Pioneers are the developers they are constantly in search of what is new and never sitting still. Meanwhile Settlers are the Ops folks who stake roots in the datacenter and ensure that it thrives as an ecosystem. Town planners are the glue here, they leverage strategy to ensure that the Pioneers are getting what they need, and the Settlers are getting support from the Pioneers and that the goals are being met. Back into the analogy the Town Planner would ensure that a pioneer wouldn’t set up a temporary cattle paddock next to the drinking well because that’s how you get **it in the water.
The concept of tri-modal speaks to something else though, which is the maturity of an organization. While developers tend to be the founders of software or companies, once established their findings and creations become the baseline which operations have to maintain. Once we hit an operational maintenance mode for anything we start to look at efficiencies in how we productize it (that’s business). Some of the time that will mean changing the way we position or license the product set or the way we manage the infrastructure and move towards the elasticity of cloud, that is commoditization. Look at the path storage has taken, at once it was all built to suite specific needs, then productized and marketed and startups jumped in the ring, now it’s commoditized as we look to moving our data to the cloud. That is the natural progression of most successful solutions.
Bi-modal isn’t wrong but I think a disservice is being done to those who buy into it as the only or best method to combat the ever-changing ecosystem. Business and organizations today are concerned with being out paced or becoming obsolete. That means competitive advantages what better advantage is there than being able to reach full evolutional maturity of products faster than your competitors? Proper planning and execution is how you do that and breaking the silos through team alignment towards business objectives is the key. That’s why tri-modal makes more sense.