GeramMAP4

Implementing the MAP Framework1 using GERAM2

Mark GoetschDePaul University

School of Computer ScienceChicago, IL

[email protected]

Abstract

The purpose of this paper is to implement the MAP Framework into the GERAM Framework. The MAP Framework is a framework for defining the ontological roles of a software architect in any process. GERAM is a meta-enterprise architectural framework that is used to implement other enterprise frameworks. By implementing the MAP Framework into GERAM we will show that MAP is compatible with other enterprise architecture frameworks. MAP can then be used to link the software architect with enterprise architectures such as Zachman[9] and COSM[6] on the one hand and software development processes including XP[3] and RUP[2] on the other.

1 Introduction

Enterprise architecture frameworks concentrate on the processes for building entities within the enterprise or on the deliverables from building these entities. There are different examples of these frameworks including Zachman3[9], TOGAF4[10], COSM5[6] as well as a number of others. An enterprise framework will expose the entities as a set of ontological concepts that have processes associated with them that create deliverables as well as other entities. The problem however is that each of these processes have different ontological concepts and more specifically different taxonomies associated with them. This is the same problem that can be found with software development processes. What one software development process refers to as an architect is often not the same as what another software process refers to as a software architect. In one example an architecture centric process RUP6[2] has a specific role for the software architect whereas another competing agile software process XP7[3] does not recognize the role. However they both use the software architects functionality. When managing an organization that has multiple software development processes a common ontological view for a software architect is important. When managing the enterprise architecture a common ontological view is critical. To have a consistent view of the enterprise from software development processes to the enterprise architecture their needs to be a framework that can map 1 MAP is Meta-Architect Processes Framework. This framework started as posts on the WWISA web-site (http://www.wwisa.org) in 2003.2 GERAM is the Generalized Enterprise Reference Architecture and Methodology3 Zachman refers to the Zachman framework except where noted4 TOGAF is The Open Group Architectural Framework.5 COSM is the Component-Oriented Software Manufacturing Enterprise by Herzum Software.6 RUP is the Rational Unified Process7 XP is Extreme Programming, a software process developed by Kent Beck

1

both sides to a common ontology. We introduce MAP as a framework for defining this ontology.

MAP is a role-based framework defining what a software architect is and what type of deliverables that the software architect can deliver. By implementing a software development process using MAP standards can be consistently set between different software development processes. To implement MAP into a process a method similar to MDA8[8] is used. A UML profile9 is created that contains the meta-meta layer concepts [M2 in MDA][8] and used to implement the meta layer concepts [M1 in MDA][8] that defines the software development processes. This then can be implemented into the lowest layer concepts [M0 in MDA][8] that are specific to the company or corporation.

To integrate the enterprise architecture frameworks with MAP however requires a meta-framework that can map the common parts of the two. GERAM provides the meta-enterprise framework needed to integrate MAP with other enterprise frameworks. Once that this is accomplished the other enterprise frameworks have a common set of concepts through GERAM for implementing the ontological concepts of MAP in any other enterprise framework. This is accomplished by mapping the framework to eleven different parts of GERAM: Life Cycle Phases, Life History, Modeling Frameworks, Modeling Languages, Methodologies, Reference (Partial) Models, Entity Types, Recursion, Generic Enterprise Modeling Concepts, Enterprise Modules and Enterprise Engineering Tools[4].

2 Enterprise Architecture Frameworks and GERAM

An Enterprise Architecture Framework is a template for an enterprise architecture. Boar[5] defines an Enterprise Architecture as “… a series of principles, guidelines, drawings, standards, and rules that guide an organization through acquiring, building, modifying, and the interfacing of IT resources throughout the enterprise. IT resources include hardware equipment, software, communication protocols, application development methodologies, database systems, modeling tools, IT organizational structures, data, and more.” Defining enterprise architecture frameworks provides structure and common enterprise ontologies between different instances of the same enterprise architecture in different companies. Zachman[11], emphasizing this point, refers to his enterprise architecture framework as the “periodic table10” of IT architectures.

GERAM is a meta-architecture framework[7]. It [GERAM] defines the common elements that should be available in all enterprise architecture frameworks. By using a mapping process it is possible using GERAM to translate the same activities in one enterprise architecture framework into another enterprise architecture framework. To map an enterprise architecture framework into GERAM requires that the framework map its concepts into the nine different parts of GERAM from figure #1.

8 MDA is Model Driven Architecture a method for separating the modeling from the implementation of an architecture9 UML Profile is a method for defining stereotypes and tag values in UML. It captures the ontological information in the meta layers10 Periodic Table is the official table of recognized elements used in Chemistry

2

While GERAM provides a common set of elements not every enterprise architecture framework supports all of GERAM. In this case the mapping process still takes place but modifications are made to the enterprise architecture to incorporate all of GERAM’s different parts. Zachman provides us with a good example. Zachman only supports a subset of the life history concept [4]. The framework does however support a mappable lifecycle concept. To map this concept into GERAM requires us to first map the Zachman lifecycle into GERAM’s framework. Once the lifecycles are matched multiple copies of the Zachman framework are made with each representing a different time in the life history [4]. This method of modifying the enterprise architecture framework to fit in with GERAM works as long as the architecture is kept ontologically consistent with how it [the framework] was before the changes.

Figure #1: GERAM Meta-Architecture Framework[4]

3 The MAP Framework

The Meta-Architectural Processes (MAP) framework was developed to provide a consistent ontology for the software architect profession. MAP focuses on the individual architect, the architect’s artifacts and how those artifacts are created. MAP does not cover the processes of being an architect, the organizational structures of architects or how the architect interacts with the firm. By not covering the processes and the organization the software architect works in

3

MAP can be used consistently with different software development processes and implemented consistently across companies. MAP consists of five different conceptual areas that are linked together in UML to provide a common view of the software architect. Stakeholders, the system itself and other external elements of software are not a part of MAP as they are in other similar frameworks like IEEE 1471-200111[1].

While MAP is one framework it is also possible to have other meta frameworks that add ontologies for organizations or other key software development concepts.

3.1 The Five MAP Packages

MAP is composed of five different UML packages: Professional Software Architect, Software Architects, Software Architectural Practices, Software Architectural Documentation and Software Architectures as seen in Figure #2.

Figure #2: MAP UML Packages

From Figure #2 a software architect specializes a professional software architect. All software architects should be professionals. The software architectural practices depend on the software architect using them. The software architectural practices, software architectural documentation and software architectures operate in a model-view-control pattern where the practices will control what is developed. The software architects get feedback from the stakeholders on what is to be viewed and how it is to be viewed. The software architectures are the models that feed the different views. In some cases the software architectural documentation is a subset of the software architectures but they may also be views of the software architecture.

3.2 Implementing MAP into a Process

11 IEEE 1471-2001 is a standard for describing software architectures

4

There are at least three separate layers to implement a framework. The first layer is the M0 or framework layer, which contains the meta-ontological concepts for processes. The second layer is the M1 or processes layer, which contains the task ontological concepts for defining the generic processes in a firm. The third layer is the M3 or implementation and configuration layer which contains the domain ontological concepts. Figure #3 is an example of how the layering is

Figure #3: The Layers for Implementing a Framework

represented in UML. There are one or more frameworks that are bound to one or more processes. The assumption that MAP has is that it [the framework] will be bound once to each and every type of software development process. A company, corporation of software vendor will configure this process using and customizing it for themselves but still being bound to the framework through the process layer.

3.3 An Example of Using MAP to Implement a Software Development ProcessIn figure #4 there is an example of binding the framework layer to the process layer. In this case MAP is being bound to the extreme programming software development process. The references to MAP in the stereotypes are the result of a MAP UML profile. Using a UML profile in this instance types each of the different objects with a meta-artifact12 from the MAP framework.

12 Meta-artifact refers to artifacts defined in the higher level ontological layer. In this instance it refers to MAP’s defined artifacts as opposed to artifacts defined by the XP process.

5

Figure #4: An Example of Binding a Framework to a Process

A fundamental part of this binding is that it does not change the nature of the process. The software development process for XP [3] remains that same, however when viewed from outside the XP [3] process the names for the architects and different parts of the architecture will be common to other software development processes that implement MAP. At this level of detail the difference between this software development process and other software development processes that implement MAP are primarily in naming13. When the process is used and configured by a company or corporation management can then refer to a common view of how software architecture is used within the firm. 4 Implementing MAP into GERAM

GERAM is a meta framework on the same ontological level as MAP so the samemethod that MAP uses to implement it’s concepts into software development processes will not work. Instead MAP can be treated in the same fashion as other enterprise frameworks and mapped into GERAM like the other enterprise frameworks14. GERAM uses association rather than typing as used in MAP to relate to an enterprise frameworks ontological concepts. MAP, however, is not an enterprise architecture framework therefore it cannot be fully implemented using GERAM. MAP does however focus on many of the artifacts that exist in other enterprise architectures and can be partially mapped into GERAM.

13 There should be no difference in referring to an architect in an organization whether he is working in the XP software development process or the RUP development process.14 Assuming that the enterprise framework can be mapped into GERAM

6

4.1 Life Cycle Phases

MAP contains a different idea of lifecycle phases than GERAM. GERAM [4] identifies lifecycles as phases in a typical project. This is a very process orientated view and presupposes that the entire history of the project is available to map into the different phases. In figure #5 the phases proceed in a very linear phases from defining the business case for the project to implementing, configuring and finally retiring the project when it’s use has passed. In MAP this process is assumed to be part of the software development process and not implemented directly in MAP.

Figure #5: GERAM Lifecycle phases[6]

7

MAP instead has placeholders that represent the different stages of a software architecture during its lifecycle. In MAP this is categorized as candidate architecture, release architecture or legacy architecture. These lifecycles in MAP represent one dimension in a three

Figure #6: The MAP Software Architecture Matrix

dimensional matrix that represents the different categories of software architecture. Even though it might be assumed that the candidate architecture precedes the release architecture, which in turn precedes the legacy architecture MAP does not imply this relationship and treats every architecture as separate from each. The danger of treating the MAP lifecycle as a single complete lifecycle of an architecture is that there might be multiple architectures for one stage in the software architecture matrix but only a single architecture for the other stages. There might be, for example, three or four candidate architectures with one eventually becoming the release architecture.

Each lifecycle stage in MAP can contains the full lifecycle or a subset of the lifecycle for that architecture. To implement MAP using GERAM we would have to add the different lifecycle phases of GERAM to each lifecycle stage in MAP. This can be seen in the following table:

MAP Stage GERAM PhaseCandidate IdentificationCandidate ConceptCandidate RequirementsCandidate Preliminary DesignRelease Detailed DesignRelease ImplementationRelease OperationLegacy Decommission

Table #1: Implementing MAP Lifecycles into GERAM Lifecycles

8

Each of the stages in MAP includes all the GERAM phases from the previous MAP stage. The release stage of MAP includes all of the GERAM phases from the candidate stage with the addition of the detailed design, implementation and operation phases from GERAM.

4.2 Life History

MAP contains the life history as an artifact or record of the software architecture. MAP recognizes versioning along all three stages of the lifecycle but does not impose any temporal constraints on when these architectures are developed. It is possible in MAP, for example to have three candidate architectures being developed at the same time by different teams with each candidate architecture being a different version as shown in Table #2.

Team Version Team A Candidate A.1Team B Candidate B.1Team C Candidate C.2

Table #2: Three Candidate Architectures by Different Teams

GERAM[4] has the same concept as shown in figure #1. Each MAP stage could be independent of each other as long as the stages were kept sequential (Candidate Stage occurs before the Release Stage which occurs before the Legacy Stage). Within each stage the lifecycle history would be the same as it is in GERAM.

Figure #7: GERAM Lifecycle History [6]

9

The key issue with the GERAM[4] lifecycle history is that multiple projects can occur simultaneously. MAP, because of it’s architectures being independent but related to each other can support this through GERAM as well.

4.3 The Modeling Framework of a Reference Architecture

MAP defines the modeling framework across two edges of MAP’s software architecture matrix. Each edge represents a layer in the MAP architecture matrix. The layers can represent different architectures or be integrated into a single architecture with each matrix box being a model of the architecture. In figure #8 there is one axis for the different activities that produced the software architecture and a second axis for how generic the software architecture is.

Figure #8:MAP Software Architecture Matrix

The activity axis15 breaks architecture down into the three different activities responsible for the architecture. The engineering activity is the architectures that reflect quality and non-functional constraints. The integration activity is the architectures that correspond to integrating 3rd party vendors and utilities. The modeling activity is the architectures that model the system itself.

The genericity axis represents levels of software architecture. At the lowest level there are the building blocks, the patterns, products and individual qualities of software architecture. The next level defines architectures across practices, vendors and reference architectures. The top level

15 Axis is equivalent to dimension

10

reflects the performance attributes, the integrated relationships and how the architecture is specific to the project.

GERAM has different views of the architecture on one axis16 of their modeling framework and different levels of instantiation on the other. GERAM has four different views[4]: Model Content, Purpose, Implementation and Manifestation views. MAP refers to these views as activities and breaks the activities down according to how they were produced instead of their purpose as in GERAM.

Figure #9:GERAM Modeling Framework [6]

16 Axis is equivalent to dimension as described in GERAM

11

Figure #10: The Different Views of GERAM [6]

Mapping MAP into this framework requires us to first map the MAP genericity axis to GERAM’s instantiation axis. From figure #9 the generic and partial parts of the GERAM architecture is referred to as a reference architecture[4]. GERAM reserves the particular part for the actual implementation of the architecture. The GERAM generic part represents the generic parts of an architecture that can be applied as a library. MAP uses a similar concept referring to the quality attributes used for an architecture, the products used in an architecture and the patterns required by the architecture. In manufacturing terms this might be referred to as raw materials. The partial part of GERAM is the partial implementations of the architecture. These partial implementations are not specific to the architecture and can be used along other architectures that solve the same issues17. This is the same in MAP as the practices that develop an architecture, the vendor that solves the problem with one or more products and the reference architecture that specifies the model. The particular part of GERAM is how the architecture solves the specific issues or needs needed to implement an architecture. MAP has three different architectures that contain the performance characteristics (non-functional requirements) of the architecture, how all of the different vendors are integrated together to form the architecture and the specific models that make up the architecture.

GERAM Views Versus MAP Activities

GERAM ViewsManifestation Implementation Purpose Model

ContentEngineering Integration Modeling

GERAM Particular Performance Integrated ParticularGERAM Partial Practices Vendor ReferenceGERAM Generic Quality Product Pattern

Table #3: Mapping the MAP Software Architecture Matrix to

17 Issues refer to a similar architectural set of concerns

12

4.4 The GERAM Modeling Framework

The other axis will map from the MAP activities axis to GERAM’s view axis producing the table #3. The Manifestation view in GERAM maps quite nicely to MAP’s engineering activity that would produce it. GERAM’s implementation view maps into the integration activity in MAP. GERAM supports a purpose view that MAP does not support. MAP relies on the software development process to define the management, control and customer interaction. However, when MAP is implemented the GERAM purpose view would be linked with the modeling activity of MAP. GERAM’s model content is the same as the modeling activity in MAP that produces it.

4.5 Modeling Languages

MAP recognizes four layers of modeling. Requirement modeling models the business rules, text requirements and “loose-leaf” requirements that are part of a project. The requirements may be

Figure #11: The Modeling Layers of MAP

formally or informally captured. Conceptual modeling provides domain context to the models. This includes methods that use the UML MDA[8] approach or the UML profile as well as any other method that attaches domain specific information to the models. Logical modeling relates the different elements of a model into a coherent model. Physical modeling relates the model to the “real” world. One or more modeling languages represent these forms of modeling.

An example of different models from the data architecture is the requirements representing the identification of different entities, the conceptual modeling is the traditional ER modeling that adds the relationships between the entities (which in ontology defines concepts), how the data has represented in tables with foreign keys and using the rules of normalization or the logical model and finally where the actual databases are stored and how they are implemented in the physical models.

MAP also recognizes four different categories of modeling. Each category captures how static and dynamic elements can be captured in models. The four are functional, non-functional, behavioral and structural. Functional represents the business constraints imposed on the model.

13

Non-functional represents the technical constraints on the model. Behavioral is the dynamic view of how elements interact and structural is the static view.

Modeling Functional Non-Functional Behavioral StructuralRequirementsConceptualLogicalPhysical

Table #4: Requirements for Modeling Languages18

It is possible for a modeling language to be used for multiple purposes. A modeling language for modeling functional requirements might also be used for structural requirements. It might also be that there is a modeling standard such as UML that defines multiple languages for this task.

GERAM has requirements for the modeling languages that can be defined (constructs and semantics). These include the expressiveness of the language, the domain covered by the modeling language and that the models produced should be able to be integrated across the different areas of enterprise modeling [4]. MAP in this instance only specifies the types of modeling supported and how close the modeling is to the actual implementation and deployment of the architecture. Adding the requirements of GERAM does not change any of the requirements of MAP for using a particular modeling language.

MAP’s modeling language matrix will map well to any of the enterprise architectures that are mapped into GERAM. The MAP modeling layers will associate well with the lifecycles of enterprise architectures like Zachman[9] or GRAI-GIM[4].

4.6 Methodologies

MAP relies on integrating with a software development process to implement the methodology. However, MAP does focus on how an architect communicates with the software architecture. From Figure #2 we saw that the only contact a software architect has with the software architecture is through his practice. The practices of MAP include:

18 The individual cells in the table would be filled in by the appropriate modeling language. There might (and often will be) the same modeling language used in different cells.

14

Figure #12: MAP Software Practices

Each practice has constraints that must be met according to functional non-functional, behavioral or structural guidelines. The practice also contains quality attributes that represent the trade-offs needed in designing and building an architecture. It is through the various artifacts that the software architect uses these principles to communicate and develop the software architecture. In MAP these practices are also defined as part of the software architecture matrix in figure #6.

The Practices in Figure #12 represent some sample software architecture practices. MAP relies on seven principles to choose a practice as displayed in table #5. Each of these principles must be met to be considered a software architecture practice in MAP.

Principle ExplanationCovering All the software architecture practices combined should cover the

usable software architecture field. More formally the software architecture field equals the sum of all known software architecture practices.

Completeness There should not be any dangling quality attributes that are not part of a software architecture practice.

Composition All software architecture practices contain a unique aggregation of software quality attributes.

Uniqueness For a software architecture practice to be unique it must contain at least

15

one software quality attribute that is not contained in any other practice.Tradeoff There must be at least one unique tradeoff for any given quality

attribute with at least one other quality attribute in a particular software architecture practice.

Attribute Substitution Any decomposable quality attribute can be replaces by the quality attributes that it is composed of as long as the decomposition is complete. (A completed decomposition refers to the logical partition of the parent quality attributes).

General Practice A quality attribute that is contained in every defined software architecture practice can be taken out of the practices and added to a general practice.

Table #5: Principles for Picking a Software Architectural Practice19

GERAM[4] has several requirements for the methodologies: How humans are involved Distinguishing between the user and technology orientated designs Use project management techniques Costing Models

These are all answered as part of a software development process. The roles, how the designs are divided between functional and non-functional requirements, how projects are managed and how they generate value versus what they cost are all part of XP, RUP, SCRUM, Waterfall Model and the Spiral model.

4.7 Reference Models

MAP supports reference models directly under the modeling column of the software architecture matrix. MAP further extends the idea of reference models as seen in GERAM to also include the vendor model under the integration column and the practice model under the engineering column.

GERAM, as seen in figure #9 combines the generic and partial models as reference models. GERAM uses the level of reuse to distinguish between generic and partial models. The generic model can be reused completely whereas the partial models can only be partially reused. MAP equates the generic model to patterns and the partial model to the reference architecture.

4.8 Entity Types and Recursive Entity Types

MAP supports two different entity types: Software Architect System Folio20.

19 These principles were first used in a presentation What Type of Software Architect are You? given at the MSEC (Midwest Software Engineering Conference) 2004 by the Author.20 A folio as used here is a container for artifacts.

16

The MAP software architect is the focus of the MAP framework. As an entity the software architect creates and modifies architectures through its practices. MAP relies on other organizational frameworks (from the software development processes) to decide on how to organize software architects, their practices, documentation and architecture. MAP however represents only one software architect not software architects as a group so there it is not a recursive entity type.

The MAP system folio is a collection of software architecture models from the software architecture matrix. MAP supports recursion in the system folio since each system folio contains another system portfolio as seen in figure #, but nothing is specified on the how the parent system folio is related to the child system folio. MAP relies on the software development process to implement concepts like projects and hierarchical ordering of the models in the system folios. Each system folio is owned by a software architect and represents the architectural models that are part of the software architects responsibility.

Figure #13: MAP Entity Types and Their Relation

GERAM[4] has five different entity types: Strategic Enterprise Management Entity Enterprise Engineering/Integration Entity Enterprise Entity Product Entity Methodology Entity

The GERAM entity types[4] come from manufacturing based processes. Each one of the GERAM entity types[4] contains the GERAM lifecycle[4]. GERAM’s entity types are recursive [4] as demonstrated in figure #14. A strategic enterprise management entity initiates, defines and supports an enterprise engineering/integration entity. An enterprise engineering/integration Entity develops and builds an enterprise entity. An enterprise entity develops and builds a product entity. The enterprise engineering/integration entity and the enterprise entity are supported by the methodology entity.

17

Figure #14: GERAM Recursive Entity Types [6] Even though MAP and GERAM contain different entity types they [the entity types] are still compatible. GERAM doesn’t specify the structure that a software architect uses to store the artifacts of software architectures so it is possible for GERAM to use the MAP’s system folio entity type. GERAM does not view entities as granular as the software architect so MAP’s software architect entity type can also be used in GERAM. MAP uses the organizational structure of the software development process and/or on a lower level the company/corporation. As long as GERAM is compatible with the software development processes of the company/corporation it can be used by MAP.

4.9 Enterprise Modules

MAP does not specify enterprise modules directly. In the MAP framework the focus is on the software architect and his/her ability to create and modify software architecture(s), not on the process of creating or modifying software architecture. There is nothing in MAP that prohibits adding this functionality in the software development process or it’s integration into the company or corporation. This makes sense since there should be one integrated set of reusable modules that can be used throughout the enterprise not one that is attached directly to the software architect21.

4.10 Generic Enterprise Modeling Concepts

The Software Architect and how he relates to his practice is the “glue” that relates all of the MAP concepts together. A software architect as shown in figure#15 uses various artifacts as a method of communicating with the software architecture. He uses the practice (from figure#12) to give scope to this communication. The resultant software architecture can then be

21 MAP only represents the software architect and how the software architect acts as a professional. Libraries of code and other applications not linked to the software architect directly are out of scope for MAP.

18

communicated to different stakeholders. The software architect keeps logs, which can then integrate with project management or other software architects depending upon the process that is implemented.

Figure #15: The MAP Software Architect

GERAM (through ISO/TC184/SC5/WG1 (2000a) [4] describes the generic enterprise modeling concepts as containing: Glossaries Metamodels Ontology

MAP itself implements that glossaries, metamodels and ontology of the software architect. However it is the software architect through his tools, artifacts and logs that maintains this information for the software architectures in MAP22.

4.11 Enterprise Engineering Tools

MAP has seven different categories of artifacts that tool vendors need to support. Each category has some attributes that determine the minimal set of guidelines for choosing these tools as demonstrated in Figure #16.

GERAM[4] uses enterprise-engineering tools to construct, store, analyze and communicate models. These include tools that model the AS-IS[4] model and update those models. They should also support the storage and administration of the models. ISO/TC1854/SC5/WG1 (2000a) [4] defines other requirements include: Shared repositories Management and operation of enterprise operations Connecting to the operating environment to update a model Modularity and extensibility

22 It is important to remember that MAP is not an enterprise architecture framework and is itself an ontological framework. Everything refers back to the software architect in MAP.

19

Figure #16: Software Architect Artifacts

MAP relies on the software development processes or the company that implements the software development processes to set the standards for managing and administrating repositories. Other specifics of how these tools operate are also reliant on the implementations. MAP instead defines the need for different types of tools that include tools for delivering vision documents, blueprints, prototypes, ontologies and implementations of software. These might include repositories for the manipulating and managing blueprints, animated drawing tools for delivering the vision documents, development environments that create test harnesses for prototypes, tools that enforce the use of ontologies23 which includes patterns and other meta-models and tools that trace all of these other tools to the implementation of the architecture as a working system.

5 Conclusions

We have in this paper demonstrated that the MAP framework can be implemented using GERAM. This was done by comparing MAP with the lifecycle phases, life history, modeling framework, modeling languages, methodologies, reference models, entity types & recursive entity types, enterprise modules, generic enterprise model concepts and enterprise engineering tools of GERAM. This process illuminates the functionality of MAP and provides a mapping device for other enterprise architectures to integrate their concepts with MAP. Whole MAP remains a purely ontological construct, the act of implementing MAP into GERAM reveals the conceptual ties with other implemented frameworks.

23 Enforcing ontologies can be either policy driven or automated

20

References

[1] Albin, Stephen T., The Art of Software Architecture, 2003, Wiley Press, ISBN 0-471-22886-9[2] Arlow, Jim, Neustadt, Ila, UML and the Unified Process, 2002, Addison-Wesley, ISBN 0-201-77060-1[3] Beck, Kent, Extreme Programming Explained: Embrace Change, 2000, Addison-Wesley, ISBN 0-201-61641-6 [4] Bernus, P., Nemes, L., Schmidt, G. et al., Handbook of Enterprise Architecture, 2003, Springer-Verleg, Berlin ISBN 3-540-00343-6[5] Boar, Bernard H, Constructing Blueprints for Enterprise IT Architectures, 1999, Wiley, ISBN 0-471-29620-1[6] Herzum, Peter, Applying Enterprise Architecture, Cutter Consortium Executive Report vol. 6, No.3, 2003 [7] IFIP-IFAC Task Force on Architecting for Enterprise Integration, GERAM v.1.6.3, http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3/GERAMv1.6.3.pdf, March 1999.[8] Kleppe, Anneke, Warmer, Jos, Bast, Wim, MDA Explained, Addison-Wesley, 2003, ISBN 0-321-19442-X[9] Spewak, Stephen, Enterprise Architecture Planning, 1992, Wiley QED, New York, NY, ISBN 0-471-599859[10] The Open Group, TOGAF Enterprise Edition v. 8.1, http://www.opengroup.org/architecture/togaf8-doc/arch/, 2003[11] Zachman, John, Erecting the Framework Part II, Interview from Enterprise Architecture Magazine Online Spring 2004, Fawcette Publications

21