The Build-Your-Own IT Solution: RIP

Have you ever noticed when going out to eat with friends or family, someone often says “I could make this at home”? Do you know anyone in your neighborhood, or at work or at school, that likes to tear apart and rebuild cars in their garage? Or how about the guy in your neighborhood that always seems to be building some new project around his house.

It’s that “build-your-own” mindset. It’s often ascribed to as being “American”, but in reality, it happens all over the world. Some people just like building things with their own hands to solve their own needs.

IT used to be like that.

If you were paid to work on computers in the 1990’s, and even into the early 2000’s, you can probably think of at least a few projects you built which couldn’t be purchased. Even if you started with a retail product, just like buying wood at the hardware store, you ended up cutting, adding, attaching, reconfiguring, and so on. You still see a fair amount of custom construction in the software space, but not as much in the infrastructure space. Not as much as there was (on average) around ten years ago.

So, what happened?

Two words: fiscal responsibility. Businesses like things which are measurable. Quantifiable. Predictable. Construction workers depend on bricks and other materials which comply with a standard of some kind. Imagine building a house to plan, and all the materials were different shapes and sizes. No two boards the same kind of wood or measurements. It would suck.

I use the analogy of construction, because it has so many parallel aspects to IT, but we don’t often see them. Like craftsmen, as much as we hate to think about it, technical-minded people (systems engineers, administrators, technicians) prefer to build things and improve things, not take our eyes off the bench to look at material lists and bank accounts. We don’t care as much about how our materials are really made, as long as they pass the test and we can get them when and where we need them. Then we assemble them into sum total which is greater than their parts. We’d like to think so anyway.

What happened, was managers and financial experts got tired of trying to decipher IT “geek talk” into project planning metrics. When comparing the hardware-based and software-based sides to IT, the hardware-based side was the lower hanging fruit. Let’s face it, for years, it was much easier to “show” the management folks how far along the server room or SAN build-out was progressing. “Showing” them how far an application development project had progressed was never “crystal clear”.

I won’t go into the personality trait differences between server and network engineers and programmers, but let’s just say that one of them tends to communicate with the suits on a more familiar dialect.

With virtualization, cloud services, modularity and commoditization overtaking most of the data center world, the Wild West road show has had to move down the road farther and farther away. The new business town wants building blocks that match in size, weight and material. The top-level business echelon really doesn’t care if it’s HP, Dell, Apple, or what OS is running on it, or what applications are involved. Just because one product is a no-brainer solution today, doesn’t mean that if something fit the need better later on, they wouldn’t drop the status quo and chase the better solution ASAP.

Their money is riding on the mission statement, and the vision, not the data center. For most organizations, the data center is a tool; a resource for performing a business function. It’s not perceived as being the business itself. Even if you work for a company that relies heavily on IT, if you stand back and ask “what is the reason for this business to exist?”, you often answer it with something other than “to build and maintain data centers” (unless you work for a cloud service provider).

Most technology vendors left that “gap” alone. They had a wide range of reasons for doing so. Some valued their VAR channel involvement, partner and ISV ‘value add’ propositions. Others marketed to the customer as being the gap filler; in-house customization, etc. and may have offered custom augmentation services when needed. Others used the gap as an up-sell for their own “special” services (CRM, portals, document management, come to mind).

Whatever the reason, customers began to express dislike for the added headache and costs associated with filling the gaps. (gaps, in this context, refers to features or capabilities available in the retail product, as compared with customer proprietary needs). So vendors began absorbing more and more of the gap, for two primary reasons:

To position their products and services as being less complicated and costly than their competition.

To secure and control the fringe revenue being siphoned away by VARs.

All that business blabber, so what am I really saying? I’m saying that the big vendors are pushing harder than ever to make their products easier to install, configure and use. Years ago, these were merely marketing buzz words. Customers got wise to that. Vendors got wise to customers getting wise. Vendors had to actually deliver, or at least, start to deliver.

If you’ve worked in IT for more than twenty years, you probably have noticed that many areas of our industry don’t require as much “custom” work as they used to. Login scripts? Backups. Web portals. Most of those are now either built into the products, are simple features in those products, or available as free or affordable products of their own.

Look at how imaging has evolved. In the “old days” it was horrible. Then came Ghost, and Microsoft stepped in with BDD and MDT. The same thing happened with patch management and then SUS, WUS and WSUS. Then virtualization landed, and that evolved to VMware Player and Hyper-V, both of which are free.

Some would argue these evolutionary extinctions are the result of evil-minded business greed. I would argue that they were more likely the result of trimming complexity and gaining a competitive edge.

All of these have either been acquired, assimilated or co-opted in one form or another. Some would argue these evolutionary extinctions are the result of evil-minded business greed. I would argue that they were more likely the result of trimming complexity and gaining a competitive edge.

Pretty much any general-purpose business-oriented technology has been placed on a new conveyor belt to be scanned, probed, evaluated and re-engineered to do more, out of the box, so as to reduce the need for post-installation work. It started with the IT aspects which could be measured most easily, and is still ongoing, towards the ultimate battlefield ahead: applications development. When development tools and coding patterns and practices are standardized to their satisfaction, they tool will get a label, a box, and a shelf on which to be counted and assigned a value. And all this time you thought those IDE and cloud integration features were just for the sake of coders.

Can you build your own System Center-like software tools? Yes. Could you build your own SharePoint portal? Yes. Could you build and maintain your own Azure Active Directory synchronization platform? Absolutely. But, compared with making your own restaurant-style meal at home, you’re not as likely to chase that in IT anymore.

Don’t mistake what I’m saying for being Microsoft-centric. I chose these examples because they’re the predominant tools and terms in most large data centers. All of this applies to open source and competing retail services and vendors as well.

So.

You will likely hear “I can make that at home” while eating in a restaurant for many more years. You will likely see people making their own household projects, custom cars and motorcycles and even clothing. But you’re going to hear less and less of IT folks saying “I can build that myself”