How can you govern solution architecture?

Solution Architects are crucial in building the gap between business needs and technical solutions. Their expertise in technology evaluation, risk assessment, performance optimization, and integration are vital in creating efficient and sustainable systems. In my experience their ability to collaborate effectively with diverse stakeholders in aligning everyone towards vision for the project is the key role.

The good thing about architecture is that there are so many subject matter experts. But do they address real-world security issues? Are they conversant in NIST 800-207 or NIST 800-53? No! You can open your browser every day and find the latest examples of security architecture failures. No civil engineer or architect could get another job, and most would go to jail or be litigated into bankruptcy if the buildings and bridges they designed fell over like so much of what is designed by IT architects. So, back to the question about how you can govern it? I suspect nothing short of requiring professional certification from a standards body and an oversight board to revoke credentials when the equivalent of a building collapsing occurs.

A standard way of defining this is RACI (Responsible, Accountable, Consulted, Informed) Matrix in tabular format. It clears all doubts and helps to understand who is / are going to call shots. If you are working with Client-side Architect, clear contract definition helps to ensure that nobody steps on toes of others unnecessarily.

In order to govern a solution architecture you need to have a view of what good looks like. i.e what in the context of the organisation, constitutes an optimal solution architecture. Optimal in the context of solution architecture in my opinion simply means “best it can be” within the given solution constraints (time, cost, resource, regulatory etc). This in turn requires having clear principles about what an optimal solution architecture should address and how. Having clear best practice examples is very useful as is a library of recommended design patterns. The key point here is governance should be an ongoing process to help the solution architect create an optimal solution architecture rather than just being a quality gate at the end.

Most of the material here focuses on funded, mission or business solutions where the outcome of the "architecture", is implementation. Another context for solution architecture is as an offered, proposed answer or idea for purposes of sales, proposal, or other activity that may result in actual investment (as a starting point for a full lifecycle). As in the GovCon Sales/Growth community, organizing around usually incomplete or unclear requirements aligned to sales interests. The outcome of this kind of solution architecture is the opportunity and investment to proceed and execute on a fully-funded architecture (which may turn out quite different, but directionally-consistent).

TOGAF, Zachman are example frameworks. While defining a solution, one also needs to understand what the boundaries are at solution level, technology level, personal level, team level and combinations of it.

There are several widely popular frameworks to start with Solurion Architecture for information systems, as said TOGAF or Zachman however each Enterprise should tailor use of such frameworks to make them easy and quick to follow. Nobody likes enduring meetings for hardly understandable purposes so KISS and DRY are extremely valid principles in establishing Enterprise Architecture function. As for downstream Solution Architectures, don't reinvent the wheel, stay up to date with modern stacks and map your requirements to them.

If Architecture is not complex, you can use PowerPoint for designing diagrams. Organizations also use Confluence / Azure DevOps Wiki Pages to keep history of discussions, business drivers, stakeholder's comments and links to Architecture Diagram.

A standardised vocabulary is useful when communicating across different audiences. That might be as simple as an agreed dictionary of terms, or a formal UML document. One of the biggest causes of project failure is misunderstanding of requirements and solutions. Having a common language will help reduce this risk.

Often business, operational and technical metrics can be a great way to justify spend and ROI on architectural improvements and in-house development spend. Metrics, and rapid feedback brought about through visibility of what's happening in the organisation in realtime, is a key way to prove value of your stack. Consider metrics not just through the software maintainer or the support engineer's lens, but also through the business, customer and security lens. If you're building a solution, what value can you add for very little cost, by simply adding a log, or capturing an event to be made visible in another system?

There is no solution architecture, there are only architected solutions. The standalone project is a rare exception, in vast majority of cases there is a preexisting complex enterprise landscape of applications, processes and teams deposited over time. The work of the solution architect then is to weave a change or new addition into this landscape that reuses what is useful and preserves what works. Accordingly, the most important thing to learn is the landscape - both systems and people - that one will be working in.

Solution architecture should always have a peer/team/business review of the target state. This will provide proper communication to all those impacted and allow others to speak up or agree with the proposed solution. For more mature organizations there may be a Solution Review Board (SRB) or Application Review Board (ARB) that requires all proposed enterprise solutions to be presented to a committee representing data, security, infrastructure, architecture, and other teams for review and approval. Going through the above will help reduce solutions that don’t meet business requirements or don’t align with enterprise strategies across the organization. Also one will need to consider post go-live support of the solution architecture.

You should not try to *govern* the architecture.?? It is better to have an environment where the teams feel encouraged to collaborate in the design decisions that are needed to shape the architecture. Also the experimentation required to solve complex and chaotic problems requires an environment where the team feels safe instead of governed. ??