This section discusses tools and techniques helpful in using TOGAF.
42.1 Overview
As an enterprise architecture framework, TOGAF provides a basis for developing architectures in a uniform and consistent manner.
Its purpose in this respect is to ensure that the various architecture descriptions developed within an enterprise, perhaps by
different architects or architecture teams, support the comparison and integration of architectures within and across architecture
domains (business, data, application, technology), and relating to different business area scopes within the enterprise.
To support this goal, TOGAF defines numerous deliverables in the form of architectures, represented as architecture models,
architecture views of those models, and other artifacts. Over time, these artifacts become a resource that needs to be managed and
controlled, particularly with a view to re-use. This concept is referred to in TOGAF as the "Enterprise Continuum".
Architecture models and views are discussed in detail separately in Part IV, 35. Architectural Artifacts . This section discusses considerations in choosing automated tools in
order to generate such architecture models and views, and to maintain them over time.
42.2 Issues in Tool Standardization
In the current state of the tools market, many enterprises developing enterprise architectures struggle with the issue of
standardizing on tools, whether they seek a single "one size fits all" tool or a multi-tool suite for modeling architectures and
generating the different architecture views required.
There are ostensible advantages associated with selecting a single tool. Organizations following such a policy can hope to
realize benefits such as reduced training, shared licenses, quantity discounts, maintenance, and easier data interchange.
However, there are also reasons for refusing to identify a single mandated tool, including reasons of principle (endorsing a
single architecture tool would not encourage competitive commercial innovation or the development of advanced tool capability); and
the fact that a single tool would not accommodate a variety of architecture development "maturity levels" and specific needs
across an enterprise. Successful enterprise architecture teams are often those that harmonize their architecture tools with their
architecture maturity level, team/organizational capabilities, and objectives or focus. If different organizations within an
enterprise are at different architecture maturity levels and have different objectives or focus (e.g., Enterprise versus
Business versus Technology Architecture), it becomes very difficult for one tool to satisfy all organizations' needs.
42.3 Evaluation Criteria and Guidelines
TOGAF does not require or recommend any specific tool. However, in recognition of the problems that enterprise architects
currently face in this area, this section provides a set of proposed evaluation criteria for selecting architecture tools to
develop the various architecture models and views that are required.
Individual enterprises may wish to adapt these generic evaluation criteria to their particular circumstances and requirements.
In particular, such an exercise would typically produce weightings of the various criteria that can be used to produce a "score"
for the specific tools evaluated.
42.3.1 Tool Criteria
42.3.1.1 Functionality
Key Features and Functions
Does it support the framework that your organization has chosen to use?
Does it support production of the deliverables required?
If not, does it support some of the known frameworks; e.g., TOGAF or Zachman Framework out-of-the-box?
Glossary:
Glossary extendible to become a taxonomy?
Active Glossary to enforce a taxonomy?
Ability to represent architecture models and views in a way meaningful to non-Technology Architecture stakeholders
Does it support metamodels; e.g., ability to configure and tailor models?
Does it support enterprise use; e.g., multi-user collaboration support?
Does it allow drill down; e.g., conceptual, logical, physical, etc.?
Does it provide a mechanism for linking requirements to the resulting enterprise architecture; i.e., requirements
traceability?
Security features:
Does it facilitate access control; e.g., different permissions for different roles?
Does its security design support corporate security policies?
Does it natively support report generation?
Does it support a common language and notation?
Intuitiveness/Ease-of-Use Factors
An easy to follow "process map" guiding use of the tool
Online help
Relevant out-of-the-box architecture constructs, be it business, data, application, or technology
Relevant out-of-the-box templates or patterns for constructs, which can be used to help organizations "jump start"
Support for visualization modeling; e.g., drag-and-drop and lines that equate to links
Can it be extended or customized and does it provide utilities to do that?
Does it track and audit changes?
Does it provide a way for consistently naming and organizing those artifacts?
Can those artifacts/components be easily viewed, used, and re-used?
What requirements are there for use of programmatic languages?
Organizational Compatibility Factors
Internationalization/localization capability:
Can the tool be used in all the geographic locations and/or language domains in which architecture work is done?
Tool Capacity/Scalability Constraints
Does the tool have capacity constraints?
Size of data
Number of files
Number of data entries/records?
What are the tool's design "sweet spots" (i.e., optimal design configuration parameters), and how scalable is it around those
optima?
Is there an upgrade path beyond the capacity constraints of the tool?
42.3.1.2 Architecture of the Tool
Repository distributed or central?
Dynamic repository?
Does the tool function with multiple industry standard data stores (e.g., Oracle, Sybase) or is storage proprietary?
Backwards-compatibility with prior releases of the tool?
Does it allow integration and consolidation of data into a central repository?
Does it include version control?
Is it accessible through a web client?
What platforms (hardware, OS, DBMS, network) does it run on?
42.3.1.3 Full Lifecycle Support
Does it provide full lifecycle support?
Does it support various relevant views out-of-the-box; e.g., Business Process, Data, Application, Technology?
Does it support the creation of custom views?
Does it use modeling methods and techniques relevant to this enterprise's architecture practice?
Does is support simulation?
Is the model that it produces executable?
42.3.1.4 Interoperability Factors
Import/Export:
Can it create an artifact inside the tool and export it to other commonly used tools, and have the users of those tools use the
artifact intact?
Can it import an artifact created in another tool, and use the artifact intact?
Does it integrate with other tools?
Does it provide and support industry standard APIs?
Does it use relevant industry standards; e.g., XML, HTML, produce hypertext, UML, other industry standard?
42.3.1.5 Financial Considerations
What is the acquisition cost?
What is the total cost of ownership?
Maintenance
Equipment costs
Support costs
Number of resources required to keep it up-to-date
Administration responsibilities/time constraints
Will there be any impacts of introducing the tool into your environment; e.g., does it require some unique infrastructure?
Training
Licensing models
42.3.1.6 Vendor Factors
Will vendor remain viable?
How long has vendor existed in this arena?
Do they have large customers?
Do they have professional services?
Third-party support?
Does the tool have history at the organization and, if so, what is its reputation?
Has the vendor certified the tool within The Open Group's TOGAF certification program?
Training factors:
Availability
Costs
Amount required to become productive
Style of learning (CBT, classroom)
42.3.2 General Pointers
Value of the tool is dependent upon the architecture maturity of the organization.
Need to match the tool to the capability of your organization; i.e., where it is architecturally?
Trade-off between tactical considerations (competency, familiarity, etc.) and strategical considerations (overall
organization's standards and directions).
Teaming can positively or negatively affect a tool's success.
The TOGAF document set is designed for use with frames. To navigate around the document:
In the main Contents frame in the left margin of the page, click the relevant hyperlink to load the Contents List for that Part
of the TOGAF document or go direct to a chapter within the document.
Within a chapter you can select Previous and Next at the top and bottom of the page to move to the previous or next chapter, or
select Home to return to the welcome page.
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.