in recent articles, I’ve written about good and bad practices as well as what could be conceived as bad practices or anti-patterns coming from architects.
At face value, it’s not the full story and may only be a few aspects, or potential faults, in what may otherwise be effective architecture. Architects come from all different perspectives with different ways of seeing things and different approaches to problems. They come from different backgrounds from different organizations which helped to mold their worldview of architecture.
Some people may be better at delegating, leading, and inspiring people to do their best work whereas others may be more intense thinkers and problem solvers yet still good at collecting and then conveying information to the right people. Some people may be exceptional yet still have communication challenges or perhaps inexperience with very fast moving operations which leaves them struggling to maintain alignment without having additional support. Others may have most of the high quality attributes necessary to be an effective architect, yet still with opportunity to grow.
To be clear, there are a core set of competencies that architects need to have to be effective, and architects should be held to that standard, yet as we see above there are ranges of qualities between different architects.
An effective architecture practice needs competent architects, but it also needs culture, methods, rules of engagement, gating, and operating procedures in order to be effective and to establish a baseline of how an effective architecture practice operates.
You don’t want your architecture practice to be too rigid because rigidity actually slows competent people down, but you need to strike the right balance in defining your architecture practice to ensure a minimum level of quality outcomes from your diverse architecture team, and this is not a one size fits all approach.
For example, operating procedures and gating can help ensure that accountability is properly delegated to a SME for implementing certain significant facets of the architecture. Security teams can take ownership of security facets of architecture with gating processes requiring sign off by security team and CISO to move forward with security designs which also serves to shift accountability for those controls to security teams.
Workflows can be introduced and systemically enforced to ensure that architecture or the delegated SME reviews completion of work that are significant to the architecture, or review, by process, work that is significant to the architecture that is not complete within agreed upon milestones – this sets the stage to identify risk in-flight and to ensure mitigation is in place (business risk acceptance, re-work, re-design, etc).
These are a few examples, and they may or may not be necessary depending on the organization, its culture, its business, and its historic operating success.
Establishing the right balance of practices within your architecture practice is an iterative journey which requires some amount of experimentation and validation. You may have to remove things that are not working and slowing the team down, only to add additional refined practices later that help establish a minimum standard of quality outcomes.
It’s important to observe how things are currently working and provide a qualitative measure to them in order identify areas of potential improvement.
Brainstorming and alignment with the broader team will help provide a mutual understanding of why things may not be working well, or even provide clarity as to the things that actually are working well but may have been perceived to not have been working well — of course this leads to discussions on perception and how to improve perception. This will lead to more effective iterative practices within the architecture practice.