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.
REFERENCES
- [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.
