The Many Faces Of Architectural Descriptions
- 1. Inf Syst Front (2006) 8:103–113 DOI 10.1007/s10796-006-7975-x The many faces of architectural descriptions Danny Greefhorst · Henk Koning · Hans van Vliet C Springer Science + Business Media, LLC 2006 Abstract In recent years architecture has acquired recogni- Introduction tion as playing a pivotal role in change processes. Despite this recognition, describing architecture has proven to be difficult. Architecture in IT has gained acceptance as a means to guide Architecture frameworks have been defined to address this IT change processes. Although people tend to disagree on problem. However, there are many of them, and together they the exact definition, architecture can be seen as the high- leave us with seemingly contradicting terminology. What are level structure of a system. It describes fundamental aspects the underlying forces that caused people to create so many of the system, and guides the persons that actually design different frameworks? What do these frameworks teach us and build the system. Architecture needs to be described in about the essence of architecting? Where do I start to select a document: an architectural description. Also, the archi- or create a framework for my current project? With these tectural description needs to be structured into manageable questions in mind we set out to perform a comparison of ex- “chunks” that each addresses a number of aspects of the ar- isting architecture frameworks. We ended up with a deeper chitecture. There is no universal agreement on the “chunks” understanding of the function of a framework, and “discov- that an architectural description should consist of. Architec- ered” nine fundamental dimensions that seem to underlie ture frameworks should provide guidance in this area, but the architectural thinking. These “base dimensions” can be used problem is that there are so many of them. Even when there to clarify the meaning of individual architecture documents is agreement on the use of a framework, the peculiarities of independent of the framework they originate from, and they a specific project often make it necessary to deviate from the can be helpful in defining new architecture frameworks or framework. IT-architecture consultants who work in vary- situational architecture descriptions. In this paper we also ing circumstances have to spend extra time to get acquainted relate our findings to IEEE 1471, which is another important with local templates, and it may take some time before all the generalisation of existing frameworks. meanings are clearly understood. The trade of architecting is visually manifested mainly by the frameworks. They are Keywords Architecture frameworks . Architectural the signs of mastery achieved. Persons who are new to the dimensions . IEEE 1471 field, like junior architects, and who see so many diverging frameworks, ask themselves “what is going on here?”. Can you imagine a doctor in a hospital saying “I have 18 ways to D. Greefhorst ( ) record your case in my files”. IBM Business Consulting Services, The Netherlands These observations motivated us to investigate frame- e-mail: greefhorst@nl.ibm.com works for architectural descriptions, and try to discover their H. Koning fundamental structure. Architecture frameworks order archi- Freelance Researcher, The Netherlands tectural descriptions along one or more axes, and typically e-mail: koning@arc-it.nl visualize the resulting architectural space spanned by these axes. A cell in this n-dimensional space denotes an archi- H. van Vliet Vrije Universiteit, Amsterdam, The Netherlands tectural description that corresponds to the characteristics e-mail: hans@cs.vu.nl of the accompanying column and row. We call these axes Springer
- 2. 104 Inf Syst Front (2006) 8:103–113 “dimensions”, and call specific columns or rows in these di- descriptions, while others focus on the method. In this paper mensions “values”. Further analysis of these dimensions led we are mainly interested in the way architecture frameworks to the identification of nine “base dimensions”, that are the approach architectural descriptions, and structure them into foundation for the dimensions found in architecture frame- one or more dimensions. Further analysis of the space of works. We will describe these base dimensions, and illustrate architecture frameworks shows that they can be divided into their relationship to the dimensions as they occur in existing two categories: enterprise-class frameworks and application- architecture frameworks. The latter are typically a combina- class frameworks. tion of one or more “base dimensions”. Enterprise-class frameworks are aimed at business units, The main contribution of this paper is the insight that archi- complete organisations or even industry sectors. These tectural “dimensions” should be made explicit, and are based frameworks often have multiple dimensions, potentially lead- on a number of “base dimensions”. It is not our intention ing to a large number of architectural models. An enterprise to introduce a new framework. Although we studied quite architectural information base may contain many separately a number of frameworks, we do not contend that our list of maintained documents. Examples of enterprise-class frame- base dimensions is complete. Also, the values within the base works are the Zachman Framework for Information Systems dimensions presented are merely described to illustrate the Architecture (ISA) (Zachman, 1987; Sowa and Zachman, base dimensions. Finally, we did not strive to make a com- 1992), the Information Framework (IFW) (Evernden, 1996), plete survey of architecture frameworks, but only to have a The Open Group Architecture Framework (TOGAF) (The solid enough basis for analyzing the “logic of architectural Open Group, 2003), Integrated Architecture Framework frameworks”. Readers are urged to use the base dimensions (IAF) (Goedvolk and Rijsenbrij, 1999) and Methodology for presented as a reference point to position individual archi- Architecture Description (MAD) (Meinema, 1999). tecture documents or to better understand the essentials of Application-class frameworks describe the architecture of existing architecture frameworks. a specific (software) application or a group of similar appli- An important milestone in the field of architecture descrip- cations, and typically comprise a small number of architec- tions is ANSI/IEEE Std 1471 (IEEE Std 1471-2000, 2000), tural models. The information in application-class frame- which was published in 2000. We will refer to this standard as works is often more fine-grained than the information in IEEE 1471. IEEE 1471 proposes to structure architecture de- enterprise-class frameworks. Well-known application-class scriptions in views which are directly related to stakeholder frameworks are the 4+1 model (Kruchten, 1995), the frame- concerns. In this paper we point to some strengths and weak- work of Siemens (Hofmeister et al., 1995, 2000), and the nesses of this approach and we show that our findings are 2+2 model of the Vrije Universiteit (Lassing et al., 2001). complementary to IEEE 1471. The following paragraph describes the Zachman frame- This paper is organised in three sections. In the first sec- work and the 4+1 model in more detail as typical examples tion we describe the current situation of the architecture of enterprise-class and application-class frameworks, respec- frameworks. We will give a short description of two archi- tively. It also illustrates the concept of dimension. tecture frameworks, just to introduce the notion of an ar- chitecture framework, and the concept of “dimension” to Showcases readers unfamiliar with them. We then list a number of ar- chitecture frameworks, and the dimensions we discovered Zachman in them. This is followed by an analysis, leading to some general observations and essentials of architecting. In the The foundation for enterprise-class frameworks was laid by second section we elaborate on the concept of “dimension”, John Zachman in his 1987 article (Zachman, 1987) in which and propose a list of base dimensions in architecture. We he describes a framework for the architecture of informa- illustrate the usage of the base dimensions with an exam- tion systems. His idea was that architecture for information ple. In the third section we relate our work to IEEE 1471. systems could be inspired by architecture in more mature en- We conclude with a short recap and acknowledgements and gineering disciplines. He saw that the architectural models in references. these engineering disciplines showed a lot of similarities and could be combined in a generic model. Zachman recognised two dimensions: perspectives of specific target audiences and Architecture frameworks the types of architectural descriptions. Potential perspectives are those of: the planner, the owner, Architecture frameworks offer a standard approach to archi- the designer, the builder and the subcontractor of an informa- tecture. This approach may encompass a model for architec- tion system. Later on, Zachman gave these perspectives more tural descriptions, as well as a method to produce them. logical names, and they were labelled the contextual, concep- Some architecture frameworks focus on the architectural tual, logical, physical and out-of-context perspectives. The Springer
- 3. Inf Syst Front (2006) 8:103–113 105 Fig. 1 Zachman framework for enterprise architecture out-of-context perspective denotes that at this level parts are typically fabricated outside the larger context in which they are used. The types of description dimension finds its origin in Zachman’s observation that the same elementary questions of what, how, where, who, when and why can always be an- swered in different contexts. For information systems these questions are translated to data, function, location, people, time and motivation. The other observation was that both dimensions could vary independently, leading to 5 ∗ 6 = 30 different kinds of architectural models for one information system. In the framework these models are depicted in a ma- trix with columns for the types of description and rows for the perspectives (see Fig. 1). Fig. 2 The 4+1 model 4+1 (processes, messages) and system engineers (nodes and networks). The fifth view contains scenarios that describe A well-known application-class framework is the 4+1 model how the elements in the other views co-operate. (Kruchten, 1995) for software (see Fig. 2). In contrast with the enterprise-class frameworks, this Overview framework only has one dimension, which is not named explicitly. Like the Zachman framework, the views relate We now offer a summarized overview of architecture frame- to different stakeholders and their concerns. There are four works, and other architecture classifications we found (see views, namely the logical, development, process and physi- Table 1). For each framework we list the source, the dimen- cal view. These views have a recognisable relationship with sions and the values in the dimensions. The dimensions are users (classes), developers (packages and files), integrators depicted as the rows next to the framework. A division of Springer
- 4. 106 Inf Syst Front (2006) 8:103–113 Table 1 Existing architecture frameworks Framework Source Dimension Values 2+2 model (Lassing et al., 2001) Context, Technical Infrastructure, Conceptual, Development 4+1 model (Kruchten, 1995) Logical, Process, Development, Physical, Scenarios ADS (Youngs et al., 1999) Aspects Functional, Operational Level Specified, Physical ARIS (Scheer, 1992) Organizational, Data, Control, Function, Product/Service Boar (Boar, 1998) Infrastructure, Data, Applications, Organization Inventory, Principles, Models, Standards CIMOSA (ESPRIT, 1993) Instantiation Generic, Partial, Particular Views Function, Information, Resource, Organisation Derivation Requirements Definition, Design Specification, Implementation Description DYA (Wagter et al., 2001) Business (Product, Process, Organisation), Information (Data, Application), Technical (Middleware, Platform, Network) Common Principles, Policies, Models Evernden (Evernden, 2002) Types of Eight information Levels of understanding Types of representation Levels of transition Types of knowledge Levels of responsibility Types of process Meta levels Gartner (Rosser, 2002) Scope Multi enterprise Grid, Enterprise, Business Process, Brick Context, Concept, Logical Now, less than 2 years, 2 to 5 years GEM (deBaat, 1999) Operational External Infrastructure (Suppliers, Partners, Customers) processes Business Architecture (Business Organisation, Business Processes, Business Information), Application Architecture (Presentation, Business Logic, Data Access), Technical Architecture (Middleware, Operating System, Hardware) Migration Operations & Support, Infrastructure Specification, Test, Training & Deployment Development & Maintenance Architecture & Engineering GERAM (IFIPIFAC, 1998) Life-Cycle Identification, Concept, Requirements, Design, Implementation, Operation, Decommission Genericity Generic, Partial, Particular Views Entity Model Contents, Entity Purpose, Entity Implementation, Entity Physical Manifestation GRAAL (van Eck et al., 2002) Service Layers Environment, Business mission and functions, Business processes, Software applications, Software platform, Processing and networking hardware Refinement Lifecycle Planning, Organizing, Directing, Controlling Aspects Dictionary, Communication, Functions, Behavior, Quality Herzum/Sims (Herzum and Sims, 2000) Functional, Application, Technical, Project Management (Continued on next page) Springer
- 5. Inf Syst Front (2006) 8:103–113 107 Table 1 (Continued) Framework Source Dimension Values Herzum/Sims (Herzum and Sims, 2000) Functional, Application, Technical, Project Management IAF1 (Goedvolk and Rijsenbrij, 1999) Main Business, Information, Information Systems. architecture areas Technology Infrastructure Design phases Contextual, Conceptual, Logical, Physical, Transformational Special Business and ICT System, Security. Governance viewpoints IFW (Evernden, 1996) Types of Organization (Strategy, Structure, Skills), information Business (Data, Function, Workflow, Solution), Technical (Interface, Network, Platform) Levels of Deconstruction (Domain Concept, Domain Classification), constraint Composition (Generic Template, Design Context), Implementation (Operational Bound) Content Organisation Model, Financial Services Data Model, Financial Services Function Model, Financial Services Workflow Model, DesignWare, Finance Industry Solutions, Technical Model, Financial Application Architecture Transformation Ownership Global, Industry, Enterprise, Local, Individual Route maps MAD (Meinema, 1999) Inter-organizational, Organizational, Process, Information, Application, Distribution, Configuration Maier/Rechtin (Maier and Rechtin, 2002) Data, Behaviour, Form, Purpose, Performance, Managerial March (Hermans, 2002) Product, Process, Organisation, Information provisioning, Infrastructure Context, Concept, Logical Now, less than 2 years, 2 to 5 years RM-ODP (ISO/IEC CD 10746-1, 1994) Enterprise, Informational, Computational, Engineering, Technology Siemens (Hofmeister et al., 1995, 2000) Conceptual, Module, Execution, Code Tapscott (Tapscott and Caston, 1993) Business, Work, Information, Technology Application, TOGAF (The Open Group, 2003) Architecture Business, Data, Applications, Technology Domains Architecture Foundation, Common Systems, Industry, Organisation Continuum Zachman (Zachman, 1987) Types of Data, Function, Network, People, Time, Motivation (Sowa and Zachman, 1992) description Perspectives Contextual, Conceptual, Logical, Physical, Implementation, Out-of-Context 1 Recently IAF has included the “Enterprise” main architecture area, which comprises one holistic representation of the organization as a whole. values into subvalues is shown in parentheses. The table will r They use different terms for similar aspects, and similar be the primary source of inspiration for our definition of di- terms for different aspects (for example: the term “busi- mension, and the base dimensions that we distinguish. Cells ness” in IFW is not the same as the term “business” in for dimensions and values that are empty indicate that the TOGAF). source does not explicitly name them. r They often define terms only informally making it difficult to demarcate boundaries clearly (for example: where does the conceptual level end and the logical level begin?). Observations r They often do not name dimensions explicitly, leaving their Confusion interpretation up to the reader (an example is the March framework). An analysis of existing frameworks and their dimensions r They sometimes do not distinguish clear values within leads to a number of observations: the dimensions, hindering effective communication (an Springer
- 6. 108 Inf Syst Front (2006) 8:103–113 example is the Evernden Eight that leaves the exact content The secondary, vertical dimension, in contrast, often is of all dimensions up to the reader). one that has a sequential aspect or is simply a partitioning in r They often have slightly different sets of values for partic- different levels of detail. With a sequential aspect there is a ular dimensions (see for example the IAF “design phases” certain order in the construction of architectures that follows dimension and the Zachman “perspectives” dimension). the values in this dimension. Examples of such dimensions r They sometimes have dimensions with values that do not are the IFW dimension “levels of constraint”, and the IAF di- have a clear relationship, which makes it hard to understand mension “design phases”. When devising such a dimension the dimension altogether (take for example the “special the framework creator must discover which architectural de- viewpoints” dimension in IAF). scriptions need to be fixed first, and which architectural de- scriptions need to be based on them. When the dimension is These observations show that architecture frameworks are a partitioning into levels of detail, the higher rows contain a not the silver bullet for the confusion that exists when talking higher level of abstraction (fewer details) than lower levels. about architecture. Not only do individual frameworks leave These two meanings of the secondary dimension (sequence us with some questions, but current architecture frameworks versus levels of detail) are very similar since a design usually are also inconsistent with each other, making it necessary to progresses from a high level of abstraction to a lower level tell someone which framework you use when talking about of abstraction. architecture. What is required in our view is an underlying Dimensions are inherent in the paradigms people use, and concept of architectural dimension, but more on that later. prevailing paradigms can be a good source for concepts to build architectural dimensions from. Examples of these are the chain of control, the value chain, and the phases in de- Essentials velopment. These observations might be helpful for those that want to Analysis of the frameworks also leads to another important describe their own architecture framework. They need to ask observation, in that frameworks in essence are an attempt themselves: “what is the purpose of this framework?”, “what of the creator to enable clustering of architectural informa- are the types of information that need to be described?” and tion in a way that suits a particular context and goal, with “what is the order in which we want to architect?”. We believe many parties involved. We see dimensions that are unnamed, that the best architecture framework is the one that provides which may express the lack of one overall concept. We per- answers that are most appropriate for a specific context. ceive these unnamed dimensions as a struggle by the creator to capture in one stroke the main dimensions by which the various stakeholders structure their world. Dimensions We observe a division of dimensions into primary, sec- ondary and supporting ones. The reason probably is that two We have used the term “dimension” informally several times dimensions are often enough to cover the required archi- in this paper already. It is an everyday word. Now we will tectural descriptions. Also, on paper it seems most natural try to formalize it. Using the resulting definition we will syn- to represent the framework as a collection of cells, spread thesize a list of base dimensions from existing frameworks. over the two dimensions of a matrix; one dimension is de- These base dimensions are further explained and illustrated picted horizontally (primary dimension), and another one subsequently. vertically (secondary dimension). Sometimes other (support- Webster Online offers the following explanation of the ing) dimensions are shown, or mentioned in the description word “dimension”: of the framework. The primary, horizontal dimension is often the type of in- 1a (1): measure in one direction; specifically: one of three formation (topic), which can be divided into business and coordinates determining a position in space or four co- IT aspects. This distinction between business and IT is ordinates determining a position in space and time (2): prominent in enterprise-class frameworks, but missing in one of a group of properties whose number is necessary application-class frameworks. This is perfectly explainable and sufficient to determine uniquely each element of a from the purpose of the framework: enterprise-class frame- system of usually mathematical entities (as an aggre- works need to align business and IT, while application-class gate of points in real or abstract space) <the surface frameworks only need to model an IT solution. A general of a sphere has two dimensions>; also: a parameter or observation concerning this first dimension is that, although coordinate variable assigned to such a property <the relationships exist, the values can be described fairly inde- three dimensions of momentum> (3): the number of pendent of one another. elements in a basis of a vector space b: the qualityof Springer
- 7. Inf Syst Front (2006) 8:103–113 109 Table 2 Proposed base dimensions Dimension Description Type of information The topic of the information (business, organisation, technical) Scope The extent of the information covered (industry sector, organisation, domain, system family, system, component) Detail level The amount of detail (high, medium, low) Stakeholder The target audience (client, end-user, architect, analyst, developer) Transformation The transformation phases that the architecture needs to cover (current situation, short-term, medium-term, long-term) Quality attribute The quality attribute that is being addressed (functionality, reliability, usability, efficiency, maintainability, portability) Meta level The amount of abstraction (instance, model, meta-model, meta-meta-model, meta-meta-meta-model) Nature The nature of the information (policy, principle, guideline, description or standard) Representation The way architectural information is represented (formal, semi-formal, informal) spatial extension: MAGNITUDE, SIZE c: a lifelike or Base dimensions realistic quality d: the range over which or the degree to which something extends: SCOPE – usually used in Based on our definition and existing architecture frameworks, plural e: one of the elements or factors making up a we will now synthesize a list of nine base dimensions. The complete personality or entity: ASPECT sources of inspiration for these dimensions are the existing 2 obsolete: bodily form or proportions architecture frameworks. We have studied the dimensions in 3 : any of the fundamental units (as of mass, length, or time) these frameworks and transformed them into “pure” dimen- on which a derived unit is based; also: the power of such sions conforming to our definition. The resulting list is shown a unit in Table 2, which includes a short description of the dimen- 4 : wood or stone cut to pieces of specified size sion and a hint at possible values. Since it is not our intent to 5 : a level of existence or consciousness standardize or formalize these values, they are just meant to illustrate the dimension. Also, we are not claiming that the set of nine dimensions is complete; other base dimensions With a little play of words from 1 a (2) we like to see may exist and could be added to our list. a dimension in the field of IT-architecture as an attribute of a piece of information which positions this piece of Base dimensions in detail information in the total available information space. 1 e shows that more than one dimension is needed to make We will now describe our proposed base dimensions in more up a complete architecture description. And 3 speaks of detail. The first five are fairly common in architecture frame- fundamental (base) units on which a derived (practical works. The other four are used less frequently. applicable) unit is based. So far the (serious) play of words. If we try to put it in one sentence, it would be something like: Type of information. This dimension is by far the most preva- lent in architecture frameworks, and describes the subject of architectural information. Another way to look at this An architectural dimension is a criterion to partition an dimension is that it consists of the concepts that exist in architectural description into a set of segments, where each domain-specific languages. At a high level this dimension segment is identified by a unique value within a list of values can distinguish segments such as business, organisation, and associated with the dimension. technical. Within these segments a further segmentation typi- cally exists. For example, IFW decomposes the technical seg- Architectural descriptions should document the dimensions ment into interface, network and platform segments. Some used and the segments they cover in an introductory chapter. other frameworks that use this dimension are: 4+1, DYA, Standardizing these dimensions, their segments in particular, GEM, GRAAL, RM-ODP, Siemens, and TOGAF. in a specific organizational context prevents semantic obscu- We perceive this dimension as a means to break down rities and introduces a shared architecture terminology. a complex situation into more or less independent aspects. Springer
- 8. 110 Inf Syst Front (2006) 8:103–113 Together these aspects provide a conceptual model of the from short-term, medium-term and long-term situations, in- entire environment. Some frameworks are explicit about the cluding the transitions between them. A slightly different relationship between aspects. An example is the GRAAL way to define this dimension is to not refer to specific mo- framework which claims a service provisioning sequence ments in time, but to characteristics of the situation that can from “processing and networking hardware” to “software exist in time, like the levels in the Capability Maturity Model platform” to “software applications”, and so further. TOGAF (CMM) initial, repeatable, defined, managed and optimised. prescribes a design sequence from “business” to “informa- Examples of frameworks that use this dimension are: Gart- tion systems” to “technology”, which we read as a claim that ner, IFW, Evernden Eight and March. the business determines the information systems, and that information systems determine the technology. Quality attribute. A number of dimensions in existing frameworks mention quality characteristics such as secu- Scope. This dimension describes the scope of the informa- rity, performance and usability, see for example IAF and tion covered. It is our proposal for a “clean” top down di- Maier/Rechtin. In our view these characteristics can be mension, one that is easily understood. One way to decom- considered as a separate dimension, with segments that pose this dimension is with the values industry, organisa- each highlights certain quality characteristics. The val- tion, organisational domain, system family, system, and sys- ues within this dimension are defined by quality frame- tem component. Scope is the main dimension of the Gart- works. Various quality frameworks exist, such as the Ex- ner framework (Rosser, 2002) with a different list of val- tended ISO model (vanZeist et al., 1996). This dimen- ues. Different interpretations of the dimension are possi- sion makes it possible to talk about, for example, a ble, interpretations that each may be valid from a specific performance view or a security view. These last two point of view. The scope dimension is very much related to views are also very common types of quality-driven the ownership dimension in IFW, and it is implicitly used views. in the levels of constraint dimension in IFW. In particu- lar, the design context and operational bound values in IFW Meta level This dimension addresses those architectures that, have a system scope, while the upper levels have a domain instead of domain-specific models, provide general clas- scope. sifications and relationships. It really describes a meta- model; information about information. Consider for example Detail level. This dimension is based on the amount of detail, a model that describes the types of components that may be where levels with more information can be defined. A char- developed, and the legal relationships between them. Multi- acteristic is that all information of the level above is kept, and ple meta levels exist (meta-meta models, and so forth), but that new information is added. The primary goal of varying arguing that these are architectural in nature becomes in- the level of detail is to leave out those details that are not creasingly difficult. The “meta level” dimension resembles relevant or known in a particular context or at a particular the “detail level” dimension; the difference is that instead moment in time. Since it is possible to add different types of of less information meta-models describe different informa- detail, one could say that the detail level dimension comes tion. Evernden Eight is a framework that includes a meta in various types. Examples of frameworks in which we rec- level dimension. ognize a detail level dimension are: Zachman (perspectives dimension), IAF (design phases dimension), March (second Nature. This dimension determines the nature of the archi- unnamed dimension). We say “recognize” because the detail tectural information; is it a policy, principle, guideline, model level portioning is a bit obscured by other meanings attached or standard. Inherent in this dimension is the extent in which to these dimensions in the frameworks. designers need to comply with the architectural information. A policy is clearly more important to follow than a guideline. Stakeholder. This dimension uses the stakeholders that are The dimension is based on the dimensions as defined by Boar addressed as primary criterion. Stakeholders are typically and DYA. only interested in certain parts of the architecture. Defining descriptions for specific stakeholders was the intention of the Representation This dimension uses the way to represent ar- Zachman perspectives dimension, but this also holds for other chitectural information as criterion. One can choose between architecture frameworks such as 4+1, IAF and RM-ODP. formal, semi-formal and informal representations. An infor- Again, the pure meaning of the “stakeholder” dimension is mal representation is natural language, which leaves room for obscured by other meanings attached to it in the frameworks. interpretation. Semi-formal means such as UML improve the welldefinedness. Formal description languages such as C2 Transformation The transformation dimension uses change and Rapide (Medvidovic and Taylor, 2000) are at the other in time as the criterion. It distinguishes the current situation extreme, but sometimes necessary to automatically generate Springer
- 9. Inf Syst Front (2006) 8:103–113 111 models or reason about them. For example, a performance information is medium; it is not the intention of the SAD to model based on Queueing Networks (Smith and Williams, be a detailed design. Looking at the activities that the SAD 2002) provides a very accurate description of a system. The is input to, we derive that the target audience of the docu- Evernden Eight framework also includes a representation di- ment are the designers and implementers of the system. The mension. goal of the SAD is to be a short-term architecture; project members need to fully comply to it immediately. Although Usage the emphasis of the SAD is on the functionality of the sys- tem, the impact on all other quality attributes also needs to The list of base dimensions can be used in many different be documented. The contents of the document are models of ways: as communication vehicle, checklist or basis for an the system; no meta-models are described. Also, the nature architecture description or an architecture framework. The of the architectural information is that it contains only mod- primary goal of the list is to facilitate communication about els; no principles, guidelines or standards. The models are architecture in general. There are several ways to support represented by UML models, which are supplemented with this, such as documenting the values that an architectural de- text. scription covers in the various dimensions in an introductory chapter. Also, in verbal communication these dimensions can be used to position an architectural description. Using the list IEEE 1471 as checklist allows one to check whether all relevant aspects have been taken into account for a specific architecture. Fi- The IEEE 1471 “recommended practice” defines concepts nally, the list can be used in the construction of a new archi- and their relationships that are relevant for architectural de- tectural description or architecture framework. This means scriptions (IEEE Std 1471-2000, 2000). It also provides selection of the most applicable dimensions and values within guidance on the structure of architectural descriptions. The those dimensions, and translating those to document struc- main concepts standardised are “architecture”, “architec- tures. tural description”, “concern”, “stakeholder”, “viewpoint” and “view”, see Fig. 3. Architecture is defined as “the fun- Example damental organization of a system embodied in its compo- nents, their relationships to each other, and to the environ- We will now exemplify the use of our list of base dimen- ment, and the principles guiding its design and evolution”. sions by positioning the view on architecture of the Rational Architectural descriptions are segmented into views. A view Unified Process (RUP) (Rational Unified Process, 2002), an addresses a related set of stakeholder concerns and is con- object-oriented software development method (see Table 3). structed in accordance with the specification that is laid down The software architecture document (SAD), as RUP calls in a viewpoint. Together the views address all the concerns the architectural description, contains seven potential view- of the stakeholders. points that are inspired by the 4+1 model. In addition to the Since its publication in 2000, IEEE 1471 has received original viewpoints, also a data and user experience view- much appraisal. The concepts of stakeholders, concerns and point are added. Looking at these viewpoints we see that views are accepted as essential. The terminology proposed by they describe technical information about the system. RUP talks about the “software architecture” of a system, implying a system scope for the architecture. The detail level of the Table 3 Positioning architecture within Ratio- nal Unified Process Base dimension Value Type of information Technical Scope System Detail level Medium Stakeholder Designer, Implementer Transformation Short-term Quality attribute All Meta level Model Nature Model Representation Text, UML diagram Fig. 3 IEEE/ANSI Std 1471 conceptual model Springer
- 10. 112 Inf Syst Front (2006) 8:103–113 IEEE 1471 is now being used by many architects. The focus There still remains a lot of work to be done in architecture on concerns of stakeholders is a good stimulus for otherwise description standardization. In particular, the values within possibly too technically oriented IT architects. After all, it is the dimensions described need to be widely agreed upon. the interests of the stakeholders that need to be served. This will lead to standardized architectural viewpoints (li- Although IEEE 1471 is an important contribution to stan- brary viewpoints), and will ultimately contribute to the fur- dardising architecture terminology, it still leaves a number ther maturation of the architect profession. We would like to of things unspecified. Most importantly, IEEE 1471 does not understand more of the circumstances in which the different propose nor prescribe any specific viewpoint, which might frameworks function. confuse architects and stakeholders. In a specific context, two We recommend the use of IEEE 1471 and would like to architects can easily disagree on who the stakeholders and see more constructive debate to come to effective application their concerns are, and what information is needed to address of this standard. these concerns. Also, if a view contains a lot of architectural information, it needs to be structured, bringing back the needs Acknowledgments We want to thank everyone that has provided for which frameworks have been defined. This also holds at us with helpful comments and feedback. In particular, we thank the enterprise level, where many IEEE 1471 compliant ar- Philippe Spaas, Harry Hendrickx, Jan Campschroer, Erik Vermeulen, and Michiel Perdeck for their review comments. We also want to thank chitectural descriptions may need to be made accessible. So, the anonymous reviewers of an earlier version of this paper. even if all IT architects would follow IEEE 1471, architec- tural information could still be very different up to a point where documents are still not accessible, nor comparable. References The “dimension” concept provides a means to further struc- ture IEEE 1471 views into more manageable chunks. Boar BH. Constructing Blueprints for Enterprise IT Architecture. Wiley, We don’t write this in critique of IEEE 1471, but we do 1998. de Baat JM. CMG’s Multi-Channel Management Vision on Architec- feel compelled to raise some arguments against a view of ture, 1999. IEEE 1471 as the silver bullet where it comes to architectural CIMOSA—Open system architecture for CIM. ESPRIT Consortium descriptions. Also with IEEE 1471 at hand, there still is a AMICE, Springer-Verlag, Berlin, 1993, (ISBN 3-540-56256-7), need for additional support to help communication about IT (ISBN 0-387-56256-7). Evernden R. The information framework. IBM Systems Journal, 1996. architecture. Evernden R. Evernden eight. 4th, resource 2002. We also see a mismatch between IEEE 1471 and existing GERAM: Generalised enterprise reference architecture and methodol- architecture practice as represented by the frameworks in our ogy. IFIPIFAC Task Force, Version 1.6.2, 1998. overview. IEEE 1471 requires a view to address a set of re- Goedvolk H, Rijsenbrij D. White paper integrated architecture frame- work. version 1.0, 1999. lated concerns. The “chunks” in which existing frameworks Hermans L. Uitbuiten synergie ICT- en business strategie. Informatie, divide the architectural information are addressing many con- ten Hagen Stam, 2002. cerns, but it is not obvious these concerns are “related” in the Herzum P, Sims O. Business Component Factory. John Wiley & Sons, sense of IEEE 1471. Our guess is they aren’t, but a diffi- 2000. Hofmeister C, Nord RL, Soni D. An industrial perspective of soft- culty here is that IEEE 1471 does not specify what “related” ware architecture. In: Proceedings of the Eleventh International exactly means. Conference on Data Engineering, IEEE Computer Society, Taipei, Taiwan, March 1995. Hofmeister C, Nord R, Soni D. Applied Software Architecture. Addison Conclusions and future work Wesley, 2000. IEEE Std 1471-2000. IEEE recommended practice for architectural There are many differences between existing architecture description of software-intensive systems, 2000. frameworks. Partly this can be explained from their original ISO/IEC CD 10746-1, Basic reference model of open distributed pro- goal, and the context from which they originated. A com- cessing, 1994. Kruchten P. The 4 + 1 view model of architecture. IEEE Software, monality is that architectural information is often organised 1995. in a matrix that is bound by two dimensions: one dimension Lassing N, Rijsenbrij D, van Vliet H.Viewpoints on modifiability. In- typically addresses the type of information, and a second one ternational Journal of Software Engineering and Knowledge En- having a sequential order. gineering 2001;11(4):453-478. Maier MW, Rechtin E. The Art of Systems Architecting. CRC Press, In this paper, we propose the use of nine base dimensions: 2002. Type of information, Scope, Detail level, Stakeholder, Trans- Medvidovic N, Taylor RN. A classification and comparison framework formation, Quality attribute, Meta level, Nature and Repre- for software architecture description languages. IEEE Transac- sentation. These base dimensions allow us to better under- tions on Software Engineering 2000;26(1):70–93. Meinema JL.Corporate Architecture: A Conceptual Approach. Univer- stand and compare existing frameworks, or to create a new sity of Twente, 1999. framework. They also ease the understanding and communi- Rational Unified Process. Rational corporation, Version 2002.05.20. cation of architectural descriptions. 005, 2002. Springer
- 11. Inf Syst Front (2006) 8:103–113 113 Rosser B. Defining architecture for IT: A framework of frameworks. van Zeist B, et al. Kwaliteit van Software Producten, Praktijkervaring Gartner, Research Note, 12, 2002. met een Kwaliteitsmodel. Kluwer Bedrijfsinformatie, 1996. Scheer AW. Architecture of Integrated Information Systems. Springer, 1992. Danny Greefhorst is a Senior IT Architect at IBM Business Con- Smith C, Williams L. Performance Solutions. Addison Wesley, 2002. sulting Services. His expertise lies in the area of enterprise applica- Sowa JF, Zachman JA. Extending and formalizing the framework for tion architecture, integration and development. Before joining IBM he information systems architecture. IBM Systems Journal 1992;31 worked as senior researcher for the Software Engineering Research (3). Center. Danny has a M.Sc. in Computer Science from the University of Tapscott D, Caston D. Paradigm Shift—The New Promise of Informa- Utrecht. tion Technology. McGraw-Hill, 1993. The Open Group: The Open Group Architectural Framework, Version Henk Koning has over 20 years practical experience in system 8.1 2003. development and architecture. This article is part of his Ph.D. study on van Eck PAT, Blanken H, Fokkinga M, Grefen PWG, Wieringa RJ. “Communication of IT-architecture”. A conceptual framework for architecture alignment guidelines— Project GRAAL WP1 Whitepaper, Department of Computer Sci- Hans van Vliet is a Professor in Software Engineering at the Vrije ence, University of Twente, 17, 2002. Universiteit. His research interests include software architecture and Wagter R, et al. DYA: Snelheid en samenhang in business en software measurement. Before joining the Vrije Universiteit, he worked ICT-architecture. Tutein Nolthenius, 2001. as a researcher at the Centrum voor Wiskunde en Informatica (Amster- Youngs R, et al. A standard for architecture description. IBM Systems dam) and he spent a year as a visiting researcher at the IBM Almaden Journal 1999;38(1). Research Center in San Jose, California. Hans has an M.Sc. in Computer Zachman JA. A framework for information systems architecture. IBM Science from the Vrije Universiteit and a Ph.D. in Computer Science Systems Journal 1987;26(3). form the University of Amsterdam. Springer