I am looking for insights on establishing an Architecture Review Board (ARB) within our organization. As we aim to enhance our architectural governance and ensure alignment with our strategic objectives, we recognize the importance of setting up an effective ARB. To this end, I would greatly appreciate your guidance on the following aspects:       1. Establishing a Charter: What key elements should be included in the ARB        charter to clearly define its purpose, scope, and authority?       2. Member Selection: What criteria should we consider when selecting members for the ARB to ensure a diverse and knowledgeable board?       3. Review Process: Could you share best practices for structuring the review process to ensure thorough and consistent evaluations of architectural proposals?       4. Decision-Making: What are effective methods for making decisions within the ARB, and how can we ensure transparency and accountability?       5. Documentation and Communication: What templates or tools would you recommend for documenting reviews and communicating decisions to stakeholders?      6. Measuring Success: How can we establish criteria for measuring the success and impact of the ARB on our architectural practices? Your expertise and experience in this area would be invaluable to us as we embark on this initiative. Any additional insights or resources you could provide would be greatly appreciated. 

This is a high workload to be done in one Board. My advice is to have one enterprise architect, CIO and another member who will be selected based on the application structure and IT Org structure it self. Let me know if I can help.

Firstly congrats on setting up a structure and asking the right questions. Here's my take having implemented over 20 Architecture Boards for organizations spanning public and private sectors. 1. The charter and objectives of the ARB should be pragmatic. Gauge your organization's tolerance to review boards, and ensure that buy-in from stakeholders is established ahead of establishing the organizational and operating model as it relates to the scope and review governance - i.e. what domains will you cover (based on your current capacity and skill sets). What principles have you already established, if there are deviations or exceptions what would they be (this is key so you don't boil the ocean with ARB requests) and the authority i.e. will you approve and reject designs, will you establish Architecture by design principles baking in Privacy, security and architecture standards, how do you ensure that corrective actions or remediation plans are enforced, and lastly are you adopting methodologies or frameworks like Zachman's or TOGAF? - And what is your meeting cadence i.e. once a week or based on demands. 2. I always ensure that we have SME's based on the domain i.e. technology should have operational SME's in attendance as they will be implementing the design, this avoids the hierarchal command and concur impacts. Always have a Privacy and Security representative, Chair, a BRM or BA, and Program manager. 3. So the review process should always have a degree of separation and objectivity - you don't want your architect designing the solution to also review the solution. - example: We have augmented development teams ( we provide them with the principles and reference architecture) they design the solution based on our templates for SDS (COTS with enhancements) - turn around 3 days from submission HLD (Conceptual design) 5 days from submission LLD ( low level - **** ALWAYS ensure that you have traceability from the requirement to design fulfillment and expected outcome) 5-8 Days from submission. Always record using AI or some other means to ensure you can demonstrate completion and compliance should the initiative be audited. - You can use a checkpoint approach i.e. 0 - conceptual, 1, logical 2/3 physical and 4 - closeout (ensuring what was designed is in accordance to the proposed architecture design) 4. Decisions are not done in isolation, should follow the Approved / Approved with Conditions / Rejected / Deferred approach. and justification for the decision should always be established this inevitably will end up as a reference architecture or precedence. 5. I mentioned above. 6. Success should always be traced back to business capability and strategic org goals and objectives - you can measure based on cost , adherence to to standards, principles and guidelines, and the success indicator could be the % of projects complying with standards etc. - excuse the novel and grammatical errors I did it during a ARB session :) - btw AI was not used in this response and I may have missed a few things. - Feel free to reach out and I can share examples of the ARB operating model.

I would start with your goals and the question which kind of architecture you want to review. Also consider context: how strong is your mandate, how mature the organization that "does" the architecture that should be reviewed. How much capacity is required from your team and the others. What is the value, for you, them, the overall organization => that should be quantified and measured. Based on such thoughts I would assemble the team and (depending on your mandate) discuss the operationalization with them.

Also: There are good Gartner papers on "Adaptive EA Governance"

I would offer one insight - which is that the Enterprise Architect as a role, in my opinion, should be a Leadership Team position. It's such a critical role for the organisation that can drive real value with often competing perspectives and legacy situations, and enabling the technology vision and roadmap really takes a voice at the table independent of business/functional areas. Leveraging a technology where you then catalog and map technology decisions, capability models, roadmap status (Decom, Tolterate, Invest etc) - like LeanIX - can then drive accountability and access to information across the organisation.

We have a Technical Archiecture Group (TAG) along with a charter that includes Executive Sponsor, Chair, Secretary, voting members and supporting members. Many of the member are from different technical areas i.e. cyber, engineering, soft dev, end user, BI, risk, and project management.   We have a technical checkoff list for new solutions that we vet against our standards.  This group does not have the authority to say "no", but we address all of our concerns and risks, provide that back to the initiator and rarely do we move forward with something that we don't support.  TAG does not have any budget or project management approval, but a project can not proceed without going to TAG.  

We require the initiator to present their solution and be available to address it to the group. In more complex solutions, we have a technical call with the solutions engineer so we can ask more details.   The group then discusses it and completes a feedback form stating their support, concerns, and anything else that needs to be addressed.    In essence, they vote in a range of 1-5 for the support of the solution/design change.  The TAG chair collects feedback and writes a summary.  This is provided to the initiator.  If there is little or no support, we have additional meeting to discuss this.  All of this process and documentation makes the auditors very happy plus we know what we are introducing into our environment.   

We use a SharePoint site for management of this group.  We meet monthly and have the option for an emergency if needed.  Having a strong and engaged Chair is key as this role requires some administrative skills as well as being a good business partner.  Consistency is key. Organizational buy it is a must.  Hope this was helpful.