“Impossible only means that you haven’t found the solution yet.” – Anonymous.
- The overall Solution/Service should be owned, shaped, and engineered in the sales phase by an experienced Solution/Service Architect/Design Authority who continues into the delivery phase.
- The Solution/Service Architect/Design Authority must be empowered, experienced, and commercially-aware to maintain the solution vision, make decisions regarding design/technical conflicts, change, risk mitigation and the impact of change.
- On major delivery contracts the Solution/Service Architect/Design Authority should be a team rather than a single person.
- Avoid confusing the Solution/Service Architect/Design Authority and Development/Production leadership roles; the former keeps the solution vision and the latter drives system, software or service teams to build the solution to plan.
- If the contracted scope of the Solution is vague then always resolve this at the outset; never try and muddle through.
- Always have a clear Controlling Specification with supporting External Interface Specifications to set the requirements and boundaries for the Solution.
- Produce Controlling Specification and supporting interface specifications that are clearly articulated, unambiguous, and supported with compliance matrices that formally trace to mandatory higher level requirements.
- Always agree Controlling Specification and Interface Specifications with the client and apply rigorous configuration and change control to this baseline.
- Use appropriate support tools to produce and maintain a written Solution/Service Design Specification or equivalent; ensure the design is traceable to the Controlling Specification, addresses requirements such as performance, reliability, availability, service levels, maintainability, and also captures key design decisions clearly.
- Cultivate a ‘design, build, test to specification’ mentality; strive for solution design simplicity and always avoid ‘gold plating’.
- Design to de-risk a solution; never build risk into the design – avoid using new techniques or concepts where existing well-proven concepts will do the same job simpler and cheaper.
- Always design security, privacy and safety aspects into the Solution from the outset.
- Where Products form part of the solution, ensure the overall Solution design is componentized to cater for upgrade paths or product replacement; never modify (as opposed to configure) a product or kernel supplied by a third party.
- Avoid, where possible, designing a Solution that is reliant solely on a single specialist or new product from a very small company; always have and alternative product fall back option in case the supplier fails to deliver or goes out of business.
- Ensure that changes made to the Solution are controlled, formally authorised and preserve the solution’s overall integrity – avoid irresponsible or uncontrolled changes, especially in the later stages of a delivery lifecycle.
- Conduct regular design reviews of the Solution and it’s compliance with the Controlling Specification baseline; use relevant experienced staff external to the delivery team and address any identified shortcomings quickly.
- Conduct a ‘critical design review’ of the Solution prior to moving to the next lifecycle phase or service production activity; use this to confirm the solution meets requirement, architectural, technical and commercial objectives adequately enough to proceed without undue risk of failure.
- On major delivery contracts ensure the Solution/Service Architect/Design Authority team has the right mix and calibre of people to take collective responsibility for whole Solution such that unforeseen loss of a team member does not impact.
- Continuously educate and update delivery team(s) on the Solution matters; liaise with the client on Solution matters using proper established Solution governance mechanisms.
- Remember – you have no solution without an experienced controlling architect or design authority.