Tools for Architecture Development
Overview Issues
Evaluation Criteria
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 reuse. This concept is referred to in TOGAF as the
Enterprise Continuum.
Architecture models and views are discussed in detail separately
in Part IV. 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 capabilitities, 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 extendable to become a taxonomy?
- Active Glossary to enforce a taxonomy?
- Ability to represent architecture models and views in a way meaningful to non-technical
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
- On-line help
- Relevant out-of-the box various 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 reused?
- 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 life cycle support
- Does it provide full life-cycle 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?
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?
- Use of 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 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,
) and
strategical considerations (overall organization's standards and directions)
- Teaming can positively or negatively affect a tool's success.
Copyright © The Open Group, 2002