Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the third posting in our “EA Roadmap for success” series. In this posting we zoom in on the embedding enterprise architecture within organizations: EA can only be successful by linking to, and aligning with other disciplines in the organization.
Second blog under 'aim'
When assessing the effectiveness and strength of an organization, one may use the weakest link principle: the capability of the organization that is least developed will – in many cases – largely determine the outcome of such assessment. This is particularly true if these capabilities are in the primary processes. However, due to a long tail effect, secondary processes and capabilities can also have a significant effect. For such analysis to work, of course there should be a chain to begin with! In other words, EA cannot and should not exist in splendid isolation!
This implies that EA should be firmly embedded within the organization at large. Key questions that organizations should answer in this respect are: what do we want to achieve with EA? Which KPI’s do we use to measure success of the investment in our EA practice? Who is responsible for EA? What is needed to make EA a success in terms of partnerships (with other capabilities) and other means (tools, offices, staff etc.)? Answering these questions is not an easy task.
Goals & approach
In our previous post we discussed two approaches for EA: top-down (aligning with strategy) and bottom-up (aligning with projects, closer to operational issue). In each of these approaches, one should clearly specify the goals for EA. This may seem like the proverbial “open door” but judging from what we see in practice many organizations seem to have forgotten to either define, or communicate the goals of their EA team. All too often we see the EA team working hard and seemingly doing their work well, only to find out that expectations were different.
Depending on the approach that is taken, we see different types of goals, and consequently also different ways / levels / capabilities to interact with when embedding the EA function in the organization. As each organization is different, it seems hard to come up with any definite list of advice on how to approach the subject. Therefore, we will illustrate our point with some examples
Supporting strategy: Let’s start with a goal that clearly fits in a purely top-down approach, supporting the strategic team of the organization. Strategy typically consists of an external part (how to position the organization with respect to the environment) and an internal part (how should we organize ourselves?). For both, we see organizations battling with n-year plans (pick a number for n) and “statements of direction” for the upcoming n years. Unfortunately, in many cases these statements have little (modeling) rigor and do not resonate well with many groups in the organization. Embedding EA in this case could mean: support processes at the strategic level of the organization by bringing a rigorous model-based approach to the table, based on e.g. the business model canvas (Osterwalder), or capability based planning (TOGAF).
Supporting project management: at the other end of the spectrum, a purely top-down approach could imply that the organization’s change- and project management discipline is to be supported with architecture. In this case, embedding EA could mean such things as supporting the program office in building roadmaps, supporting project managers in effectively starting up projects and assessing impact analysis using a Project Start Architecture (also called Contract in TOGAF). This should, of course, be started early on in the project lifecycle!
Supporting governance: most organizations juggle many different types of governance, ranging from financial governance, health regulations, standards, policies and so on. Each discipline has a unique perspective on the organization. Embedding EA in such a context could imply the start-up of a joint meeting where governance-related issues are discussed on a bi-weekly basis. A solid standards base (see our series on standards management) and architecture models (for example in ArchiMate®) can greatly improve the effectiveness of such meetings
Security: like governance, security is pervasive and potentially touches all aspects of the organization. One of the harder parts of security-related work is threat assessment and assessing the reach of security measures. Simply put: where are we vulnerable and what will the impact of a specific measure be? In such a situation, embedding may mean: setting up detailed models for analysis, as well as high-level models for communication, linking to governance and project management to make sure that measures are implemented correctly and in a timely manner, and so on.
Role of the Architecture Board
If we accept the premise that aligning the architecture function to its environment by embedding it in the organization at large – or putting it differently, that it is to support the organization / enterprise – then it makes sense to institutionalize the ability to steer the architecture capability, making sure it continues to deliver value. Usually this group is called the architecture board (AB). This AB has various roles and tasks, depending on the context. We will zoom in on the AB in our next posting!
If you’d like to know more, please contact the authors directly at firstname.lastname@example.org / email@example.com, or leave a comment. The next post in this series covers setting up and maintaining the Architecture Board. It is scheduled to be posted on the 25th of December.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: