Tools for Architecture Development
Overview |
Issues in Tool Standardization |
Evaluation Criteria and Guidelines
This section discusses tools and techniques helpful in using TOGAF.
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, Applications, 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 Developing Architecture
Views . This section discusses considerations in choosing automated tools in order to generate such architecture models and
views, and to maintain them over time.
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.
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.
Tool Criteria
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 meta-models; 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, Applications, 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?
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?
Full Lifecycle Support
- Does it provide full lifecycle support?
- Does it support various relevant views out-of-the-box; e.g., Business Process, Data, Applications, 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?
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?
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
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?
- Training factors:
- Availability
- Costs
- Amount required to become productive
- Style of learning (CBT, classroom)
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
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents
List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
return to top of page
Downloads
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 hardcopy book is also available from The Open Group Bookstore as document G063.
Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group