One topic that’s unusually difficult to wrestle to the ground is what to do about what is often referred to as "engineered systems" -- vertically-integrated single-purpose software and hardware stacks, designed to be consumed as a dedicated appliance. I would put Oracle’s Exa line in this category, as well as data warehouse appliances such as Teradata and Netezza.
Just to be clear, I consider these purpose-built beasts as quite distinct from the horizontal converged infrastructure offers (Vblocks, etc.) that can be used for many different purposes as well as support open management integration.
And, as I tell anyone who will listen, this is going to be one of the harder choices you’ll have to make.
Let's say I’m talking to a reasonably proficient — and large — IT organization. They’ve started to transform to a standardized / consolidated / virtualized technology base, coupled with new operational and consumption models. It ain’t easy for them, but you can clearly see them moving in that direction — and for all the right reasons. All good.
Except for a particularly thorny and passionate debate has erupted.
Dotting the landscape are a non-critical mass of non-standard, special-purpose technology
stacks dedicated to a single application function in the IT realm. Making problems more challenging are associated strong user communities who are heavily invested in “their” platform.
IT desperately needs to move to a standardized / consolidated / virtualized supporting ITaaS, but — clearly — certain technology choices don’t even begin to fit that paradigm, and won’t any time soon.
A small but vocal business user community (armed with arguments from the vendor) has decided to fight for their right and need to be different.
The Arguments In Favor Of Engineered Systems
My biases should be clear here, but I will acknowledge the engineered system vendors have come up with a few reasonable-sounding arguments, with enough "truthiness" to be seriously considered.
Their arguments usually center around workload optimization: things like better end-to-end performance, driven by the presumption that a given workload is unique and thus can’t possibly use what everyone else uses.
And, finally, there's the perception created of a less-expensive combined software/hardware/support solution.
Everything is engineered to work together; all sold by and supported by one source, bundled into a presumably attractive price. What are you waiting for?
Keep in mind, these systems are typically pitched at the business users, and those who directly support them. The central IT group is approached later in the sales cycle as a final obstacle, and not usually engaged at the outset.
The pitch to the business crowd is quite seductive: what you do is so darn important that you certainly need something special, so tell those IT infrastructure guys to get in line and support your requirements — in the form of a purpose-built, non-standard “engineered platform”.
After all, isn’t the role of IT to do what the business wants? You’re the business — tell them what you want!
And I’ve seen an awful lot of Oracle, Teradata and similar platforms land on the floor — and stay there — based on this selling motion.
The Arguments Against Engineered Systems
The perspective shifts when one attempts to consider the macro implications of the decisions being made. For starters, I consider the “superior price/performance” claims somewhat overblown in many cases, with Oracle typically not being shy in this regard.
Parts is parts. Horizontal technology (Intel CPUs, flash, hypervisors, etc.) can deliver outstanding levels of price/performance, and they’re far more useful when packaged to be consumed horizontally vs around a very specific use case. Look inside most of these engineered systems, and you’ll find very familiar components and building blocks.
The engineered systems crowd usually promotes an argument that their pre-built application environment is far simpler to install, operate and support as compared to do-it-yourself, which is true. That’s the appeal of appliances.
But this argument also ignores the appeal of more horizontal converged infrastructure approaches which offer the exact same benefits, but do so for many diverse workloads vs. only one -- plus support a far richer integration model that enables them to be managed as part of a whole vs. a one-off.
The bigger argument against engineered systems — I believe — turns out to be operational. Most every IT organization I meet is working diligently towards a more efficient and more agile standardized operational model that works across the majority of the IT landscape, and not designed as collection of isolated pockets.
Look at it this way: with every flavor of "engineered system" that lands on the data center floor, there is a non-trivial and incompatible operational footprint that lands with it.
You will need specialists that understand the nuances of how it works. Common IT operational tasks: provisioning, monitoring, capacity planning, etc. — will be done differently and in a non-standard way on these platforms — unless you’re willing to invest in some serious systems integration and/or a dedicated team to
look after them.
And that ain't what IT-as-a-service is all about.
I Am Not Pure Here
Back when I was working at EMC, this came up shortly after the Greenplum acquisition. Greenplum is pure software -- runs on just about anything standard, and runs quite well. But we quickly discovered that certain customers wanted an all-in-one solution, pre-packaged with hardware to land on their floor. Thus was born the DCA -- the Data Computing Appliance -- a pre-configured rack of industry-standard servers, ready for consumption.
While not as egregious as some of the "engineered systems" in terms of lack of standard-ness and openness, it did illustrate the appeal of an easy-to-consume solution that was the shortest path between a business need and a running solution.
For those of you who follow me, you'll know I've long been a fan of converged infrastructure such as the VCE Vblock. Once again, that's a different deal: not only can it be used successfully for a wide variety of workloads (including many that presumably warrant an "engineered system"), it also has the open APIs and management interfaces that enable it to be more easily integrated into the customers' operational model of choice vs. one pre-defined by the appliance vendor.
What To Do?
Clearly, the IT infrastructure and operations groups are often under enormous business pressure to simply suck it up, and bear the additional cost and complexity of non-standard engineered systems. Perhaps more cost-effective and functional alternatives are readily available (especially when it comes to Hadoop for analytics), but — alas! — no one on the business side is listening.
I consider this decision as one of those "moments of truth" as IT organizations transform to ITaaS models. What stance will you take regarding one-offs? Their existence is inevitable; but you can decide how you want to handle them.
I’ve always believed that the best approach was to expose the true costs back to the people who are asking for a specific (and non-standard) platform.
I’m not talking about acquisition, licensing and maintenance costs — I’m talking about the far larger organizational cost of supporting a non-standard platform.
The best approach I’ve seen is simple: externalize the costs
The Ideal Conversation
CIO or similar engages with business lead, and the discussion goes something like this.
Dear Business Leader:
You’ve decided that you need a very specific platform to run a critical business function, and we fully understand and appreciate that.
But, at the same time, we in IT have a critical mandate to standardize our environment — both from a technology perspective as well as an operational perspective. Introducing non-standard elements raises our costs substantially, and we’re not chartered to invest in supporting one-offs internally. I'm sure you can appreciate what we've been asked to do.
So here is what I propose ...
Let us help you find a good hosting provider for you to work with. They can house your platform, and support its day-to-day needs, since we're not skilled in your choice, and don't plan to invest. Together, we can find a good provider, and additionally do the required legwork to vet their security, compliance, and operational model. We also may need to build data integration bridges into — and out of — your choice.
The benefit to you is that you will get exactly what you need, and at a fair market price. We in IT will get what we need as well — the ability to move towards operational standardization across the entire business, while trying to accommodate your unique needs. Of course, we will ask you to bear the costs of hosting, as well as compensate the IT team for the time and effort that will be needed in helping you achieve a satisfactory result.
I should warn you, you may find this proposed approach to be relatively expensive when compared to other alternatives. If you’d like to discuss more cost- effective alternatives that are compatible with our existing environment, we’d look forward to that.
Let me know how you would like to proceed.
Your IT Leader
The appeal here is that you’re essentially asking the business leader to bear the true costs of their decision — which, from a business perspective — is not an unreasonable ask. Asking for the IT group to suck up the additional costs made by a business unit would strike some as being unreasonable.
IT Needs To Learn To Control Their Own Destiny
I certainly don’t envy the predicament many larger IT groups find themselves in.
On the other hand, there’s 10+ years of point solutions and associated technology stacks sitting on the data center floor, many with defensive user populations to contend with. Not to mention some very aggressive vendors trying to move "engineered systems" hardware behind their software stacks.
Maybe you can’t change the legacy, but you certainly can take steps to keep even more legacy from landing on the data center floor.
Like this post? Why not subscribe via email?