Recently I have read a number of articles and had several conversations with architects and engineers across various specialities in the industry and I’m finding there is a growing trend of SMEs (Subject Matter Experts) having tunnel vision when it comes to architecting solutions for their customers.
What I mean by “Tunnel Vision” is that the architect only looks at what is right in front of him/her (e.g.: The current task/project) , and does not consider the implications of how the decisions being made for this task may impact the wider I.T infrastructure and customer from a commercial / operational perspective.
In my previous role I saw this all to often, and it was frustrating to know the solutions being designed and delivered to the customers were in some cases quite well designed when considered in isolation, but when taking into account the “Big Picture” (or what I would describe as the customers overall requirements) the solutions were adding unnecessary complexity, adding risk and increasing costs, when new solutions should be doing the exact opposite.
Lets start with an example;
Customer “ACME” need an enterprise messaging solution and have chosen Microsoft Exchange 2013 and have a requirement that there be no single points of failure in the environment.
Customer engages an Exchange SME who looks at the requirements for Exchange, he then points to a vendor best practice or reference architecture document and says “We’ll deploy Exchange on physical hardware, with JBOD & no shared storage and use Exchange Database Availability Groups for HA.”
The SME then attempts to justify his recommendation with “because its Microsoft’s Best practice” which most people still seem to blindly accept, but this is a story for another post.
In fairness to the SME, in isolation the decision/recommendation meets the customers messaging requirements, so what’s the problem?
If the customers had no existing I.T and the messaging system was going to be the only I.T infrastructure and they had no plans to run any other workloads, I would say the solution proposed could be a excellent solution, but how many customers only run messaging? In my experience, none.
So lets consider the customer has an existing Virtual environment, running Test/Dev, Production and Business Critical applications and adheres to a “Virtual First” policy.
The customer has already invested in virtualization & some form of shared storage (SAN/NAS/Web Scale) and has operational procedures and expertises in supporting and maintaining this environment.
If we were to add a new “silo” of physical servers, there are many disadvantages to the customer including but not limited too;
1. Additional operational documentation for new Physical environment.
2. New Backup & Disaster Recovery strategy / documentation.
3. Additional complexity managing / supporting a new Silo of infrastructure.
4. Reduced flexibility / scalability with physical servers vs virtual machines.
5. Increased downtime and/or impact in the event hardware failures.
6. Increased CAPEX due to having to size for future requirements due to scaling challenges with physical servers.
So what am I getting at?
The cost of deploying the MS Exchange solution on physical hardware could potentially be cheaper (CAPEX) Day 1 than virtualizing the new workload on the existing infrastructure (which likely needs to be scaled e.g.: Disk Shelves / Nodes) BUT would likely result overall higher TCO (Total Cost of Ownership) due to increased complexity & operational costs due to the creation of a new silo of resources.
Both a physical or virtual solution would likely meet/exceed the customers basic requirement to serve MS Exchange, but may have vastly different results in terms of the big picture.
Another example would be a customer has a legacy SAN which needs to be replaced and is causing issues for a large portion of the customers workloads, but the project being proposed is only to address the new Enterprise messaging requirements. In my opinion a good architect should consider the big picture and try to identify where projects can be combined (or a projects scope increased) to ensure a more cost effective yet better overall result for the customer.
If the architect only looked at Exchange and went Physical Servers w/ JBOD, there is zero chance of improvement for the rest of the infrastructure and the physical equipment for Exchange would likely be oversized and underutilized.
It will in many cases be much more economical to combine two or more projects, to enable the purchase of a new technology or infrastructure components and consolidate the workloads onto shared infrastructure rather than building two or more silo’s which add complexity to the environment, and will likely result in underutilized infrastructure and a solution which is inferior to what could have been achieved by combining the projects.
In conclusion, I hope that after reading this article, the next time you or your customers embark on a new project, that you as the Architect, Project Manager, or Engineer consider the big picture and not just the new requirement and ensure your customer/s get the best technical and business outcomes and avoid where possible the use of silos.
Pingback: Example design consideration - Company culture - Virtxpert
So, in essence, _any_ Enterprise or System Integrator needs to have an *IT Generalist* to oversee that the proposed solution will be optimal for the corporation.
#ITGeneralist #ITGeneralistManifesto #SysAdmin
Every project should have an experienced architect with broad experience in the relevant areas (hands on and architectural) with a deep understanding of the customers existing environment and requirements for the current project/s. The architect should have expertise in for example virtualization, and ideally be supported by SMEs from other areas.
Very good article, Josh! I see this quite often in situations where vendors or system integrators are focused on their own product/ solution. Most the target is to position their solution and use as much features as possible. To take up again the example Microsoft Exchange: Recommend the usage of physical servers and JBODs is Microsofts way to say “Look, you can reduce complexity and costs with our product. Use cheap servers, cheap storage and our software will do the rest.”. On top of this: The first question is rarely “Tell us something about your environment.”, although this should be the first question. A sales process should be driven by delivering added value to customers. And value isn’t added by adding silos to the customers environment. Adding silos to customers environments is a waste.
I am an IT architect with a broad experience, I realized lot’s of projects myself, I educate myself all the time and I’m working since than 15 years…
One very big challenge as IT architect is to be accepted as important part of a project. IT projects are often designed by the sales representive and the sales engineer behind them. Paying lot’s of money for an IT architect is a huge problem for lot’s of companies. They don’t understand why they should pay lot’s of money for people like me, who creates “only” a paper with a solution that fits. (But their homes are design by an architect, of course. ;))) )
As IT architect you have no friends. The sales people don’t like you b/c you are sizing the environment (and his provision). The IT stuff of the companies don’t like you, b/c you recommend things they don’t want, either it’s more work or it don’t fit in their vision. The clients don’t like you, b/c you’re expensive and the result is only a paper/recommendation/guideline… no HW, no SW, no product.
On the other hand, you’re right, lot’s of IT architect sells only best practise that you can download everywhere. This is not good… lot’s of IT architect have no real experience. They design things that they never tried them sells. And lot’s of IT architect are similar to sales enginerrs and have no own opinion and selling only products from a specific vendor.
We need real IT architect, b/c IT complexity increases and on the other side companies want to save money. I’m not sure if our job can survive.
I see all to often Sales people calling themselves architects, and I agree the Architect who makes recommendations which may not line up with sales expectations, or customer budgets are never popular but I have always believed the customer deserves the truth, so at the risk of loosing a sale, I will tell a customer my opinion which cannot be influenced by my employer or a sales target which is why I have found many customers looking to me as a trusted adviser.
My other rule of thumb is, if you can’t implement it, you can’t (or shouldn’t) architect it.
Good point. Unfortunately I don’t think this is a commonly used/thought about.