Supplementary files are available for this work. For more information about accessing
these files, follow the link from the Table of Contents to "Reading the Supplementary Files”.
Table of Contents
Go Back
Causal Architecture: aligning enterprise strategy and
operational dynamics with the enabling information technology.
Edmond F. Vail Ill
Ptech Inc.
500 Victory Road, Quincy, MA 02171
Ph: 617-689-0564 F: 617-689-0940
evail@ ptechinc.com
Enterprise Architecture (EA): An Enterprise Architecture is a set of aligned business and
IT models of an enterprise, as well as the key aspects of the governing processes
needed to keep these models applied and in a usable format.
System Dynamics (SD): System dynamics is a methodology for studying and managing
complex feedback systems, such as one finds in business and other social systems. It
rapidly identifies the high leverage variables in a system.
Zachman Framework (ZF): The Zachman Framework is a classification model
developed by J ohn Zachman to assist in the development and management of
comprehensive and aligned Enterprise Architecture models.
The Zachman Framework has proven to be a very rigorous and useful model for guiding
strategists and IT departments of businesses/government agencies in developing Enterprise
Architectures in an organized manner. Ptech Inc., a supplier of Enterprise Architecture
solutions through the use of its flagship product, Enterprise FrameWork™ , has found that many
of its clients have uniformly requested that resulting models be organized using the Zachman
Framework discipline. However, since the Zachman Framework was deliberately defined such
that it is independent of any methodology or tool, methodology and tool choices must be made
in order to effect implementation. To realize the benefits of architecturally sound
implementations, it is only prudent to make the method and tool choices consistent with the
logic embodied in the Zachman Framework. In this regard, Ptech offers some guidance
pertaining to:
¢ Ina given situation or state of event, which Zachman Framework cells would be of
greatest consequence?
¢ Whatare the specific high value interactions between cells?
To bridge these gaps, a new Enterprise Architecture methodology named “Causal
Architectures"” has arisen, which integrates the two powerful concepts of Causal Loop Diagram
(CLD) models and the Zachman Framework. The concept of CLD models is taken from the
System Dynamics discipline, which traces the cause and effect of relationships between
systems of related variables, while the Zachman Framework is taken from the Information
System discipline.
Information Systems Management Article: Causal Architecture Pagel
This article describes how Causal Architecture (CA) can be used to identify and create content
for the most relevant Zachman Framework cells, as well as how Ptech’s Enterprise FrameWork
solution can be used to interrelate the cells within the Zachman Framework. Two recent
examples of the Causal Architecture implementation will also be illustrated.
Zachman Framework Overview
The Zachman Framework’ is a classification schema based on the fundamental questions: who,
what, when, where, why and how, from the perspectives of the planner, owner, designer,
builder, vendor, and product implementation. The goal of the Zachman Framework is to ensure
that Enterprise Architecture integration and consistency is found by way of determining and
relating the architectural primitives as embodied in the individual cell models of the Zachman
Framework. From an inventory of primitive cell models defined and related, a virtually infinite
number of composite, implementation models can be constructed rapidly and inexpensively,
and maintained coherently, relative to the enterprise as a whole. Figure 1 is Ptech’s
interpretation of how some Ptech diagrams may map against the Zachman Framework. (Note:
This is not intended to represent J ohn Zachman’s view of the mapping.)
Locations.
Business Logistics
System
Distributed System
Architecture
Technology
Aschmecture
Network
Architecture
Network,
Figure 1: The Zachman Framework Matrix, as interpreted by Ptech
1 Extensive information on the Zachman Framework discipline can be found at http://www.zifa.com.
Information Systems Management Article: Causal Architecture Page 2
Sub-Optimal Performance: IT and EA Zachman Framework Development
Since the Zachman Framework is a framework without a built-in methodology, IT Enterprise
Architecture teams are typically faced with 36 cells, all of which are equally important. As a
result, some typical Enterprise Architecture team responses are:
“Let's start at random and pick a cell.”
“Let's start with Row 1 and work our way sequentially across the matrix.”
“Let's start modeling with cell [X] because we have something available to capture.”
Though understandable, none of these starting approaches are optimal, since they are not
guided by a value-based organizing principle. The Causal Architecture methodology was
developed in order to assist framework users with this dilemma.
Optimal Performance: The Zachman Framework Development Guided by CA
The purpose of the Causal Architecture methodology is to identify an enterprise’s key value
streams and high leverage factors, determine how they are related, as well as how they behave.
A high-quality CLD tells a systemic cause and effect story (See Figure 2).
IT Staff
Financial
Fo” , Resources Hiring
Total Available NS
Market
Network <_ architecture
ROX Features Quality
Legend: Mailed
> Relationship moves in same direction Share
© Relationship moves in opposite direction
FP Relationship has a time delay
Figure 2: Causal Loop Diagram
For example, in Figure 2, the CLD starts with Financial Resources. As resources increase, they
directly affect IT Staff Hiring and Network Features positively. Staff Hiring increases
Architecture Quality, which in turn also increases Network Features. As Network Features
increase, so does Market Share, looping back to Financial Resources, with an immediate
increase. In an unlimited market, this cycle would repeat indefinitely; however as Market Share
increases, the Total Available Market decreases and after a time delay, Financial Resources
would decrease as well, altering the cyclical pattern.
In a very succinct model, this CLD would trace the interactions between the key variables of the
mini-enterprise system. When developed in joint business and IT team workshops, the CLD
methodology similarly captures and integrates key variables across different components of the
enterprise, from strategies to processes and IT capabilities. When applied at an enterprise
level, the benefits of the Causal Architecture methodology are numerous:
¢ Assists with developing effective and integrated business/agency and IT strategies
* Encourages and facilitates active business management participation in EA development
* Ensures consistency, alignment and integration among business/agency and IT
strategies
Information Systems Management Article: Causal Architecture Page 3
* Guides prioritization, efficient development of high-value ZF cells
* Captures, shares, and analyzes all knowledge in a knowledge base, which is the most
powerful way to utilize Causal Architecture and create value, as it continuously
enhances and extends these functions
The CA methodology is enabled by Value Mapping.’ Value Mapping identifies the high value
EA composite variables, while Causal Architecture maps these high value variables to the
appropriate ZF cells.
Value Mapping
The purpose of Value Mapping? is to identify the enterprise’s high leverage, actionable value-
stream generating variables. There are two major forms of Value Mapping: visual and causal.
Both rapidly identify the key value streams and can be used for SWOT’ analysis and strategic
development; they differ in the style of their techniques.
Value Maps are interactive and participative, typically being created by cross-functional teams.
As a result, the maps benefit from multiple levels and perspectives. Both business and IT
teams have successfully used Visual Mapping and/or Causal Mapping - the choice predicated
upon the nature of the cross-functional modeling teams.
Due to their pictorial nature, Visual Mapping techniques appeal to many visually-oriented
business and executive modeling teams, as they are user-friendly and lend themselves to story-
telling of map relationships (See Figure 3).
Weakness/
Strength/
Threat
Opportunity
Figure 3: SWOT Visual Map°
? Knowledge Management Review, Knowledge Managementand the Value System by Edmond F. Vail Ill,
January/February, 2001. Melcrum Publishing Ltd.
For Visual Mapping techniques, visit Wild Water International at http://www.seemap.com or NewBase
International at VLRCENTER@AOL.COM
4 swort: Strength, Weakness, Opportunity and Threat. SWOT is a fast and powerful method of
assessing areas that can benefit from strategic investments.
5 Copyright © 2001 Wild Water International. Map made with SeeMap materials.
Information Systems Management Article: Causal Architecture Page 4
Compared to Causal Mapping, the major drawback of Visual Mapping is the inability to carry as
much causal information or contain greater variation in semantics. Causal Mapping’ techniques
appeal to many graphically-oriented IT and process-oriented modeling teams due to their clear
depiction of causal relationships. They support rapid identification of causal patterns and
effective causal story descriptions (See Figure 4).
Business
Unit Profit
Margin |
asc
BUSINESS STRATEGY Mati
Cresting Enterprise
Value
Business Unit
Improvea-— > Profitability
aa vin
ate
on
Reduced End SS S) win 7
i < Rate
freee oe Bsc
» ine
Mio
bo) ‘Shorter
procurement
falter Matching ot
Cycle
wre “bus. Reatsto iT
Technol. Growth
FS
Figure 4: Subset of a CA Value Map
A unique feature of these modeling forms is that the value variables of either can be created at
various levels of detail and type, with the sole requirement being that they are relevant in
creating value. To this end, interest remains in finding the higher value-creating variables and
their relationships, which leads us to the subject of prioritization.
Variable Prioritization
Effective prioritization focuses on two key areas: value contribution and actionability, but not all
enterprise variables are equal contributors to value. The Pareto principle of “trivial many, vital
few” would apply here, since there are many value-generating variables in a Value Map, but it is
critical to focus on those with the highest leveraging value. Another key focus area is that of
actionability. Can strategic or tactical investments positively affect the enterprise in relation to
this variable? The ideal actionability situation is a high leverage variable that provides a large
improvement with minimal investment. But even if a high-leverage variable is beyond the
control of an enterprise, there is value in knowing how and where it impacts, which is obtained
by carefully tracking and forecasting that variable.
Causal Architecture Development
Developing a Causal Architecture includes five steps:
1. Develop the value map
2. Perform a prioritized SWOT analysis
® Example of Causal Mapping: VIS-IT Hexagon Method from Vision Works, LLC (http://vis-it.com);
Example of CLD method described in Peter Senge’s first book, “The Fifth Discipline”. More info available
at http://www.albany.edu/cpr/sds/
Information Systems Management Article: Causal Architecture Page 5
3. Transcribe strategies and projects, based on the SWOT analysis
4. Divide the value map into sectors
5. Assign and map the sectors to the appropriate Zachman Framework cells
A common starting place for Causal Architecture is helping the Enterprise Architecture team
determine how their EA Program can add value to the related IT function. The goal is to create
a value map of the high-value IT variables, depicting the EA Program influencers. Another
common starting point is at a level higher, creating a value map of the high-value
business/agency variables, depicting the IT influencers (See Figure 5).
aa crating
Entrprite
value cS
auiren
uni
ai CREATING BUS. VALUE BE ig,
FA i complete?
Improved But, __aeet Contictng Bu
common Teshnisa nt Stntigien
irartructure Reduced End Product
a Cxle Time
Colaporton el ve.
fimariustur for shorbr tte Mating of Ir Funan
Customers? Foarvment -<— oul Requrementi io ‘2 competing
Parr Support eee Bae Lennit Trvion
went; Functional
Capabiition
7 Beant ave
Underutilavd IT CAPABILITIES Ea
Tcapacit;
auignmentot
Treveuuine a
ranet shatg?
Ke *s
implementabi
ring
tigt
snot tng a
Tnvertnente
Mapping Eusinens
Procea to Etlnting
Toit
Tr knoxtedgs
repoutony
Figure 5: EA Causal Architecture Value Map
The next CA development step is the SWOT identification and prioritization. Here, the mapping
team discusses the map variables and relationships and modifies them as needed. The team
then votes on the highest value variables, typically using “voting dots”, resulting in a voting dot
pattern yielding a prioritized set of SWOT candidate variables. Subsequent discussions confirm
the prioritized set, determine their SWOT type, and identify the strategically actionable items
(See Figure 6).
Information Systems Management Article: Causal Architecture Page 6
ao
So
as Unter
Margin
esc
bpportunity BUSINESS STRATEGY Mati
Sot
Business ‘Unit
Improved >” Profitability
pee “an
Rate
ol
Reduced SS S) ein
Product Cycle ise
Time
Matic
=, Shorter
Procurement
‘ue Better Matching of
S____ bus. Reqtsto IT
Technol. re
Figure 6: Subset of EA Causal Architecture Value Map
with SWOTs and Corresponding Strategy
The final value-mapping step is to write an “IT and EA Strategies and Projects” draft, which
leverages the Strengths and Opportunities and neutralizes the Threats and Weaknesses.
While creating a value-map set of consistent, aligned and implementable strategies is quite
valuable in its own right, the real payoff is the application of Causal Architecture in linking these
strategies to business and IT projects, which actually creates the value-creating capabilities.
Yet, even a short set of business strategies can generate numerous IT projects also needing to
be prioritized, aligned and checked for consistency. The ideal mechanism to produce these
results? The Zachman Framework.
Mapping to the Zachman Framework
If an Enterprise-wide, excruciatingly detailed model were to be developed for each of the
Framework cells, the result would be an explicit, gargantuan, yet finite and holistic model of the
enterprise. In other words, the Zachman Framework is conceptually comprehensive, including a
complete metamodel, knowledge map, relevant perspectives and abstractions of the enterprise.
This makes the Zachman Framework an ideal structure to exploit the capabilities of Causal
Architecture, enabling an enterprise shortcut to the high value-creating paths.
In order to map an individual CA variable to the appropriate ZF cell, one needs to identify the
most appropriate perspective and level of abstraction for that variable. In the ZF spirit of
“defining a cell at an excruciating level of detail”, it should be recognized that most CA variables
could be further decomposed.
The CA variables themselves are created from the value-mapping process at different levels of
detail and variable types, although the convergent part of their process helps level them, relative
to each other. Even at the same level of detail, some CA variables are high-level composites,
made up of more detailed items/concepts or act as discrete, single-dimension variables. So,
another way to proceed with mapping is to further decompose the CA variable directly until
either the desired level of modeling detail or the ZF primitives are reached. While this loses the
Information Systems Management Article: Causal Architecture Page7
summary and direct CA variable relationships at more detailed levels, it does provide a robust
decomposition to the ZF primitive level.
Often, a single high-value leverage CLD variable has several simultaneous causal relationships.
This is a good indicator that a more detailed in-context decomposition CLD (showing the higher-
level inputs/outputs) of this variable is required in order to fully understand the contextual CA
variable relationships.
Causal Architecture Sectors
Causal Architecture sectors are a common way of dividing up large CLDs for easier
communication, comprehension and navigation. A CLD sector is typically made up of a
functional or organizational group of related variables, such as a strategy sector, process sector
or IT infrastructure sector (See Figure 7).
Why,
How, Builder oar
eve |e ia ae
iw Own
tail BUSINESS STATEGY iroteea ty Why, er
a noone
aon eit ae eR) —— ee ae
te Udi 0 Sat ~
sete rons peewee
Aaie + |
gaptran
j
Figure 7: EA Causal Architecture Initial Sector to Zachman Framework Cell Assignment
In Figure 7, the CLD’s Business Strategy sector maps well with and is assigned to the Zachman
Framework’s “Why, Planner” cell, indicating that this ZF cell is now a high priority one for
modeling. Similarly, the IT Strategy sector and IT Projects sector are mapped and assigned to
the Zachman Framework’s “Why, Owner” and “How, Builder” cells, respectively, indicating that
these two cells are also high priority ones for further modeling. The next step is mapping these
CLD sectors to the most appropriate ZF cells (See Figure 8).
Information Systems Management Article: Causal Architecture Page 8
Figure 8: Initial Zachman Framework CLD Sector Cell Mapping
Here, the CLD Sectors are mapped to their appropriate row-column cell locations on the
Zachman Framework. They clearly indicate which out of the 36 possible cells should be
modeled initially, since they are the highest value leveraging cells to the business. Itis
important to note that every cell in the Zachman Framework is equally important and can be a
high leverage cell, and focus should not be solely placed on the strategy cells (See Figure 9).
Figure 9: EA Causal Architecture SWOT Opportunity, Corresponding IT Project,
and IT Capability Implementation
If a detailed decomposition isn’t needed, CLD sector views can also be designed to map closely
to ZF cells. This is done by examining the sector variables by type and then choosing the best
ZF cell match for the majority. The complete CA sectors can then be located in the appropriate
ZF cell to guide further detailed modeling.
Information Systems Management Article: Causal Architecture Page 9
Redefining Sectors can be done by moving variables to other CA sectors for a more appropriate
cell match or by performing a CLD variable decomposition if they are composites that can be
used in order to properly match a given ZF cell. Fora cell match example, CLDs often evolve
as a function of the relative unspecified order in which the team considers variables and their
positioning on the diagram as the relationships evolve. Generally, some subsequent variable
repositioning is needed in order to better group variables and minimize relationship crossovers
for clarity. As a result, sectors may end up including one or more variables that logically belong
to another sector. If they are high-leverage variables or have strategies related to them, then
they should be moved to the appropriate sector.
In the case of CLD variable decomposition, one would first need to decompose the CLD
variable into the appropriate level and number of sub-variables in order to maintain both
consistent internal sub-variable relationships, as well as the original variable’s external
relationships. These sub-variables can then be mapped to the appropriate ZF cells.
As in any form of modeling, the intended purpose and use of the Causal Architecture by
decision makers/knowledge workers should guide the use of sectors and the required depth of
CA decomposition. In general, since the primary purpose of Causal Architecture is to guide
subsequent EA modeling efforts in the high-value Zachman Framework areas, detailed CA
variable decomposition is not required. Instead, the appropriate modeling methods for those ZF
cells would drive further development.
As J ohn Zachman has stated on previous occasions, the ideal way to use the Zachman
Framework, given sufficient time and resources, is to model, descending vertically from Row 1.
This ensures that subsequent rows are wholly consistent with the perspectives of preceding
rows. While Causal Architecture relays a swift time-to-value impact short cut, it does run the risk
of creating models in a given column that may later be inconsistent with previous row cells. This
risk can be mitigated by modeling the preceding column cells in parallel, or as a next priority, to
a sufficient comfort level of detail that the high-leverage modeling work is thorough.
Examples of Clients Using Causal Architecture
Client A: Fortune 50 Insurance Company
Client Challenge:
Fortune 50 Insurance Company has started the Enterprise Architecture development
journey and has created an initial EA Core Team. The next task is to selectan EA
strategic direction. Questions posed: How quickly can they develop a consistent and
easily explicable set of EA strategies that clearly link and add value to their business
unit? In doing so, how can the Zachman Framework be utilized to support and manage
this type of modeling?
Approaches Employed:
* Process: A three-day EA Core Team workshop was used. Two CLDs were developed
during the first two days: the first, focusing on the potential value contributions of
Enterprise Architecture to the IT function; the second, focusing on the combined
potential contribution of Enterprise Architecture and IT on the business unit. During the
second day, the project sponsor invited the Senior VP of IT to drop in and review the in-
process CLD. After a few minutes’ study of the wall-sized CLD, the Vice President
easily picked out their three most important SWOT variables/potential contribution areas
to the business. Needless to say, these three were in the final set of SWOTs for which
the EA strategies was developed. After the workshop, the draft set of strategies was
refined to a final set and the CLD sectors mapped to the appropriate ZF cells.
Information Systems Management Article: Causal Architecture Page 10
* Enablers: A combination of Causal Architecture and Enterprise Architecture via ZF
modeling methodologies was selected. Causal Architecture was used to develop the
CLD, SWOTs, and strategies, while Ptech’s Enterprise FrameWork was used to capture
the strategies in a ZF model (See Figure 10).
¢ Results: The Causal Architecture methodology enabled their cross-functional EA Core
Team to quickly identify the key Enterprise Architecture, IT and business variables, inter-
relationships, and high priority variables. The Causal Architecture CLD was extremely
effective in describing the SWOT strategy opportunities in a senior executive context. A
final set of integrated and consistent EA strategies, supported by the CLD/SWOT value
relationships, was created, along with the final set of Enterprise Architecture strategies
mapped to the corresponding ZF cells.
Owners: focus
4 _Enterpnee Architect Stratmgis Plan
Zachman Cell: (Why, Owner).
gem —~2
(ase = = or ee
pacer a ‘
\ Focus Question: What areline hey
5 factors effecting te retail nahis
between the Gusinaae andi AD?
‘, 0 sateen tome W reaprene |
y /- =
Figure 10: ZF EA Causal Architecture Mapping to Corresponding EA Strategies
According to the company’s Architecture Director, "because the goals and discipline of
Enterprise Architecture are often misunderstood, we found ourselves being directed at all levels
of the architecture simultaneously. Causal Architecture allowed us to identify the key areas of
focus and, more importantly, demonstrate why and how those areas would provide the most
positive business impact."
Client B: Major US Defense Contractor
Client Challenge:
How can this Major US Defense Contractor most effectively develop, align and
communicate EA strategies to both their IT and the business units?
Approaches Employed:
* Process: A two-day workshop comprising of extended EA Core Team members from
both the business side and IT was used. The first day and half was used to create CLDs
covering “EA to business” and “IT to business”, along with their associated SWOTs; the
last half-day was used to develop the draft EA strategies. The company’s CIO, who had
just transferred to IT from one of the business units, helped the team with the business
Information Systems Management Article: Causal Architecture Page 11
value mapping. She ratified the SWOT strategy choices and helped in prioritizing them,
which was ideal, since these choices would correlate to her overall IT strategy. At the
end of the second day's session, the team decided that a third CLD was needed, to
cover the mapping of EA value contribution to IT. The following day, the sponsor, on his
own with no formal training, successfully led a third EA Core Team session to create an
additional CLD, focused on how the Enterprise Architecture would impact IT’s effective
and efficient execution.
¢ Enablers: The Causal Architecture methodology was used to develop the CLD and
SWOTs; while Ptech’s Enterprise FrameWork modeling was used to capture the CA
along with the draft strategies, which were then mapped within a ZF model (See Figure
11):
feet Business - IT Strategy SWOT Analysis
© Tic dear sou ikegn st i anec Som au Saeed [teen
Architecture variables for Business Strategy, IT Strategy and IT
= eel
sottui
poantee
i “ss a
“
and learn IT Opportunity
requirements on
“yp ag ——.,fagmert
TT strategie RD eos
Swat Create Weakness
Projectto map
tusnes Jt RSET open Business
= TFTools
sa —
linplainent av Repository
KnowladgeBace ©
a sD
Figure 11: Business - IT Strategy SWOT analysis
* Results: Within a rapid two-day Causal Architecture session, the EA Core Team had
developed a detailed understanding of the strategic linkages between EA, IT and the
business units. They gained experience in using Causal Architecture as a repeatable
methodology for involving business units, IT and Enterprise Architecture in joint
planning. They also created the capability of using the Zachman Framework for both
communication and management of EA, as well as a way for the most efficient
implementation of Zachman Framework.
The Enterprise Architect of the Defense Contractor in Minnesota, summarized, “we have used
Causal Architecture [here] as a starting point to identify the business objectives of greatest
strategic benefit to our Information Systems and Technology group. We are planning to use this
information to influence and prioritize the sequence, content and relationships among the
[Zachman] Framework cells we model.”
Causal Architecture and Zachman Framework Future Objectives
Causal Architecture is an evolving methodology with several promising development paths.
Further CA development objectives include:
Information Systems Management Article: Causal Architecture Page 12
* Causal Architecture decomposition to ZF primitives: Developing and analyzing common
patterns of CA variables to ZF primitives to guide and accelerate EA modeling.
* Dynamic Architecture® simulation: Quantification of the value contribution of ZF cells in
a Dynamic Architecture. Overlaying the corresponding CLD system dynamics simulation
model to quantitatively measure and follow the flow of value between the Zachman
Framework cells.
* EA Metrics: True Enterprise Architecture balanced scorecards. Since a Causal
Architecture is a balanced, systemic model of EA, itis an ideal way to develop truly
balanced and consistent EA, IT and business scorecards.
The Zachman Framework has proven to be a very rigorous, yet functional model for guiding IT
departments and businesses/government agencies in developing Enterprise Architectures in an
organized manner. As we have seen in the above discussion of Causal Architecture’s
capabilities, it can guide Enterprise Architecture teams to the fastest time-to-value development
of the Zachman Framework by focusing Enterprise Architecture modeling efforts on the highest
value leveraging cells.
Copyright © 2002 Ptech Inc. All Rights Reserved. Ptech, FrameWork, Causal Architecture and the Ptech
logo are all trademarks, service marks or registered trademarks of Ptech Inc., Quincy, Massachusetts.
Zachman Framework is a trade name of J ohn Zachman.
Back to the Top
Information Systems Management Article: Causal Architecture Page 13
CC BY-NC-SA 4.0