Let Your Needs Dictate Your Architecture
Let Your Needs Dictate Your Architecture
Are you managing your technology preferences right? It's important to let the requirements choose what vendors and services you uses, not what's popular.
Join the DZone community and get the full member experience.Join For Free
Beware the most common trap of technologists, which is becoming religious about a specific technology or vendor. This is what often leads to the unfortunate failure of a project or a product and also creates the incorrect measurement metric for a technology’s capability for success.
Take AWS for example. I’m a huge fan of AWS, but will not push it as a solution unless it maps to specific business and technical requirements. It is also important to note the order of the business before technical in the requirements chain.
Biz Requirements FTW
Before we launch into “We should use AWS for this because it’s where everyone is going” as our requirements, we have to step back. It’s really as simple as when our parents would say “Well, if your friends jumped off a cliff, would you do it, too?”
Starting down the path with a solution in mind can be a huge contributor to the failure of a project. This is a common problem among the business world as we lean into our internal IT organization to look for how to solve problems with technology. We are humans and are more likely to want to use something we are familiar with.
If you’re asked to find the right tool to get a nail into a piece of wood, you are probably not just going to say, “We need a hammer,” you will probably say “I need to go to Home Depot and get a hammer.” Even further to that, you may say “I need to get an Estwing hammer,” which is where this maps to our IT practices.
Religion of IT
The IT ecosystem tends to create nearly religious allegiance to products and vendors. When someone asks you to pick a network vendor, you’ll most likely say Cisco. When you are asked which virtualization vendor to choose, you may say VMware. If asked about picking a web server, it may be Apache or IIS.
What I’m saying the challenge is here is that when asked the question, “Which product should we use?” the answer should be “What are the real requirements?” instead of asking about product vendors first. The vendor choice should be the last portion of it.
Taking the practice of systems architecture back to the roots is what we all need to do for ourselves to bring some more purity back. It isn’t that using a vendor product as a part of the evaluation and planning for a solution should happen. It is important that we remember that a vendor choice being made in the architectural design is both a requirement and a constraint. Constraints are generally best when avoided.
Requirements Over Religion
Take each of the requirements that you have and map them to solution alternatives. Only from there can we take the alternatives and then find which vendors and products will be the right choice. It isn’t that we become entirely agnostic to the vendor solution because we do have to choose a vendor one way or another. Unless you are building from scratch yourself, we make vendor choices regardless. Even when you build it yourself, you choose a language to write it in (ruby, java, scala, etc.) which means you’re making a vendor choice.
Think high level where you say, “The solution must…” and “The solution must not…” to begin each requirement. There should be no vendor names in those bullet points. Only once we list all of the requirements can we take the next steps of getting down to choices which will bring products into the decision matrix.
Will you lean towards familiarity? Of course. That should be added into the requirements. “Solution should integrate with existing standard operating procedures,” or “Solution should be chosen from existing partner vendors,” are other ways to bring a little preference into the native requirements. Those help to respect the needs of the business to maintain use of supported vendors and existing contracts. Again, we should use this sparingly as it makes us put religion over requirements.
Published at DZone with permission of Eric Wright , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.