When IT Infrastructure Thinking Doesn't Align With The Business

It's sometimes depressing to realize that I have been in and around IT infrastructure types for at least 30 years.

Sigh.

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

Not everyone thinks the same way, but there's certainly a cohort that thinks alike.

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.

The thinking is that any benefit that results around stack optimization for specific workloads is more than offset by the benefits that accrue from a simpler, more standardized environment.

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.

Using VCE Vblocks as an example, the premise is that VCE assembles popular choices and presents a single "virtual" product.

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 Argument

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.

I fully realize that this view is not popular with IT infrastructure types that think in terms of landscape-wide standardization, largely independent of workload.

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

Most people think vendor competition is a battle of products: feature/function, price, support, etc. That's largely true when considering point products.

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?

 

Comments

[Aernoud van de Graaff]

Hi Chuck,

I fully agree that the business interest should be top of mind when providing infrastructure solutions.

Maybe I am old school, but I am a true believer that standardization (where it is possible and makes sense) will help achieve this. I also believe that in most (but not all) situations a generic solution will do.

Because infrastructure is becoming more and more software defined, you can create standardized options that will facilitate different business requirements ensuring that the generic infrastructure solution can cover more and more of the business requirements, also around the DB and App solutions Oracle is bringing to the market.

The biggest issue the infrastructure has today that impacts the efficiency, reliability, security, compliance and agility of their services is complexity. Complexity because of all the variation they introduced in the past and never got rid of and all the variation they will bring in, in the future...

To enable innovation there should always be room to try new things. I would even encourage that and try lots of things, but it should be a designated environment that has a different function and service levels. Once a new technology emerges from that environment, if possible let is land on the generic infra solution, if not, build a well managed exception for it.

So, not everything has to land on a generic platform, but most should and exceptions should be offering tangible benefits for the business that justifies the additional complexity it brings to the infrastructure (and thus more cost, more risk, etc).

And to be honest, in most situations Oracle, IBM, SAP, etc. software runs just fine on generic X86 hardware with either a SAN or even on local storage (Nutanix, VSAN, etc.).

So the best way to support the business is to standardize where you can and eliminate all variants that do not (or no longer) provide key differentiation to the business and limit variation only to where it makes sense for the business.

Hopes this makes sense...

So everybody that recognizes the complexity issues in their organization. CLEAN UP YOUR $%@* !!!

[RIch Winston]

The subject of this article is at the center of what is happening all over IT. Problem I see is that ORACLE's premise is wrong.

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.

ORACLE is the center of the mission critical data in the world today but will not be in the future.

[Chuck Hollis]

Hi Rich

What do you believe will be the center of mission-critical data in the next 5-10 years? I don't see it.

-- Chuck

[Gary]

Excellent description of the real world as compared to IT centric thinking!

[Acton Dara]

To whatever IT infrastructure service provider you are contacting, you need to make sure that these services must align with your business requirements and objectives. Since IT infrastructure service kinds are nearly the same in simplicity and standardisation, so the workload is usually average because one size fits all. http://www.thebesgroup.co.uk/managed-services/infrastructure/