- Adaptive Enterprise
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 sixth posting in our “Enterprise Architecture Roadmap for success” series. In this posting we zoom in on the implementation and embedding of an enterprise architecture practice in an organization.
Enterprise Architecture Project based implementation
In one of our discussions during a client engagement we came across the following remark by one of the Enterprise Architecture’s in the organization: “Enterprise Architecture is about everything the organization is and does”. This remark supports our experience, and is one of the reasons that many companies struggle to effectively adopt and embed Enterprise Architecture in their organization. Enterprise Architecture has many stakeholders and, depending on the approach taken i.e. top-down or bottom-up, from various levels of the organization.
Enterprise Architecture touches on many aspects of the organization such as business and IT alignment, strategic portfolio management, project management, and risk management. Enterprise Architecture is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of Enterprise Architecture in the organization is typically approached as a project: with clearly defined goals, metrics, stakeholders, and appropriate governance, accountability, and with assigned responsibilities in place.
From our experience, the road to a strong, effective, and mature Enterprise Architecture capability should be broken down into manageable pieces. We favor evolution, rather than revolution. Too many times we have seen initiatives fail due to the sky high expectations to be delivered within unrealistic time frames. Implementing Enterprise Architecture is a change initiative that besides processes, tools and other hard and tangible artifacts includes many “soft aspects”. These soft aspects need to be managed as such, involving mainly frequent, clear and honest communication with feedback and iteration.
The first step is to decide on the ultimate goal for the Enterprise Architecture function: where is the Enterprise Architecture organization positioned, who are the most important customers of Enterprise Architecture, and how does Enterprise Architecture deliver value to its customers? In the first postings of this series, the ones in the “aiming” category, we covered a number of important choices for the organization to take: are we following a bottom-up, or rather a top-down approach? How does Enterprise Architecture tie into strategy, project management, the corporate governance framework, and security?
Depending on the approach chosen, the next thing to do is to establish a project team that will be tasked with drafting high level plans for the implementation and embedding of the Enterprise Architecture capability in the organization. The plans should describe a long-term (say 3-4 year) strategic vision for the Enterprise Architecture capability, as well as a plan outlining the concrete initiatives for the short-term (say the first year).
It is one of the important tasks for the Architecture Board to provide input for the strategic vision for the architecture function, and then select the right members for the project team (see also the previous posting on “the role of the architecture board”). The team should reflect the various areas and domains of the architecture, and the members should be able to look at the organization on a higher level, above the individual silos. The project team should interact with the AB frequently to make sure the efforts of the team keep aligned with the envisioned direction. In the next posting we will delve into more details around the Enterprise Architecture project team.
Once the team and high level plans are in place, it is time to kick off the project. The team will take the high-level plans and preliminary decisions, such as the proposed architecture framework as a starting point, and from there make more detailed plans and start identifying and prioritizing a number of initiatives. These first initiatives should not be seen as “architecture” projects per se, but rather pertain to the question: “how do we do architecture”. Or, according to TOGAF9: “where, what, why, who, and how we do architecture”.
Aspects in this context that need to be determined and confirmed in the first phase are (not complete!):
As mentioned before, these aspects should be considered both from a strategic, long-term perspective, as well as from a short-term perspective. This, together with the general approach for Enterprise Architecture chosen (e.g. bottom-up, or top-down) determines priorities and thus the order in which things should be done. For example, detailing and determining interaction of EA with other management frameworks should be done for the project management framework earlier and in more detail if a bottom-up approach is followed.
The exercise of determining scope and assessing current and desired maturity leads to a roadmap for the development of the architecture capability. With the order of activity based on various indicators such as approach chosen, prioritization, organization culture, sponsorship, etc. This road map guides the Enterprise Architecture project team in their day-to-day activities. It is a task of the AB to make sure that the road map remains accurate and aligned with business strategy. The road map should be assessed frequently, say each half year, and necessary changes should be made accordingly.
To conclude this posting we would like to point Enterprise Architecture project teams, especially in organizations that chose to adopt the TOGAF to an interesting section in the standard. In chapter 46, TOGAF describes how the ADM (Architecture Development Method) can be used as a tool to implement an Architecture Capability. In this approach, the “business architecture” of the Enterprise Architecture capability involves the organizational structure of the Enterprise Architecture capability, and architecture processes such as governance. The “data architecture” pertains to the meta model, and the Architecture repository that the Enterprise Architecture capability uses to describe architecture, and store architectural artifacts. The “application architecture” and the “technology architecture” describe functionality and the tools (modeling tools, document management systems, etc.) that need to be deployed to support the architecture capability. Using a structured approach as suggested in the TOGAF standard helps an architecture team to draft complete and clear plans. A number of iterations of the ADM can be defined to evolve the maturity of an EA capability.
If you’d like to know more, please contact the authors directly at email@example.com / firstname.lastname@example.org, or leave a comment. The next post in this series covers the establishment of an EA team. It is scheduled to be posted between february 11th and february 15th.