Category Archives: Evaluation

The Role of the Enterprise Architect as a Sherpa

When thinking of the role of an enterprise architect, I came up with the idea of comparing the enterprise architect with the role of a sherpa. In government, a sherpa is a person who represents a head of state or government and prepares international summits, especially the G8 summit. Sherpas meet before the official summits to analyse and prepare the decisions or agreements. This reduces the effort required at the official meetings considerably.

In addition, the sherpas are generally responsible for elaborating on concepts and explaining them to the corresponding head of state or government. That means that they are responsible for the briefing of, and knowledge transfer to, the head of state or government so that this person is prepared for an official meeting.

The term sherpa refers to the Nepalese ethnic group, the Sherpa people, who guide and support expeditions in the Himalayas. In government, the term refers to the fact that sherpas pave the way for the official meetings and agreements. You could also think of the sherpas as bearing the brunt of work in preparation of the summits. The sherpas are assumed to be quite influential but in general they do not have the authority to make final decisions or agreements.

The role of the enterprise architect is very similar to the role of a sherpa in government. Enterprise architects work towards official meetings where architectural decisions are taken. This might be a meeting of the architecture board or any other governance body in charge of architectural decisions. In preparation of these meetings they elaborate on architectural options and any deliverables and artifacts that are required to evaluate these options. All architectural options should be analysed and evaluated upfront to the official meeting so that these meetings can be conducted efficiently. In opposition to the government domain, the architectural options should be evaluated objectively, based on clearly defined metrics/KPIs, i.e. architectural decisions shouldn’t be taken for purely political reasons (cp. ‘No Politics, Just Great Architecture‘).

Analogous to the role of the sherpa, the enterprise architect is responsible for the briefing and knowledge transfer to the stakeholder so that this person is able to make decisions within the official meeting. Depending on the stakeholder’s character and knowledge on architectural topics, this could require much effort and sometimes constrains the options you are able to discuss within the official meeting. In this spirit the enterprise architect paves the way for the official meetings and decisions. He/She bears the brunt of work in preparation of these meetings.

In summary, the role of the enterprise architect and sherpa are very similar. They take a back seat and focus on methodology, concepts, options, knowledge and facts. Both strive for an efficient and effective decision process and are intensively concerned with the exchange of knowledge prior to an official decision meeting. Therefore, they are quite influential but do not make decisions on their own. Nevertheless, enterprise architects should be objective in any case whereas sherpas often act with a hidden political agenda that is driven by individual or personal interest.

No Politics, Just Great Architecture

A few days ago a friend of mine changed the short description of his business on his Linkedin page to the slogan: ‘No politics, just delivery.’. What a brilliant slogan! He’s working in the IT project business for many years and I assume that he’s tired of all these projects that are heavily influenced by politics. Of course each nontrivial IT project has to deal with miscellaneous stakeholders and their conflicting objectives/requirements including politics but I think he’s referring to those ones where politics dominates and sometimes leads to strange decisions and project conditions.

Transferring his idea to my primary business of (enterprise) architecture management I adopted it spontaneously to ‘No politics, just great architecture.’ because sometimes there is architectural work that is heavily influenced by politics too. When I spend a few more thoughts on it I was struggling with the adjective great. Of course there is no great or even bad architecture. Remembering the very basics of evaluating architectures an architecture always has to be considered in its context that is framed by the specified requirements (including objectives, principles, constrains) that it has to fulfill (see [ClKK2002, Mali2008]). So it’s much better to characterize it as a capable architecture, i.e. an architecture that fulfills all the requirements that are imposed to it, but ‘No politics, just capable architecture.’ doesn’t sound so smashing… 😉

Anyway there is still the question how to deal with such situations which are heavily influenced by politics. When looking at the enterprise architecture discipline in particular what should an enterprise architect do if he realizes that he is doing architectural work in a politics dominated environment? Furthermore from my point of view it is interesting if there are any best practices or strategies how to cope with such challenges. When looking at TOGAF for example (see [TOGAF2011]) there’s no special chapter or topic explicitly dealing with this question but of course there are a lot of basic methods, guidelines and techniques described in this framework (e.g. architecture requirements management, stakeholder management) that provide the foundation for coping with such situations.

When thinking of the most important pillars of this foundation I came up with the following ones:

1. The role of the enterprise architect should be executed in an objective manner

The enterprise architect role is responsible for providing a capable (alias ‘great’) architecture that fulfills the requirements imposed to that architecture as good as possible. When investigating and evaluating the architectural options the architect himself should be objective, i.e. he should adhere to the facts and should not rely on personal flavor. You might say: ‘Yes, of course!’. Sounds like simple logic but it isn’t… According to Bass, Clemens and Kazman there are four major factors that influence the development of an architecture: Stakeholders, the developing organization, the technical environment and the architect’s experience (cp. [BaCK2003, p. 9-12]).

Source: On the basis of [BaCK2003, p.11]

The latter characterizes the fact that within the development of an architecture the architect gains additional knowledge and extents his experience (cp. [BaCK2003, p. 11]). A successful implemented architecture will inspire an architect to design a similar architecture for another project. An architecture that fails to deliver the expected requirements (including objectives, principles and constraints) is unlikely to be chosen second time. If an architect has little experience with respect to an architecture, architectural building block and/or architectural pattern it is less likely that he will take it into the range of design options.

Therefore an architect should be beware of the fact that his experience influences the architectural design process. In addition he should be open and curious in relation to previously unknown or unapplied design options. These might be the better ones although they were not used by the architect yet.

2. Document the design decisions taken and their rationale

Going back the very basics of documenting architectures the design decisions taken and their rationales should be a mandatory part of the architecture documentation. For example Clements, Bachman, Bass et al. describe this idea in their ‘Seven Rules for Sound Documentation’ (Rule 5: Record Rationale, see [CBBG2003, p. 24-29]). Here it is important to notice that all evaluated options should be documented to support the transparency of the decision process – not only those leading to the final design. Therefore each template for architecture documentation should contain a dedicated chapter and/or structure supporting this part of the documentation.

In case the architect works on the enterprise architecture level a motivational model as part of an overall EA metamodel supports the explicit modeling of the objectives, principles, requirements and constraints and their linkage to the architectural decisions and elements respectively. Take for example Open Groups’ ArchiMate standard which contains such an motivational model in its latest version 2.0 (see [TOGAF2012] and this related post).

3. Use qualitative metrics to the most possible extend

The paramount architectural evaluation is based on qualitative metrics solely but in rare cases the architect has all underlying data and evaluation models and therefore is able to calculate all required metrics. Nevertheless the architect should strive for using qualitative metric by identifying available basic data, useful evaluation models and trying to combine architectural decisions with relevant metrics. In case there are at least some metrics available pure political decisions could be argumented against easily.


  • [BaCK2003] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2nd Edition, Addison-Wesley, Boston et al. 2003.
  • [CBBG2003] Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James; Little, Reed; Nord, Robert; Stafford, Judith: Documenting Software Architectures – Views and Beyond. Addision-Wesley, Boston et al. 2003.
  • [ClKK2002] Clements, Paul; Kazman, Rick; Klein, Mark: Evaluating Software Architectures – Methods and Case Studies. Addison-Wesley, Boston et al. 2002.
  • [Mali2008] Malich, Stefan: Qualität von Softwaresystemen – Ein pattern-basiertes Wissensmodell zur Unterstützung des Entwurfs und der Bewertung von Softwarearchitekturen. Gabler, Wiesbaden 2008.
  • [TOGAF2011] The Open Group: The Open Group Architectural Framework (TOGAF).  Version 9.1, 2011.
  • [TOGAF2012] The Open Group: ArchiMate 2.0 Specification. Technical Standard, February 2012.