Real-life IT architecture design reports and their relation to IEEE Std 1471 stakeholders and concerns

Abstract

Architectural designs are an important means to manage the development and deployment of information technology (IT). Much debate has been going on about a proper definition of architecture in IT and about how to describe it. In 2000, the IEEE Std 1471 proposed a model of an architecture description and its context, which has been greeted with a warm welcome by many professionals in IT, but has not been applied much yet. In this paper the distance between IEEE Std 1471 and current practice is investigated. We have studied four real-life architecture descriptions from the practice of a bank and consultancy firm. These documents propose strategic decisions about application portfolios and were compiled without reference to IEEE Std 1471. Our research questions were: which parts of the document are, in the perception of the authors of those documents, relevant to which concerns of stakeholders? And, does this `relevancy pattern' suggest an alternative organization in concern-related views? In other words, can the existing documents be (manually) re-engineered to IEEE Std 1471 documents? The answers to these questions enable authors to communicate more effectively to the stakeholders and can be input to future automated document generation.

We found that the `relevancy pattern' is very scattered, and that an alternative organization is not evident. Most concerns are addressed by a relatively small, but each time very different, subset of the document. So re-engineering these documents to IEEE Std 1471 documents would incur an almost complete rewrite. Our research makes it very understandable that readers complain about too much information. Some stakeholders might well have difficulty finding the information of their interest.

The authors of the architecture documents found this investigation a worthwhile exercise, one which they think could be developed further into an evaluation instrument for this type of documentation. Conversely, authors of architecture documents do well to make their stakeholders and their concerns explicit up front.