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.

return to top of page