Design Governance
Ensuring IT solutions meet organisational standards and strategies. In a nutshell, that’s it.
In this section we’ll cover:
- What is Design Governance?
- Why bother?
- Who is involved?
- How does it work?
- Solution Architect role?
- Solution Architect required skillset
What is design governance?
Every moderate to large organisation will have a view on how their technology estate should operate. Design governance is the process by which proposed IT solutions are reviewed, approved and implemented. The tools, technologies and standards that provide the best blend of factors including cost and flexibility.
A Spanish Inquisition?
Not at all. At least it shouldn’t be. The personalities involved play a big part in the ‘friendliness’ of such forums. As does the leadership and character shown by the session chair. Understand that people all have their own quirks.
Be clear about what is in and out of scope. Scope expansion such as inclusion of more systems, business areas etc. are likely to affect estimates far more than individual requirements.
Why?
Managing complexity. It’s that simple. Large organisations have hugely complex, diverse technologies. Like all things in life, time changes everything. Approaches to solving problems change. Technologies and tools evolve. People come and go, along with their opinions to problem solving.
Using standardised technologies, tools and standards provides several benefits:
- Managing a standardised set of technologies, tools and standards is, all round, easier than a diverse one
- Cost savings from re-use
- Adherence to a divisional and organisational strategic view
Complexity is an unavoidable inevitably. The best we can do is put in place mechanisms to manage it.
Who’s involved?
A small to medium organisation may have a single design authority. Large government entities or corporations are likely to have several. For example, different divisions of a large bank are likely to have a design authority aligned to each division.
Each design authority typically has a single representative from domains including security, infrastructure, information (data) and Enterprise Architecture. Each domain representative reviews the design and ensures it meets the standards relevant to their specific area.
A hierarchical structure of design authorities is common in large organisations. The structure of these can vary a great deal. A Solution Architect typically works within application design. Dedicated forums can exist for areas such as security.
Building a Rolls Royce or a Ford?
The standards required in some areas of design can be overwhelming for many projects. Not every solution needs the same level of compliance. Sensible, frank conversations are required to ensure the most appropriate solution is implemented.
What good looks like varies between different people
Design forum domain experts are custodians. They are held to account on ensuring designs meet the standards of their respective areas. What good looks like to them is meeting those standards to a high degree. Their accountability is measurable and long standing.
A project and the team delivering a solution (and its design) is a transitory thing. They provide a solution to a problem and often disband. What good looks like to the project is delivering on time, budget and with minimum risk.
Understanding this concept is essential. It enables a Solution Architect to identify points of potential contention early and initiate the appropriate work to reach an informed compromise.
It is essential that you know the individuals who will approve your design. Speak with them personally. Let them know your early thoughts on approach. Get their feedback.
How does it work?
First and foremost, the design forum is not the place for design work and debate. It is the place where experts from various domains come together to discuss as a group something they should already understand.
- Organisation defines its high, mid/low level standards and best practices
- Solution Architects produce a design that meets those standards
- A review slot with the design forum is booked and a copy of the design is shared with reviewers
- Reviewers meet to discuss the design and approve or decline the proposed solution
Attend a session of your specific design authority before taking your own design. It will allow familiarisation with the format, protocols and general tone of the session. You’ll get invaluable insight into many aspects of the process and characters involved.
Role of the Solution Architect in a design forum
- Ensure the requirement is clear and measurable
- Understand the constraints and dependencies that the solution must take account of
- Familiarise yourself with the standards, policies and protocols of your governance area
- Document the most pragmatic, clear and concise solution possible
Get comfortable with the fact designs are often a compromise. In many cases the resulting design will not meet all standards or expectations. Your role is to present a clear, informed, pragmatic proposal.
Design Authority Skills Required
- Pragmatism - More often than not a solution design will be a compromise. Time, cost, technical constraints are all factors that influence any proposed solution.
- Communication - You’ll need to convey your proposal in a concise, clear and effective way
- Confidence - If you’ve done your prep, spoke to people ahead of time, you should know the outcome. I say know the outcome rather than ‘get approval’ because there are times when you know approval won’t happen but there are reasons for attending. Another story…
Key Takeaways
- Identify who’s signing off your design
- Speak with these design signatories ahead of submission
- Attend a design authority session prior to your submission
Related topics
- High level solution design - TODO