- 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 seventh posting in our “Enterprise Architecture Roadmap for success” series. In the previous posting we started to describe actionable steps that an organization needs to take in order to set up Enterprise Architecture. We described how organizations should approach Enterprise Architecture implementation as a project, with clear and confirmed ideas on scope, leadership, budget, and planning. We mentioned the establishment of a project team that will be responsible for an effective execution of the project plans. In this posting we zoom in on some of the characteristics of an Enterprise Architecture team.
Roadmap for success part 7: Establish an Enterprise Architecture team
Implementing and evolving an Enterprise Architecture function in the organization requires a whole range of roles with specific characteristics, competences, skills, and qualifications. What the most effective team for a given situation would be depends on many factors. These factors include “hard” ones, such as organization size and structure of the organization, and available resources, but also on “soft” aspects, such as culture and “political atmosphere”. These “soft” aspects are usually established through a long tradition and history, and are thus the more tough ones to change.
Building a successful team also depends on the approach and vision for enterprise architecture that an organization pursuits. In one of the first postings of this series we described two extreme approaches: top-down and bottom-up. In a top-down approach the role of enterprise architecture is more focused on supporting high-level decision making on the strategy level. In a bottom-up approach, enterprise architecture is positioned much closer to the actual operations. In this approach Enterprise Architects role is to materialize on synergy among the numerous projects (in-flight, as well as planned) by introducing standards for processes, reference architectures, and governance. In the remainder of this posting we will describe typical Enterprise Architecture team characteristics for both approaches.
Building the Enterprise Architecture team
The initiative to establish an Enterprise Architecture function that supports the organization solving the question “how should we organize ourselves” on a higher level often comes from executive levels, i.e. the CIO. The initiative is often driven by a need or feeling that the answer to this question is not yet very well understood, can be diverse and/or complex and the organization needs a multi-perspective, and creative yet structured approach to solve the puzzle. Typical situations could for example be mergers and acquisitions, or when an organization feels that more foundational changes to the business model are necessary in order to survive.
The role of enterprise architecture in this approach is to provide better insight in the organization and its high-level constituent parts in terms of people, processes/functions, and technology. Often based on high-level models, Enterprise Architecture supports the definition of the necessary change by providing impacts of suggested changes on the current organization, combines multiple perspectives such as the financial perspective, the risk perspective, the operational perspective, the perspectives from the various areas of the business in terms of location, function, etc.
The role and position of Enterprise Architecture in this approach has a number of implications for the members of the team that is responsible for setting up the Enterprise Architecture practice. Because the scope of Enterprise Architecture in this approach is often the whole enterprise, it is an important aspect that the team has to reflect the various areas of business. For larger global organizations this means that the regions need to be represented. Or for diversified organizations, this means that the various lines of business need to be represented. Another important aspect is that members have a broad overview of the architectural landscape for their individual areas. This is why we don’t see many domain architects, such as data, application, or business process specialists on Enterprise Architecture teams in this situation. It is not easy to name typical roles in the top-down Enterprise Architecture team, but in general we could state that in the formal reporting hierarchy they are within a few steps from the CIO.
As we have described in one of the first postings of this series, the role and position of Enterprise Architecture in a bottom-up approach contrasts heavily with the top-down approach. In a bottom-up approach, the scope of the change is much more defined in terms of objectives and value, and also it is more clear what the architecture footprint is, i.e. the parts of the organizations on which Enterprise Architecture has an impact (provides value). Often, the Architecture Board was heavily involved in the definition of the objectives, and approach for Enterprise Architecture, now the execution of the plan will be the responsibility of the Enterprise Architecture team. In this situation the Enterprise Architecture team will often detail the approach into a working plan, and the implementation process will be governed with this working plan as starting point. The Enterprise Architecture team will frequently, often as much as every two weeks with the Architecture Board to discuss progress.
In this situation, the Enterprise Architecture team requires representation from the various functional areas within the scope of the organization. Often these areas are data, technology, security, application, etc. Important characteristics for Enterprise Architecture team members are seniority and expertise in their area, and also some history in the organization, which is important to more successfully navigate the political waters.
Although the task at hand seems much more straightforward for the bottom-up team, there are still plenty of challenges on the road. Especially the “relationship management” part of the task requires sufficient social skills. As mentioned earlier in the series, Enterprise Architecture cannot operate in isolation. Strong relationships need to be established and maintained with customers of Enterprise Architecture, in this approach e.g. mainly the project organization.
The top-down team
If you’d like to know more, please leave a comment. The next post in this series covers tooling for Enterprise Architecture. It is scheduled to be posted between 25th February and the 1st of March.