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 reuse. This concept is referred to in TOGAF as the Enterprise
Continuum.
Architecture models and views are discussed in detail separately.
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.
|