Thoughts on Integrated Stacks

Over the last couple of years there has been a lot of discussion around moving from the traditional methods of building out infrastructure to utilizing converged stacks. At this point nearly every manufacturer has gotten into the game, positioning their own technologies, setting up independent companies or partnering so that they too can have an offering. Engineered Systems, Integrated Stacks, Converged Systems, Reference Architectures or Validated Designs or whatever name or category they fall under are not identical but they strive to accomplish the same goals.

• Certainty. Provide solutions that are validated to have known performance and availability characteristics 
• Faster deployments. Much of the design and architecture work is eliminated. Depending on the type of solution, the actual time to implement may also be decreased since it arrives preconfigured. At a minimum guides are available to walk the team through installation as a whole rather than piece by piece. 
• Ease of Management. Converged solutions either come with or are validated to work with management and orchestration software that simplifies administration of the solution. 
• Improved Support. These solutions are standardized so the vendor support organizations have fewer variables to worry about. There should also inherently be a broader number of organizations running the same configuration so you will not be stranded on an island as “the only ones doing it that way”. 

There is no magic to these solutions, the approach is similar to what we all do today. If you have to develop a remote office solution and deploy it across 100 sites you don’t come up with a unique approach for each, you standardize the solution and implementation process so that deployment is efficient and support simplified.

At Lumenate we apply these same techniques using what we call service factories. While we certainly get involved in a wide range of projects there are several solutions that we deploy over and over again. Just as an Internal IT department would, we standardize how we use and deploy these solutions.

Now many of those in the trenches of IT, those that design and architect these solutions look at these converged stacks with a bit of skepticism. They point out that their requirements are unique and don’t fit neatly into these predesigned solutions. That’s certainly going to be true in certain cases and a senior architect or team of architects will be required. This is the type of work that most of us enjoy most, solving the hard problems. In many cases though, when looking at the most popular applications and use cases the workload is very well understood and the integrated approach can be used.

The second comment I hear most frequently is that our internal team can design a better solution for our needs than something that was created generically. Again I would say this could be true. Perhaps a thought experiment might shed some light on why management and business leadership may be enamored with this new approach.

Let’s say we started by going to 200 organizations and asking them to design and implement a solution. In each case we provided a list of requirements and parameters. The first 100 we would allow to use any methodology and any technologies they wanted. The second group we would instruct to use a reference architecture or integrated stack.

My theory is that you may have a few in the first group that create an exceptional solution, they implement it efficiently and meet or exceed expectations. Of the remainder I believe you would have a higher percentage of successful implementations in the group using the integrated approach.

If you have been in this industry for any length of time you have seen or more likely been a part of an implementation that didn’t go well, that cost more than expected, took longer to implement and failed to achieve the desired results. These are the memories in the heads of business leaders when they fall captive to the siren song of an integrated stack.

If you’ve made it this far you may be under the impression that I think this new approach is the end all be all but that is not the case. As with nearly everything in IT there are tradeoffs and areas that should be carefully considered.

One of the tradeoffs is a lack of flexibility. At the most extreme end you have engineered systems that are very locked down and rely on a single source. As you move towards the other end of the spectrum you have reference architectures that may allow more choice in the components used in the stack but the options will still be much less than we are accustomed to. During initial implementation this may not be much of a sacrifice but it could be when you want to leverage new technologies but cannot do so without breaking the reference architecture. It’s not that it wouldn’t work or that you would lose support but you would lose some of the value that took you down the reference architecture path in the first place.

What has been interesting lately is watching the reference architectures getting broader and broader and providing more and more choices. As an architect I might like that because it puts me back in the driver’s seat but I wonder how that will work long term. If there are 10,000 reference architectures how much different is that than what we have today. Murphy’s law says that you still will end up selecting an architecture that wasn’t that popular and when you call support you will have the joy of hearing “you’re the only ones doing it that way!”

Thoughts on Integrated Stacks