<p>This is the fourth posting in our “EA Roadmap for success” series. In this posting we zoom in on the <em>Architecture Board </em>and its role in making enterprise architecture a success within organizations.</p><h2/><h2><div class=”captionImage left” style=”width: 337px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Role-of-the-architecture-board.png” alt=”Role of the Architecture Board” title=”Role of the Architecture Board” width=”337″ height=”221″/><p class=”caption”>Role of the Architecture Board</p></div></h2><h2>Architects show up everywhere</h2><p>One of the things we stumble across in many organizations is that some people see ‘architect’ as a job title rather than a strategic discipline. The line of reasoning being something along the lines of “first you’re a designer / engineer / …, then you’re a really good senior designer / engineer / …, so if you progress from there, well, I guess that makes you an architect”. While there’s something to be said for senior staff to grow further, there is a real danger in calling them architect.</p><p>A key aspect of enterprise architecture work, is the holistic approach in which different perspectives on some system (business, it, or the enterprise at large) are unified and considered as a whole. Being an expert in one role, does not guarantee that one has the ability to “see the other perspective” as well, which may result in architects coming from different disciplines bickering about direction and solutions which eventually leads to high cost, low value add, low efficiency and a poor reputation.</p><p>An important task of the architecture board (AB) is to prevent this from happening. In the words of the TOGAF standard:</p><p><em>“This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture.</em>”</p><p>Typical responsibilities of the AB are:</p><ul><li>Establish an effective architecture team</li><li>Defining and maintaining consistency of architectures and sub-architectures, also across changing requirements with respect to the architecture</li><li>Enforce architecture compliance</li><li>Ensuring that the discipline of architecture-based development is adopted</li><li>Resolving ambiguities, issues, or conflicts that have been escalated</li><li>Providing advice, guidance, and information about the architecture</li></ul><p>These tasks get a different meaning, depending on the role of the EA-function in the organization. Below we will outline the main difference between the role of the AB in a top-down versus a bottom-up approach.</p><h2>Role of the AB in a top-down approach</h2><p>As we’ve seen in previous posts of this series, the main goals for EA in a top-down approach are to align with the strategic level of the organization. At first sight this implies that EA is about the implementation of strategic change. However, it should be noted that there is also the aspect of driving strategic change based on knowledge about the architecture of the enterprise.</p><p>In such approach, the main goal of the EA discipline is to be the linking pin between strategy and implementation: define projects and programs and make sure they deliver capabilities that help realize a chosen strategy. Of course, as we also have seen in the “embedding” post, the AB cannot do this in isolation, and has to cooperate with e.g. project management and delivery to make things happen. </p><p>Governance plays a crucial role in such approach. On the one hand the AB defines and approves projects. On the other, it works with other governance bodies (ie., security governance, data governance, etc.) at “lower levels” in the organizations, aligning their efforts and giving final approval / discharge when projects are done.</p><p>In that sense, the AB also has the responsibility to be an <em>enabler</em>: projects need resources (rooms, staff, machines, money etc.) to do their work effectively. If the organization wants to achieve certain results, and the AB is tasked with making this happen, then they should also have the power to make sure that projects obtain these resources. Since resources tend to be scarce, this usually results in a balancing act, working on priorities and risks, and closely cooperate with the project management office.</p><p>Last but not least, it should be noted that change does not happen overnight and is frequently met with resistance in the organization. The AB plays an important role in communication, building trust and commitment around certain (strategic) initiatives and the resulting change.</p><h2>Role of the AB in a bottom-up approach</h2><p>The role of the AB in a bottom-up approach to EA is somewhat similar, but with different accents. In a bottom-up approach, the focus of EA is on resolving operational issues, and assisting projects with sound architectural advice.</p><p>In this case, the role of the AB can also be seen as “enabler”: making sure that operational issues are prioritized, that resources are allocated accordingly, and bringing together different perspectives on these operational issues in order to resolve them as effectively as possible. We frequently see that the AB is populated with (upper) management in order to make sure that decisions can be made, that the right staff is brought together in mini-projects to tackle important issues head on. This avoids the bureaucratic hassle as well as “not invented here” syndromes.</p><h2>Board structure</h2><p>To conclude this posting we dive into the board structure. This part is inspired by the TOGAF 9.1 standard as well as several engagements with clients over the last few years.</p><p>First of all, key to success is to get the right people on board. In both a top-down and a bottom-up approach, we typically see a mix of (senior / upper) management and lead architects for different ‘domains’ (which in this context may either mean ‘field of expertise’ such as data or security, or it may mean a line of business). A management assistant to take notes, log action items etcetera tends to be indispensable as well.</p><p>This brings us to the second issue: key to success is transparency. Everything the AB does, and particularly every decision that is made should be documented and made available for the entire organization. This greatly improves trust and visibility, which is key to getting results. Typical items for publication are:</p><ul><li>A manifesto that describes the role and responsibilities for the AB</li><li>Agenda of upcoming meetings </li><li>Minutes of all AB-meetings</li><li>Links to <em>architecture regulations </em>such as strategies, policies, principles and standards</li><li>Compliance assessments and Governance log </li><li>Open and past action items</li><li>Etcetera</li></ul><p>If you’d like to know more, please contact the authors directly at <a title=”b.vangils@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”s.vandijk@bizzdesign.com” href=”mailto:b.vangils@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series covers open approaches for EA. It is scheduled to be posted on the 8th of january 2013.</p>
