Techinical Architect Design Goals

Posted by JD 07/08/2009 at 13:40

As a technical architect, I’m pulled in many different directions when working on solutions design. Some include:

Solution meets the majority of must have requirements
Solution provides exceptional value to the customer
Solution needs to meet security requirements
Solution advances long-term technical needs
Solution can be leveraged for future, unknown, needs
Solution is open whenever possible to avoid single-vendor lock-in
Leverage existing available infrastructure, unless it has been proven a poor choice
Costs – deployment and annual maintenance must be considered
Solution must include the smallest number of components; the fewest moving parts. KISS, Keep It Simple Stupid, methodology.
Minimize support complexity. Complex solutions that can’t be easily supported will eventually fail. They cause too much trouble to use.
Ensure customer satisfaction by clear, concise communication with the customer and team on the expected outcomes, issues, and schedule. Provide public and private points for feedback from anyone on the team to say good and bad things. Sometimes failures can be avoided in this way.
Solution must support future migration to a different, competing vendor. Be certain that customer data isn’t locked up inside a complex system that can never be moved.

So, when you begin working a project that includes updates to the technical infrastructure, consider that your solutions designer will be trying to merge all these interactions into the best possible solution for your needs. Sometimes there is not a clear best solution and just a non-worst solution must be selected.

As a customer, I often find that our needs are ahead of the solution availability curve. No solution currently exists so we need to revisit the solution space in a year or two.