1. Implementing the MAP Framework1
using GERAM2
Mark Goetsch
DePaul University
School of Computer Science
Chicago, IL
mgoetsch@AgileArchitecting.com
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 Methodology
3
Zachman refers to the Zachman framework except where noted
4
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 Process
7
XP is Extreme Programming, a software process developed by Kent Beck
1

2. 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
architecture
9
UML Profile is a method for defining stereotypes and tag values in UML. It captures the ontological information
in the meta layers
10
Periodic Table is the official table of recognized elements used in Chemistry
2

3. 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

4. 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

5. 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 Process
In 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

6. 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 same
method 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

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

8. 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 Phase
Candidate Identification
Candidate Concept
Candidate Requirements
Candidate Preliminary Design
Release Detailed Design
Release Implementation
Release Operation
Legacy Decommission
Table #1: Implementing MAP Lifecycles into GERAM Lifecycles
8

9. 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.1
Team B Candidate B.1
Team 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

10. 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
15
Axis is equivalent to dimension
10

11. level defines architectures across practices, vendors and reference architectures. The top level
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

12. 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 Views
Manifestation Implementation Purpose Model
Content
Engineering Integration Modeling
GERAM Particular Performance Integrated Particular
GERAM Partial Practices Vendor Reference
GERAM Generic Quality Product Pattern
Table #3: Mapping the MAP Software Architecture Matrix to
17
Issues refer to a similar architectural set of concerns
12

13. 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

14. 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 Structural
Requirements
Conceptual
Logical
Physical
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

15. 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 Explanation
Covering 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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