I certainly appreciate how they look at the world, but I despair when I see their own interests diverge from that of the businesses they serve.
Even though I suppose that's human nature, it's certainly not ideal.
Case in point: building for the averages vs. building for the extremes.
Here's the synopsis: in an effort to "standardize" the infrastructure stack, huge opportunities for portfolio optimization aren't fully considered.
But what might work for IT doesn't always work for the business.
Inside The IT Infrastructure Mind
They view IT infrastructure architecture as a layered stack, with clear preferred choices at each layer: server, storage, hypervisor and so on.
The idea is to ostensibly pick the "best" for each component, and standardize its usage as much as possible.
While everyone appreciates a modicum of integration between stack layers (e.g. the hypervisor and storage), the bigger goal is to reduce dependencies between layers, and ideally produce an architecturally agnostic stack.
The stated goal of being architecturally agnostic is to minimize "lock in", and reduce the effort associated with potentially swapping out one layered component for another.
Interesting side note? Observed behavior is that vendor choices at each layer are rarely replaced, and often remain intact for many years, or even decades. It's not like you're going to wake up Monday morning and say, "hey, today's a good day to swap out my hypervisor". Curious.
The architectural model in turn drives the organizational and staffing model: familiar roles and skills, e.g. storage person, server person and so on.
Any meaningful integration, though, is after-the-fact and never deeply architectural. Usually, integration is thought of as adding yet an another layer to the stack, for example automation or monitoring. Compromises abound, as a result.
From an outside perspective, one can be very critical of these build-it-yourself architectures. They're assembled, not architected. Getting predictable results in a minimum of time isn't easy. Keeping them running and updated can be a massive drain on resources.
And there's no compatible cloud consumption option for snowflake architectures.
On the other side, the presumption is the fewer disparate technologies, the better. The theory is that IT can gain internal leverage by limiting diversity.
Arguably, this might work for IT, but how does this work for the business?
One Size Fits All?
Because IT infrastructure types crave simplicity and standardization, there's a strong incentive to think in terms of an "average" workload, and design around that theoretical ideal. Put differently, the notion is that a single architectural stack should do a "good enough" job on most (if not all) workloads.
But, once again, that's IT looking after their own needs, and not necessarily the business perspective.
That's why it's not uncommon to hear people say things like "we're standardizing on HP servers" or vSphere or EMC storage -- although EMC has such a broad and diverse portfolio it tends to undermine the original premise.
Considering The Extremes
Two obvious opportunities for optimization usually stand out at the extremes, especially in larger environments.
For unimportant workloads, "standard" choices might not be cost-optimized: hence the interest in open source, white box servers and software-based storage stacks. So another architectural stack is often born, one with different goals. Hey, it's all about saving money -- who can argue with that?
The other opportunity for optimization lies at the other extreme: workloads deemed very important by the business, and not necessarily IT. Hey, it's all about the best tool for the job -- or should be, shouldn't it?
However, it doesn't always work out that way.
It's not unusual to see IT architects "stretch" their preferred technology choices to provide the required levels of performance, availability, data protection and security -- compromising the results -- where just realizing that the requirements are different and something purpose-built is needed and makes more sense.
Case in point: I meet with customers who are both heavy Oracle database users, and big vSphere users. During meetings, they'll sometimes talk about their heartfelt desire to run their critical Oracle databases on vSphere. Needless to say, there are good technical and economic reasons why that's unappealing, but they press on -- it's all about standards, you know.
Looks like round pegs in square holes to me.
The Business View
So, rather than thinking in terms of a workload distribution function as seen by IT, we used a curve that reflected the business importance of a given workload? We'd end up with a curve that's very low on the left, and very high on the right.
It's hard for me to imagine how a single architectural stack wculd be ideal across the spectrum. Indeed, I've found that IT organizations that are trying to 'standardize' across the entire portfolio end up missing the important extremes in a big way.
At the far left, they just can't afford or justify the familiar name-brand choices. And, at the far right, they end up with highly visible gaps vs. stated requirements.
If I were a business stakeholder -- and knew my way around IT -- my message to the IT team would be simple. Folks, these are our most critical applications that power the business. Stop messing around, and put in something that delivers proven results.
Even if it doesn't conform to your notions of fashion.
But What About Converged Infrastructure?
That's a fair question, and deserves an answer.
The stated goal is to help minimize operational effort through integration, standardization and support -- and it does do that in many situations as compared to folks who try to assemble and support their own infrastructure.
But we end up with the same problem in a different form: the choices have been optimized for the averages, and not the extremes.
VCE has responded to this by offering different flavors of Vblocks targeted at different use cases; however it's still basically the same stuff with slightly different packaging. Because of the architectural choices made, it's hard to optimize it for either extreme.
Same story, different chapter.
Oracle's approach to IT infrastructure stands apart from just about every other major vendor in the industry. The premise is simple: most important applications use the Oracle Database, so that is what should drive business-critical infrastructure architecture, co-engineering, stack optimization and integration.
However, this singular viewpoint is surprisingly appealing to people who realize that database applications are highly differentiated; and not generic.
We're not talking about the conference room scheduling application here.
I am not discouraged: there are literally thousands of IT shops who have seen the light, abandoned their one-size-fits-all mindset, and provisioned Oracle engineered infrastructure behind their databases and applications.
Generally speaking, they say three things (1) the stuff works as advertised, (2) the products deliver the promised benefits, and (3) they'd do it all over again.
If only everything worked so well :)
With Architecture, It's A Contest Of Ideas
However, the real war is in architectural thinking -- how things should fit together -- and that's a contest of ideas.
All is fair, as long as the goal is to optimize business outcomes, and not necessarily IT-centric ones.
Like this post? Why not subscribe via email?