The Poorly Designed House

My first post ended with a diagram showing what I consider necessary components of a complete solution. I’ve been using it as a tool to evaluate not only competitive solutions but our own VCE developed solutions. It also provides a visual aid that allows me to drive discussions with customers about the value of the Vblock as a solutions platform.

In those discussions with customers, I talk about solutions design by drawing on the analogy of building a house. Of course, every house should be built on a sound foundation and that is no different when building a solution such as enterprise messaging, relational database systems, VDI, etc.. To no one’s surprise, I always recommend that this foundation be a well-engineered virtualized infrastructure, preferably a Vblock. Once that foundation is in place, we can begin laying out the floor plan for the house that will host their enterprise applications.

That, incidentally, is where so many vendors stumble as they rush to sell their wares. Instead of taking the time to understand a customer’s current and future requirements, there is an immediate rush to get them into a studio apartment, when waiting to build out the mansion may be more appropriate. That type of shortsightedness is what brings us franken-solutions – systems that are bolted together over time as it becomes apparent that the original solutions design was not sufficient to scale over time or to meet future customer requirements.

A Modest Proposal

So, let me propose a different approach that I’ve learned from watching those who much smarter than I and much more thorough in their solutions designs; start with these two principles as you begin your work and have them guide you through the entire process:

1. Design for the end-state: Ever bought or built a bookcase to house your currently library, only to realize two years later, you need another but don’t have space for it? That’s how vendors and users often design their application infrastructures. They build to their existing requirements and do not design the solution with enough flexibility to scale and to add new elements. Perhaps they threw in 20% more storage and compute as a buffer for growth; but then find later they have not designed the solution with enough resiliency to account for different failure scenarios or they have constrained their network design so growth is not actually possible. However, by beginning with the end-state, we are able to not only design for scalability, but to evaluate the design for potential constraints that could become barriers to future growth or to the addition of new functionality.
2. Design solutions with modularized components: Any well-functioning complex system is composed of multiple sub-systems that are designed, at inception, to be integrated. Breaking a solution down to its constituent components, such as security and management, allows us to take a building block approach. We can identify the critical components of the base solution and design it in such a way that other components can be added in a modular fashion, with minimal disruption to service or a need for a complete solution redesign. Taking a modular approach can also facilitate an iterative design process. As each existing component grows or new components need to be added, the current solution can be reviewed and adjusted to accept new inputs and changes; this can be done without wholesale redesign.

I realize my first two posts, on solutions design, has been highly theoretical. What I plan to do in future posts is to walk though designs for different applications and use cases, such as Microsoft Exchange, VDI, Disaster Recovery, etc.. For those posts, I will assume a Vblock as the underlying system but the concepts should apply across any virtualized infrastructure.

Please let me know if you have any questions about the principles I laid out in this post. Also, if walking though different design use cases would be of value, please let me know what applications and use cases you would like me to write about.

Related articles

• What Is The Value Of A True Converged Infrastructure? (varchitectmusings.com)
• If It’s About Solutions, Then What Is The Problem? (varchitectmusings.com)