Getting results

One of the frequently debated topics in many companies is the question: what do architects really do? This is partly the result from the fact architects tend to work with abstractions. Another important aspect, however, is the fact that "doing architecture" has the connotation of a lot of talk resulting in a stack of obscure diagrams. These are, of course, important but they shouldn't be confused for being the architecture. Simply put, all systems have an architecture, whether it is documented or not. Diagrams "only" document some aspect of the architecture (most notably: diagrams tend to document the 'fundamental organization' of the system). Hence, diagrams are means to an end.

Having established this role of architecture diagrams, it makes sense to consider the question why one wants to make these diagrams in the first place. A popular take on this is "informed decision making" (see e.g., this post). As far as I can see by a review of literature on architecture, most architecture approaches see the enterprise as a closed (technical) system which is largely deterministic. Architecture diagrams are then used to gain a deeper understanding of the working of this system and to guide decision making with respect to the system. 

Seeing enterprises as open (social) systems is increasingly popular in the field of enterprise archtiecture (see e.g. the weblog of Tom Graves). One approach that is built around this view of enterprises is SqEME. In SqEME - as I understand it from the 2008 version of the book - doing architecture is seen as a social process; it is about building a shared understanding of what constitutes the enterprise. Diagrams are used as a means of communication / tool to achieve this shared understanding. 

SqEME defines four windows on enterprises, most notably:

• constitution - what are the essential characteristics of the enterprise?
• chemistry - what makes the enterprise tick?
• construction - how is work facilitated in the enterprise?
• correspondance  - how has the enterprise performed/

From an architecture point of view, the constitution window is likely to be most relevant (however, it most be noted that the windows on the enterprise form a unified, holstic picture of the organization!). The constitution of the enterprise is documented using key result areas which are further analyzed using activities (verbs) and messages (nouns). The diagram type is an a version of the SADT / IDEF0 language which is both simple and intuitive. These diagrams are not intended for "implemtation" (i.e., change the diagram first, then change reality accordingly); but rather to reinforce a synchronized view of the big picture of the enterprise. 

Abstracting from SqEME for a moment: doing architecture in practice should be seen as a social process and aims at developing a shared understanding of what constitutes the enterprise. As a corollary: all people invovled in the enterprise are stakeholders in the architecture process. It may therefore be interesting to experiment with "web 2.0 tools" to explore how large groups of people can be involved (in)directly in the process. E.g., using wiki's to define the meaning of the verbs and nouns of the organization, use clickable / navigatable diagrams (i.e., when using 'leveled diagrams') that are available ubiquitously, etcetera. 

Question: any interesting experiences to share in this area?

Kodak

While browsing the Web I stumbled upon a great post on Kodak. It is a good read and highlights the strategic issues that Kodak faces / faced. The issue that is described is also interesting from an architecture point of view: from the user / customer point of view, Kodak's service has remained the same for years (hand in foto, get prints in return). The underlying technology (film, digital) has changed. Interesting case to use in class / lectures / papers.