Published in TDAN.com January 2003
Enterprise Architecture (EA) is gaining support within both the business and government communities. While these initiatives are gaining acceptance, it’s quite possible that Enterprise
Architecture (EA) is a repackaging of information planning ideas and approaches that we’ve encountered in the past. If this is true, why do we need a new way of thinking about some pre-existing
ideas?
When it came to enterprise architecture, I felt like one of the actors in a popular commercial for an office supplies company. Two women are standing in an elevator listening to the music. One
woman asks “who performs that song?” The other woman responds with the name of a group. Obviously, she was wrong, because, when the elevator doors open, there stands Dick Clark, who provides the
name of the song, the group that originally recorded it, when it was recorded, and many other pertinent facts. The message of the commercial is “when you have a question, ask an expert.”.
Ptech’s Framework is positioned as one of the frontrunner products to support EA initiatives. Ptech is also one of the founding sponsors for EACommunity, a website committed to “obtain and share
knowledge about the Enterprise Architecture industry, solutions and technologies.” (www.eacommunity.com). I decided that one of the best experts available
to me on Enterprise Architecture is Ptech’s Chief Product Officer, James Cerrato.
An Interview with James Cerrato
What is Enterprise Architecture?
Enterprise architecture looks at the business landscape by providing insight into the enterprise from every key dimension. These key dimensions include the business intent, as represented by its
mission, objectives, strategies and performance measures, its business organization, business processes and policies, and supporting application architecture.
The enterprise architecture also focuses on the drivers of change (strengths, weaknesses, opportunities and threats) to determine the potential impact on the enterprise by examining the linkages
between these key dimensions. The emphasis of change management is to determine whether the enterprise maintains its alignment between the key dimensions when change occurs.
Finally, the enterprise architecture is an essential component in capability management, which is used to assess the touch points between the value that the enterprise is attempting to create for
its customers and the internal organization’s ability to successfully deliver those values.
IRM people have been pushing the need for enterprise-wide architectures since the ‘80s. How does EA differ from previous enterprise-wide initiatives?
Enterprise Architecture is not new. It represents an evolution of what has come before it. But, it is now more practical and tangible. The supporters of enterprise architecture initiatives
recognize that EA projects must not employ an all or nothing approach. Projects are limited by politics, budgets and deadlines.
Consequently, EAs must evolve over time. They are developed using a goal-oriented approach so that the EA dimensions are fleshed out to support specific decision-making capabilities. Each phase of
the EA is planned by answering the question, “What parts of the enterprise architecture must be put in place to achieve the goals of this specific business project?”
Why has EA become important now?
The Federal Government currently mandates the development of an Enterprise Architecture roadmap for each of their agencies. Their management, and management within commercial organizations,
recognizes that the time available to them to respond to change is rapidly reducing. Having a clearly articulated blueprint of their critical enterprise components is needed as an aid in
determining how to shift directions rapidly and correctly.
The difference now is that effective technology is finally available to support and manage an enterprise architecture. These products can provide a knowledge gateway into the enterprise
architecture by integrating operational data with the objectives and performance metrics they support.
How do these architectures differ from the Zachman Enterprise Systems Architecture (ESA) Framework?
The Zachman ESA Framework is just that, a framework for organizing your enterprise content, not an architecture. As a classification scheme, the ESA provides a mechanism for thinking about how to
build an enterprise architecture by representing its components. A number of similar frameworks have emerged for developing enterprise architectures, such as JArch for planning.
Do EA initiatives address all the cells in the Zachman framework? If not, which ones are omitted?
An EA is a planning tool that is used by management to plan and design its business operational environment. As such, an EA is addressed through the upper rows of the Zachman ESA framework. The
lower rows represent the infrastructure and components of the operational environment. Therefore, these rows are dictated by the EA, but not part of the EA.
How does EA differ from Enterprise Architecture Integration? Enterprise Application Integration?
The various EAIs are an operational issue, not an enterprise architecture integration issue. Vendors are addressing these operational integration issues. These activities are complimentary to EA.
They are a component of the IT perspective of an enterprise architecture.
We’re talking a lot about enterprise this and enterprise that. How do I know if I’m dealing with an enterprise or just a business unit within an enterprise?
An enterprise can exist at many different levels within an organization. But, to be an enterprise, it must have the ability to control its direction in each of the key dimensions. If anything is
mandated or passed down from a parent organization, it probably doesn’t qualify as an enterprise.
How Ptech’s Framework Measures Up
As a first step in selecting any tool, I develop criteria against which I review each candidate product’s features and functionality. Following is the criteria I use when assessing products
designed to support an Enterprise Architecture Management environment. Let’s see how close PTech’s Framework 6.1 comes to my ideal product.
Full Framework Support
Frameworks, such as the Zachman Enterprise Systems Architecture (ESA) Framework, are essential in developing an enterprise architecture. To address all the architectural needs of an enterprise that
consists of multiple communities, an EA can be quite complex. The framework provides a roadmap into the architecture. An EA tool must have the ability to support the enterprise’s chosen framework,
with each component of the architecture, its diagrams and associated documentation classified to a component within the framework. The tool must provide the ability to navigate through the
architecture via the framework components.
PTech’s Framework product provides an underlying architecture that is well suited to support frameworks, such as the Zachman ESA. Framework supports a network of diagrams by allowing any diagram
symbol on a diagram to be related to other diagrams. One use of this feature is to create a hierarchy of diagrams that allows you to navigate from summary level diagrams to diagrams of increasingly
more detail. You can also link related diagrams together, so you can easily move from one aspect of the enterprise architecture to another. For example, you can move from the organizational view of
the enterprise to the process perspective by linking each organization in the enterprise structure diagram to the diagrams of the activities for which it is responsible.
Framework’s designers also recognized that executive management is one of the primary stakeholders of an enterprise architecture. So, to assist the EA analyst in developing diagrams that
communicate to all stakeholders, the Framework designers provided a set of meaningful icons as the mechanism for representing a diagram’s symbols. For example, a goal is represented by a target
with an arrow in the center of the bull’s eye; a supplier icon has trucks leaving a warehouse; software is a set of CDs. If these icons don’t fit your needs, you can change them to whatever
graphic best communicates the concept for your organizations. So there is no need to maintain separate diagrams for management and another that provides the detailed views necessary to fully
articulate the enterprise architecture.
Within Framework, you can use the Zachman ESA as a portal into your enterprise architecture by organizing your diagrams according to the ESA’s cells. Initially, you are presented with the ESA
spreadsheet (Figure 1).
Figure 1: PTech Framework Zachman Enterprise Systems Architecture Framework Diagram
When a cell is clicked, another diagram is opened that provides a brief explanation of the purpose of the cell and the types of diagrams that the Framework designers recommend for this cell. As you
create your enterprise architecture diagrams, you can link them to the appropriate cell. You can also create a reference from each diagram back to the ESA cells it supports. As a result, your
enterprise architecture can easily be navigated within the perspective of the ESA framework.
Additional industry framework are available as add-ins to the basic product. You can also build one customized for your organization, using Framework’s extensibility features.
Traceability
A key feature of an EA tool is its ability to trace model objects across the entire architecture. By this, I mean the ability to ask questions like “tell me all the use cases that support the
“achieve higher sales” objective”, “for those use cases, which databases do they use?” or “who are the business stewards of those databases?”. Traceability also lets you check the
completeness of your architecture and associated implementations. You should also be able to ask questions like “do I have any database columns that are not used by any module?” or “are there
any business objects that have no supporting business processes?”. If the answer to any of these types of questions is “yes”, then your implementation may be out of synch with your enterprise
architecture.
Framework provides traceability across the columns of the Zachman ESA through its related diagrams capabilities. For example, organizations can be related to the processes they are responsible.
Business processes can be associated to the business object classes they use.
The ability to navigate from a parent diagram to its subdiagrams is automatically provided by the product. However, the links necessary to move from a subdiagram to its parent diagrams requires
some manual intervention. There are several options you can use to establish these links between diagrams. First, if you realize that you probably want to navigate from subdiagram to parent
diagram, you can set the “Add Parent Reference to SubDiagram” option. This will cause the reference to be automatically set when the subdiagram is created. A graphic reference is created as a box
with the parent diagram’s name. The box behaves like a hyperlink which causes the parent diagram to be opened when selected. Should you forget to set this option before a subdiagram is
established, the graphic reference can be created manually. Finally, you can create a “roadmap” diagram, create graphic references from each of your enterprise architecture diagrams on the
roadmap and establish the relationships from subdiagram to its parents. Now, when a parent diagram is open, it is possible to navigate to its subdiagrams through the related diagrams feature. While
the objective of being able to navigate between parent and subdiagrams is accomplished, this is an awful lot of work, especially when most of the relationships already exist within the
knowledgebase.
Another traceability capability I look for in a product is balancing between a parent business process diagram and its subdiagrams. For Framework Business Models, I would expect the ability to have
resources and products defined on the parent diagram be automatically propagated to its subdiagram, so that they can be linked to the subprocess they are involved with. Likewise, the ability should
exist that allows the modeler to specify whether flows defined on a subdiagram should be propagated up the hierarchy successively to each parent diagram.
Framework does not support automatic balancing for process diagrams. However, queries and reports can be created that can be used to identify balancing discrepancies.
Framework provides no automated support for traceability between the business models (Zachman ESA Rows 1 and 2) to the technical models (Zachman ESA Rows 3 and 4). I look for the ability to have my
first cut data model or object class model generated from my business object class model, but no such facility exists in Framework. Similarly, I think of the activities assigned to a system
resource in a business process swimlane to be the first cut set of use cases for my application. There is no automated generation facility from business process model to technology perspective.
These links can always be established manually. For example, I can create a Use Case subdiagram for each business activity or operation. I can create a UML Class Model of the structure that is
needed to instantiate each business object class. So, while I’d like to have my first cut at the technology diagrams generated and automatically linked to the business objects they support, I can
achieve most of the traceability I require at this level through manual processes.
The next level of traceability is the generation of the actual application code, both for my persistent data stores and program code. Framework provides limited code generation capabilities out of
box. However, you have the ability to create your own code generation modules using Framework’s extensibility features.
Multi-Disciplined
I never expect all the communities within an enterprise to use the same methodologies and diagramming approaches. Some prefer to use IDEF or Information Engineering. Others are driven by their
implementation technologies, so they select UML to model the business requirements and applications that are ultimately going to be built using object-oriented techniques, while people building
data warehouses are more interested in representing their data using star-schemas. No single approach is going to be sufficient to meet all the needs of the enterprise.
So any product that supports EA is going to have to be multi-disciplined so that all these dialects can be supported.
Framework is primarily oriented towards defining, documenting and communicating enterprise architectures, for which there aren’t yet many standard methodologies and diagramming approaches.
Consequently, the Framework architects have developed their own business modeling methodology and techniques by integrating diagrams from the best practices for representing business, process, data
and technology architectures. These diagrams include organization charts, strategy decomposition diagrams, object class models, swim lanes, activity diagrams and technology architecture and
infrastructure diagrams.
But Framework does not fully support any industry standard methodology or diagramming approach. While many of its diagrams are UML-like, most do not conform completely to the Unified Modeling
Language (UML) standard notation.
From the business modeling perspective, I don’t have any problems with the fact that the Framework architect compiled their own methodology and set of diagrams for representing an organization’s
enterprise architecture. I don’t believe that any one methodology has emerged to date to be considered the standard for business modeling. Therefore, the fact that PTech has taken a the initiative
by providing this initial set is definitely a step in the right direction.
However, as the focus moves to the lower rows in the Zachman ESA framework where industry standard approaches do exist, I prefer a product that supports as many of these as possible. Most of the
companies I work with have already selected their data modeling methodology, usually either IDEF1X or Information Engineering. Companies developing object-oriented applications expect full support
of UML. Data Warehouse designers expect support for dimensional models. I’ve learned that most of these modelers would rather fight than switch. I prefer a product that allows me to satisfy as
many of these stakeholders’ needs as possible, in order to east the process of migrating their models and activities to the integrate enterprise architecture environment.
Unfortunately, Framework, out of the box, provides very little assistance in this area. To its credit, Framework’s extensibility capabilities are so strong, an organization’s modeling
methodologies could develop add-ins support most of their modeling standards. But, I’m not sure that this is the best investment of these people’s time.
Common Repository
An EA is comprehensive in nature. The same information must be presented in many different formats, including diagrams, matrices and definitions. You must be able to easily navigate from one
presentation style to another. Consequently, a knowledgebase must exist that supports the entire EA.
Framework uses a knowledgebase with consists of the diagrams and all the metadata that describes those diagrams and the objects that comprise or support those diagrams. A set of forms exists that
contains information that is meaningful for each object type, including the relationships to other object types. From one object’s form, you can easily open the form for any related object. When a
new form is opened, all the current forms remain open. Tabs allow you to easily move from one form to another. You can also adjust the size of the windows so that the forms can be easily viewed
side by side.
The query facility provides an alternate way to quickly view the relationships between objects in your knowledgebase. You can think of a query as providing a view into the knowledgebase, much like
a SQL statement provides a view into a relational database. You select the diagram or object that you want to evaluate and run queries against it. The result is a list of objects that satisfy the
question asked. For example, the “all superclasses” query navigates the selected object’s inheritance hierarchy and returns a list of the names of all its superclasses. Framework provides a
number of standard queries for commonly asked questions. In addition, Framework provides the Computed Function facility, an environment for building custom queries using a graphical approach.
Extensible
As the discussion of frameworks and methodologies highlighted, you can expect to find many different approaches and methodologies used within the same enterprise. Furthermore, you will often find
that these methodologies have been tailored to meet each community’s specific needs. Minimally, most organizations need the ability to add properties to existing model object types available
through the repository. I’m always adding additional model objects types, as well, to support emerging methodologies, such as the Business Rule Approach, that have not yet gained popular
acceptance.
In addition to extending the metamodel for the underlying repository, I’d like to customize the symbols used for the model object types on the diagrams. Currently, I keep the master set of
diagrams in my modeling tool, but often must develop a second set for presentation purposes. By customizing the symbols used on the master model, I could bring the master diagrams into my
presentation software and minimize the need to rework.
Finally, since there are very few diagramming methods that have gained acceptance at the business planning level, I have created an entire set of diagrams to communicate an organization’s mission,
goals and strategies in graphical format. Once again, if my modeling tool allows me to build a custom set of diagrams specific to my methodology, I can keep all my master models within the same
environment, rather than maintaining some in my EA tool and others in PowerPoint presentations or Word documents.
Framework’s extensibility capabilities are impressive, to say the least. The product provides an extensive collection of facilities to extend almost every aspect of the product. If the
functionality you want isn’t included as a standard feature of the product, you can probably extend it to support that need.
The primary approach to extending Framework is by enhancing its metamodel. Through this approach you can add or modify object classes and associations, object class properties and constraints. You
can create entirely new diagram types simply by creating a model of the object types that the diagram contains and the associations that can exist between them, including uniqueness and naming
constraints. You can even customize the graphic icon that is used to represent each object type on the diagram. You can create additional forms and queries based on your enhanced metamodel.
For those enhancements that can not be implemented through a metamodel, Framework provides its Abstract Code Generation (ACG) facility, which is a programming scripting language. Using ACG, you can
generate templates for reports, import or export file formats, such as XML, or program language code, such as JAVA or SQL statements.
Once learned, Framework extensibility facilities are very easy to use. Anyone who understands the Framework metamodel and knows how to develop an object class model in Framework is ready to extend
the metamodel. The key is that the modeler is an experienced metamodeler. Anyone using ACG should be an experienced programmer.
PTech encourages 3rd party providers provide “accelerators” that use Framework’s extensibility features to enhance the product to support additional methodologies. For example, Business Rule
Solutions has developed the Business Rules Accelerator (BRA) to support their Proteus ™ Business Rule Methodology. I used BRA to develop the following diagram (Figure 2) which is part of the
enterprise architecture for the Business Rules Forum, an annual conference that is jointly owned by Inastrol and Business Rule Solution.
Figure 2: Business Rules Forum Business Rules Map
Developed using the Business Rule Accelerator (BRA)
Model Management
Each community within an enterprise may be responsible for developing its own portion of the overall enterprise architecture. In this situation, each community may require its EA tool environment.
At some point in time, it will be necessary to merge these knowledgebases together into the enterprise’s integrated EA.
Model Management is the process of ensuring that the information held in these related knowledgebases is consistent with one another. As part of model management, models can be compared to identify
any overlaps, divergence and conflicts. Models can be merged with the ability to specify the rules for resolving conflicts. Additionally, the ability to create a new knowledgebase by extracting
diagrams and definitions from an existing model must exist.
Since many people will be working on different portions of the enterprise architecture at the same time, an EA tool must be network-enabled to support multiple users. The product must provide
locking capabilities to prevent simultaneous modifications to the same definition or diagram. Ideally, the tool should provide a mechanism of letting users know who has locked a definition or
diagram and provide a notification when the lock has been released.
PTech provides a complimentary product, Teamwork that provides model management facilities. A Knowledgebase Administrator defines the knowledgebases to be managed and authorized users to the
Teamwork environment. Access can be defined at the diagram level to ensure that each user can only change diagrams to which he is entitled.
Teamwork allows multiple people to modify the same knowledgebase by providing a check-in, check-out approach to knowledgebase sharing. The knowledgebase is not shared in real time. Consequently,
users are not aware that they are working on the same diagram at the same time. When a user starts a session, a copy of the requested knowledgebase is downloaded or refreshed. At the end of the
session, the user can elect to merge his modification back into the master version of the knowledgebase. The user is led through an interactive session to resolve conflicts, so that any changes
made by others are not incorrectly overwritten.
When an organization uses Teamwork as part of their model management strategy, they can partition the comprehensive enterprise architecture knowledgebase into a set of nearly disjoint
knowledgebases that can be used by the individual teams. At the appropriate time, the knowledgebase administrator can merge the team-oriented knowledgebases back into the master knowledgebase. With
this strategy, the organization can maintain its enterprise-wide view of its enterprise architecture while minimizing the possibility of conflicts occurring at the team level.
Versioning and Release Management
Versioning Control and Release Management are an important aspect any Model Management facility. Versioning is the process of keeping track of each modification made to a diagram and to a specific
model object’s definition. Release management is the process of coordinating the modifications to a group of model objects and diagrams that must be treated as a unit. A release should only
contain one version of a model object or diagram. Releases tend to be time-oriented, by describing the state of the model objects involved in that release at a specific point in time. For example,
EA Release 1 contains all the diagrams and model objects for the enterprise architecture, as published on June 5, 2002. EA Release 2 contains all the diagrams and model objects that will be in
effect for the enterprise architecture when published in July, 2003.
Versioning and Release Management are essential in conducting impact analysis on an evolving enterprise by examining the effect of a change on all future versions of the enterprise architecture.
Out of the box, Framework does not provide any version control or release management capabilities. However, by carefully structuring your knowledgebases to reflect each major release of the
enterprise architecture and using Teamwork, you can gain some level of release management. While this approach only provides limited release management capabilities, it definitely better than no
support at all.
Shareable
At some point, the developers of the EA must share their efforts with others in their community. This means that an EA tool needs to be able to provide access to the information held within the
tool to people who don’t have access to the tool. The format of this information can be either as a website that provides the ability to navigate through related diagrams and definitions, and as
documents or presentations formatted to my preferred word processor or presentation software.
The product should include predefined report templates. But, once again, I find that few products have been able to anticipate exactly the structure and content details that I want, so a report
generator is also a necessity.
Framework provides a report facility that can be used to rapidly create an HTML version of a diagram. The generated website consists of the diagram image with links to description pages for
selected objects. The diagram image is not clickable. Framework comes with a predefined set of reports that can be generated. The Project Detail report creates a complete website of your entire
project, complete with clickable diagrams that allows a user to navigate through the entire project’s diagrams and supporting metadata, using their internet browser.
There is no end user-friendly facility for your analysts and modelers to use to create their own reports, customize the standard report set or generate reports to other media, such as Word or
PowerPoint. However, anyone experienced with ACG can create scripts that will generate almost any type of reports that your organization requires.
Import and Export Capabilities
As much as we’d like to have only one tool that satisfies the needs of the entire enterprise, the reality is that different communities will use different products for managing their information
systems. At some point, you will need to provide access to the information within your EA tool to others or have the desire to load data from other products into your environment. Some vendors may
have anticipated this need and provide direct translations between specific products. But, the reality is, most vendors won’t provide these capabilities for every tool you may encounter within
your enterprise. So, some level of import and export capability must be available.
Ideally, an EA product vendor will conform to some standard format to facilitate communication with other tools. Unfortunately, there are so many standard metadata exchange formats and none as
emerged as the obvious accepted standard. So the probability of any EA tool providing an automatic translation into one of these standards is slight. However, it is a capability that I always look
for when selecting any tool that holds metadata.
Given the predominance of XML, I now expect any tool to be able to support XML import and export. And provide the specification for its DTD.
I’d also like the ability to import and export the diagrams, as well as the supporting definitions. Given the amount of time it takes to layout a diagram, it would be nice to salvage that effort
when moving between tools.
Framework’s reverse engineering feature can be used to import text files in .CSV format. A wizard is provided that allows you to map the input file to your project’s metamodel. Framework does not
provide any support for exporting any formats other than its own knowledgebase format. ASG can be used to build your own customized export facilities.
Ease of Use and Learning
A product can be the powerful tool around, but it’s worthless if it’s so difficult to learn and use that your analysts are not willing to use it. A tool needs to allow the analyst to choose the
technique for entering a model object’s details, including the linkages between model objects. The notation for diagrams should be consistent with the methodology they support. The techniques for
entering diagrams should be consistent across all diagram types.
The product should support a standard GUI interface for the technology that it’s implemented in, such as Windows or the Web. Standard graphic management capabilities should exist, such as the
ability to select one or more symbols and move them as a group, resizable symbols, lines that track as the associated symbols are moved, the ability to move lines from one symbol to another without
having to delete and redraw the line and the ability to customize the diagram’s format in terms of color and fonts.
Framework provides a project work space that includes a project organizer presented as a standard file folder browser, diagramming frame, a document frame where descriptive information can be
entered and an output frame where the results of Framework’s processing is displayed. You can create whatever folders you need in the browser to organize your project in a meaningful manner. Each
diagram type has its own set of symbols that can be displayed in its own window. The palette is dockable allowing you select the location that best meets your needs.
Multiple diagrams can be open at the same time. Each diagram has its own tab that can be used to navigate between them.
Lines track very nicely to be centered with the symbols they connect. If one symbol is moved to a point where the line would look best on a slant, the orientation of the line is automatically
repositioned. Joints can be easily added to a line so it can be bent to route around symbols and other lines.
The product provides support for the standard Graphic User Interface formatting capabilities including rubber banding symbols to select them, symbol alignment to one another and to a grid, control
over how the diagram’s symbols’ fonts and colors, spell checking and Undo.
The tutorials that accompany Framework are some of the best that I’ve encountered. They don’t just show you how to use the product, but introduce enterprise architecture analysis concepts as each
new diagram type is introduced.
Framework’s naming standards for its metamodel object properties start with special symbols, such as #, ! and *. While this may help in classifying properties for the tool, they can be confusing
when made visible to the user of the product. They tend to pop-up everywhere when using the tool. For example, I right clicked on a symbol and selected “Object Report” expecting to see the
information I had entered into the object’s form, such as its description. Instead, I was presented with an indented list of metadata property names with their strange name that may make sense to
the product’s metadata architect, but was totally meaningless to me. Framework end users must be aware of the meaning of these metadata names when creating links between objects on the diagrams.
It would be so nice if these cryptic names were translated into something meaningful to the end user.
In Conclusion
PTech’s Framework and Teamwork products, collectively, are a strong contender for any organization looking for an environment to support their enterprise architecture initiatives. Their strength
is in their support for the Business Planning and Analysis phases (Zachman’s ESA Rows 1 and 2). Framework also provides solid object-oriented diagramming features, if you are not entirely married
to UML.
PTech’s intention is to provide outstanding products for developing, communicating and managing an organization’s enterprise architecture. Their support for the application and database
development exists, but is not as robust as their business planning features. Strategically, PTech is positioning Framework to satisfy a major need organizations are facing in articulating their
enterprise architecture, while providing the ability to extend the product to satisfy each customer’s specific technology modeling and generation requirements.
They appear to be succeeding in their strategy quite nicely.
