1. art and entertainment
2. visual art and design
3. architecture

Why Enterprise Architecture is an Oxymoron
Search ::
Submit
YOUR ACCOUNT :: [ Profile ] [ You have no new messages ] [ Logout (Jukka Heikkilä) ]
[ Advanced ]
View Printable Version
Why Enterprise Architecture is an Oxymoron
by Dan Appleton
ARTICLES ARCHIVES ...
February 2008
The Need for Smart
Enough Systems (Part 8)
~ Contributing Value to
your ROI Calculation:
Revenue Growth
By James Taylor & Neil Raden
January 2008
Traceability Aspects for
Business Rules
Management
By Mukundan Agaram
January 2008
The Need for Smart
http://www.brcommunity.com/b191.php (1 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
This is an excerpt from The McCafferty
Chronicles. The McCafferty Chronicles relate a
series of discussions led by Michael M. McCafferty,
Chief Transformation Officer, on the general topic
of enterprise transformation. These discussions
range widely over the topic and involve many
different folks of many different interests and
skills, depending on the subject.
One of McCafferty's pet peeves is the propensity
of IT folks to treat enterprises as if they we just
"big 'ol systems or systems of systems." This is
simply a wrong-headed view of enterprise,
perpetuated by the popular concept of 'enterprise
architecture' -- a concept long past its sell-by
date.
Alan Sverdlow swept into McCafferty's office like Rudolf
Valentino making one of his grand entrances into a
ballroom filled with admirers. The smile on his face
reached literally from ear to ear, and his eyes were
twinkling. He looked flush with victory.
"One and a half million dollars," he blurted. And he
reached over his own shoulder to pat himself on the
back. "One and a half million dollars for enterprise
architecture. Do you have any idea how long I have
been lobbying for this money? For this project? It is
going to save us millions! It is going to bring us into
the 21st Century. It is going to make us into a
knowledge business."
McCafferty just stared at him, shaking his head. Yes,
he knew how long the CIO had been struggling to get
http://www.brcommunity.com/b191.php (2 of 17) [3.2.2008 12:44:58]
Enough Systems (Part 7)
~ Contributing Value to
your ROI Calculation: Cost
Reductions
By James Taylor & Neil Raden
December 2007
Business Rules in User
Interfaces
By Kamlesh Pandey
December 2007
The Need for Smart
Enough Systems (Part 6):
The ROI for Enterprise
Decision Management
By James Taylor & Neil Raden
November 2007
An Investment in BRMS
Delivers Rapid ROI
By Thomas Cotic
November 2007
The Need for Smart
Enough Systems (Part 5):
Finding Hidden Decisions
By James Taylor & Neil Raden
October 2007
Business Rules Discovery
from Existing Applications
Dr. Vitaly Khusidman
October 2007
The Need for Smart
Enough Systems (Part 4)
Why Enterprise Architecture is an Oxymoron
the executive committee to undertake an enterprise
architecture project. He had even helped Alan research
the subject. Together, they had studied numerous EA
projects, gone to at least 7 EA conferences, listened to
scores of self-anointed EA gurus pontificate on the do's
and don'ts of enterprise architecting. McCafferty's
problem, though, was that while he had worked
alongside of Sverdlow in putting together the project
proposal, he had come to a different conclusion from
his friend.
By James Taylor & Neil Raden
September 2007
Business vs. System
Thinking in Rule Writing
By Kristen Seer
September 2007
The Need for Smart
Enough Systems (Part 3):
Enterprise Decision
Management
While Sverdlow had become enamored of EA (the seeds By James Taylor & Neil Raden
for his amorousness having been planted long ago
when as a fledgling IT chick he was besotted with IBM's
BSP --Business Systems Planning-- methodology),
McCafferty (whose roots were not in IT, but in strategic
planning and organizational transformation) had
become convinced that EA, as touted by IT folks in the
various mind-numbing conferences they had attended
together, was not only an impossible dream but a
dream that would inevitably turn out to be a nightmare
for them all.
It was not that McCafferty disbelieved in architecture,
per se. What he disbelieved was the fundamental
premise underlying the common IT vision of enterprise
architecture. To McCafferty, that vision has been
distorted by IT's system engineering mentality. At the
core of this mentality is a prism that resolves all
dimensions of the enterprise into systems and blindly
invokes traditional systems engineering (TSE) as its
solution strategy. It is this system prism and TSE that
lead IT inexorably to what McCafferty believes is the
dangerously erroneous conclusion -- that an enterprise
is basically a 'system of systems' (SoS).[1]
http://www.brcommunity.com/b191.php (3 of 17) [3.2.2008 12:44:58]
August 2007
Business Rules Bridge the
Gap (Gap Analysis, that is)
By Michael Oara
August 2007
The Need for Smart
Enough Systems (Part 2)
By James Taylor & Neil Raden
July 2007
The Need for Smart
Enough Systems (Part 1)
By James Taylor & Neil Raden
June 2007
Constructing a Business
Rules Process Is Like
Building a Delicious
Sandwich
By Kimberlea Thompson
May 2007
The Phased Approach to
Why Enterprise Architecture is an Oxymoron
"Now Michael," Sverdlow continued, "don't get all
pouty. This is a good thing. It is going to help us
prioritize our IT projects, improve our business
processes, manage our legacy transformation, and
improve our productivity. You heard all of those folks
at those conferences. And, Michael, what is most
important of all, we have top management support.
Bart [Calder, CEO] himself, told everyone this was a top
priority project. What do you think about that?"
"You know what I think," McCafferty responded. "How
many times have I said it? 'Enterprise Architecture is
an oxymoron.' Kept to a small scale, like individual
systems TSE and architecture can work fine. But, in my
humble opinion, TSE and architecture cannot scale up
to the enterprise level. Even Christopher Alexander,
the master architect who wrote The Timeless Way of
Building, says that often the attempt to gain total
design control of the environment makes things worse,
not better.[2] Of course, I understand -- and
sometimes share -- the compelling need you and the
rest of the executive team have to gain total design
control over the entire enterprise, but I firmly believe
we are going to fall into Alexander's trap. The
enterprise is not, I say again, Alan, NOT, a
deterministic system whose behavior can be
manipulated by direct actions. It is, instead, a complex
system, comprised of quasi-autonomous entities, acting
in their own best interests. Their behavior cannot be
architected in the traditional sense of systems
engineering. And, attempts to do so at the scale of the
enterprise are doomed to failure."
"Come on, McCafferty, you are the transformation guy.
You of all people should appreciate the role of
http://www.brcommunity.com/b191.php (4 of 17) [3.2.2008 12:44:58]
Mining Business Rules
By Mukundan Agaram
March 2007
Improving Decision Table
Rules with Data Mining
By Ian Graham
January 2007
Decisioning ~ A New
Approach to Systems
Development (Part 1)
By Mark Norton
December 2006
The Perfect Domain
By William Dinner
November 2006
A Brief History of the
Business Rule Approach,
2nd ed.
Compiled by the Editorial
Staff of BRCommunity.com
October 2006
Motivation at Zachman
Row 1
By Allan B. Kolber
September 2006
JSR-94 and the Case for
Business Rule Standards
By Hans Witt
August 2006
Moving from Zachman
Why Enterprise Architecture is an Oxymoron
architecture in enterprise transformation. I have heard
you talk on the subject. You have advocated that
modeling -- which is all that architecture really is -- is
the key to change management. Without modeling,
you cannot understand how the enterprise operates,
nor can you describe how you want it to operate,
setting the stage for the transformational road map you
are so proud of."
"Ah yes, you are very correct in your assessment of my
thinking about modeling. It is the sine qua non of
transformation ... has been since the days when the
only models we had were financial models. The
important things about financial models -- which seem
to have gotten lost in our present day systems
engineering modeling frenzy -- are that we could tell
when we had a good model, i.e., one that represents
our reality and enables us to think coherently about it,
and at the same time informs us as to what we can do
to change that reality and to measure our progress in
implementing changes.
"Due in large part to architecture, enterprise modeling
has gotten more and more sophisticated, and in some
ways, I think, we have gotten carried away with it.
What is the phrase: "ad absurdum? The problem is
that modeling has (in some cases -- architecture being
one of them) become an end in itself, rather than a
means to an end. We seem to model for modeling's
sake, not for any other purpose, and then we stand
back and admire our models, saying to anyone who will
listen, 'there, isn't that a beautiful architecture or
process or network or workflow' or whatever it was that
we were supposed to be modeling. We honestly expect
folks to stand there, slack jawed in amazement,
http://www.brcommunity.com/b191.php (5 of 17) [3.2.2008 12:44:58]
Row 2 to Zachman Row 3
~ Business Rules from an
SBVR and an xUML
Perspective (Part 3)
By Markus Schacher
July 2006
Moving from Zachman
Row 2 to Zachman Row 3
~ Business Rules from an
SBVR and an xUML
Perspective (Part 2)
By Markus Schacher
June 2006
Moving from Zachman
Row 2 to Zachman Row 3
~ Business Rules from an
SBVR and an xUML
Perspective (Part 1)
By Markus Schacher
April 2006
Business Rules in Practice
By Bonnie Moonchild
February 2006
Changing the Rules of
Testing ~ Testing
Strategies for the
Production Maintenance of
Rapidly Evolving Business
Rules Systems
By Pierre Berlandier
January 2006
The Role of Rule Analyst
Why Enterprise Architecture is an Oxymoron
shaking their heads in positive wonder like they were
staring out at the Grand Canyon for the first time.
Then, and here is the travesty of it all, we have the
audacity to believe that we can use these architecture
models to transform our reality, which is, in the case of
enterprise architecture, the entire enterprise.
"Did I adequately describe your enterprise architecture
project, Alan?"
"Come on, McCafferty," Sverdlow growled. "We have
got to do this architecture project. Corporate is all over
our butt. I can't get any of my projects approved
unless I can map them back to an enterprise
architecture. Our CRM project is held up behind this EA
project."
"I understand, Alan. But, that is a different problem.
Developing an EA to satisfy corporate's capital
budgeting process is a bit different than using the EA
for enterprise transformation, legacy migration, and so
on."
"I am not sure about that, Mike. Their view is that by
forcing us to develop an EA and using it to determine
our IT priorities, they are helping us to better manage
our organization. And, they will get the bonus of being
able to integrate our EA with everyone else's EA and
find opportunities for overall performance improvement
and cost management. I would do the same thing if I
were in their shoes."
(part 2)
By Kristen Seer
December 2005
Business Rules in
Requirements Analysis
By Ralph Nijpels
November 2005
The Role of Rule Analyst
(part 1)
By Kristen Seer
October 2005
Term-Fact Modeling, the
Key to Successful RuleBased Systems
By Oscar Chappel
September 2005
Negotiating Corners
By Mark Myers
August 2005
The 2005 Business Rules
Awareness Survey
Presented by Kristen Seer
July 2005
Keeping Business Rules
Separate from Their
Enforcement
By Oscar Chappel
May 2005
"And the plot thickens," quipped McCafferty. "The track The 'Other' Rules ~
we are headed down not only wants us to develop an
Internal Control and the
imaginary enterprise architecture, but now corporate is
http://www.brcommunity.com/b191.php (6 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
going to construct a global imaginary enterprise
architecture from the sum of the enterprise
architectures of the divisions. WOW. Modeling
Nirvana. And (I hesitate to ask but will do so anyway)
what makes them think, or, for that matter, what
makes us think, that these enterprise architectures will
be of sufficient quality to be -- what should I call it? -integratable? Again, TSE makes its mark. The
corporate mentality seems to be that corporate is a
'system of systems of systems' -- an SoSoS, if you will.
Does that make sense? Seems like a Tower of Babel to
me. In fact, I am sure that by the time they are done,
we will have been sold off to some other corporation
and will have to start all over again."
Influence of COSO
By Steven Chater
March 2005
Business Rule Reuse in
the Real World
By David Christiansen
February 2005
Enterprise Transformation
~ Lessons from Julius
Caesar
By Daniel S. Appleton
January 2005
A Brief History of the
Business Rule Approach
"Ok. Ok. I will bite. If enterprise architecture is not the Compiled By the Editorial
Staff of BRCommunity.com
answer, what is?"
"Don't get me wrong, Alan. I am not challenging the
idea of enterprise architecture per se. It is the
approach that I am concerned about. That approach is
based on the fundamental assumption that systems
engineering is the key to overall enterprise performance
improvement. My concern is that this mentality has
been surfing in on the information technology wave and
that this wave's energy exerts itself in the form of TSE.
I fundamentally do not believe that an enterprise is a
'system of systems' -- ergo, to me enterprise and
architecture are terms that, when placed together, form
an oxymoron.
December 2004
The Motorcycle Approach
to Enterprise Vocabulary
By Mark Myers
September 2004
Business Rules, Can They
Be Re-Used?
By Rik Gerrits
August 2004
Business Rules and the
Many Meanings of 'If…
Then…'
By Kirk D. Wilson
July 2004
A Metamodel for Business
"But, to answer your 'if you're so smart, McCafferty'
Vocabulary and Rules:
question, I need to redefine the idea of system. Sure,
Object-Oriented Meets
an enterprise can be viewed as a system ... but not as a Fact-Oriented
linear or deterministic system as TSE wants to view it.
By Donald E. Baisley
http://www.brcommunity.com/b191.php (7 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
Rather, an enterprise must be viewed as a non-linear
system of coupled, self-regulating constituents
interacting in a context sensitive manner. The behavior
of the overall system cannot be explained or obtained
or understood by summing the behaviors of its
constituent parts, nor can we control the behavior of
the whole by micro-managing the behavior its parts;
however, we can reduce the behavior of the whole to
the lawful behavior of its parts if we take the non-linear
interactions into account.[3]
"The key word in the above philippic is the word lawful.
I am willing to go along with an architecture of laws.
Not an architecture of design. As such, the architecture
of laws for the whole enterprise is intended to bound
and constrain behavior of the constituent parts."
Sverdlow could not contain himself and he started to
chuckle. "What is this, now, McCafferty? Do you want
us to build a lawchitecture instead of an architecture?
Or maybe a larchitecture?"
May 2004
The Notion Of The Perfect
Platform ~ And What It
Means For System Models
By Ronald G. Ross
April 2004
Why Enterprise
Architecture Is An
Oxymoron
By Dan Appleton
March 2004
Business Semantics Of
Business Rules
By John Hall
February 2004
Categories and Roles in
Business Vocabulary
By Donald E. Baisley
January 2004
ASL -- A Formal Language
For Specifying A Complete
Logical System Model
"Alan, your very crude attempt at degradation disguised (Zachman Row 3)
Including Business Rules
as humor actually makes my fundamental point here.
By David Bevington
One of the defining differences between deterministic
systems and social complex systems is that social
complex systems have a dimension of cognition. We
talked about this in another session when we discussed
the idea of the cognitive enterprise and the cognodigm.
[4] Enterprises are comprised of cognitive elements.
Those cognitive elements are described by symbols we
call 'words.' When you change a word -- as you have
by replacing architecture with larchitecture (or
whatever) -- you have begun to change the cognitive
structure of the system. And when two of the system's
http://www.brcommunity.com/b191.php (8 of 17) [3.2.2008 12:44:58]
December 2003
Verification Of Business
Rules Utilization
By Rick Gerrits
November 2003
Enterprise Rules Services
at Liberty Regional Agency
Markets
By David Christiansen
October 2003
Why Enterprise Architecture is an Oxymoron
constituents transact with that cognitive structure, the
behavior of the whole changes."
Business Rules, Platforms,
and Inferencing
By Kirk Wilson
"You know, Mike," said Susan [the COO] who had been
listening at the door. "I think you may have something
there. When we change words, or introduce new
words, we do have an impact on actions. I remember
when 'quality' became a big thing around here. Don't
get me wrong; we have always been careful about
quality, but when we introduced the idea of 'total
quality,' a la Deming, we changed our whole behavior
pattern. We developed a new language, a new set of
business rules, a new set of processes -- why we even
redefined job titles and job descriptions. We started
talking about six sigma and black belts and on and on.
You bet our behavior changed. No architecture there."
September 2003
The Business Rules Market
Resurrection Continues
By Jim Sinur
Ed Barlow, the CFO, had wandered in to McCafferty's
office, and now joined in. "I remember when we first
introduced the idea of 'standard cost' to this company.
You could hear the cries of agony late into the night
from the engineers. Standards scared them to death.
Standards, they said, constrained their creativity. And
standard costs had to be the worst form of standard
imaginable. Clearly, they were something born of the
devil. And the devil was me. I felt it mandatory that
we change from the idea of 'actual cost' as the primary
metric we used to manage cost structures. The ripple
effect of the language, standard costs, variances,
standard labor costs, standard material costs (and so
on) even changed the way the engineers were thinking
about what they were doing. It didn't just affect how
my cost group changed."
August 2003
The Rule Transformation
Approach To Business
Renovation
By Andrej Kovacic
July 2003
In His Own Words; A
Tribute to E.F. Codd
By E.F. Codd
June 2003
Working on a Project as a
Business Analyst
By Kristen Seer
March 2003
Cognodigms
By Dan Appleton
February 2003
Using Verification and
Validation Techniques for
High-quality Business
Rules
By Dr. Silvie Spreeuwenberg
January 2003
Eliciting Business Rules in
Workshops (part 2)
By Ellen Gottesdiener
December 2002
"It is my belief," said McCafferty, picking up again, "and Blueprint of an Enterprise
http://www.brcommunity.com/b191.php (9 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
this belief is increasingly supported by modern business
literature, that organizational transformation (and,
consequently, organizational performance) is driven by
a pragmatic six step process that begins in a place
entirely foreign to most IT professionals but entirely
comfortable to most other folks. Sorry Alan." Sverdlow
offered a small smile as McCafferty continued. "It
begins in a place called the metaphor, and it proceeds
through stages called analogy, models, rules,
processes, and, finally, performance.[5]
"What do you mean by metaphor and analogy?" asked
Susan. "Are you trying to give us a new language of
change?" The group seemed to nod their heads in
unison like they had all just been told a secret.
"Well, I think the metaphor is the ultimate cognitive
tool," said McCafferty. "By using metaphors we can
change the direction of thinking processes, we can start
new processes, we can stop undesirable processes. For
example, Susan, when we introduced the idea of
quality, we did so with the metaphor 'quality is our
business.' What this metaphor did was to get folks
thinking about quality as a job, not as a work biproduct. Then we introduced the notion of six sigma
and black belts. What are those, Susan?"
"Analogies," she responded brightly. "Six sigma is an
analogy for perfection. Black belt is an analogy for
someone who is really, really good at a specific skill. I
get it. By starting with the metaphor, we were able to
get folks to start thinking differently about quality. By
evolving to analogies we were able to move quickly in
the direction we wanted because people fundamentally
understood the analogies and were able use the
http://www.brcommunity.com/b191.php (10 of 17) [3.2.2008 12:44:58]
Nervous System
By Kamlesh Pandey
November 2002
Eliciting Business Rules in
Workshops (part 1)
By Ellen Gottesdiener
October 2002
Business Rules In Prolog
By Markus Schacher
September 2002
How to Develop Effective
Business Analysts (Part 3)
By Kristen Seer
August 2002
Profit From Events And
Patterns (Part 1)
By Alex Buckley
July 2002
How to Develop Effective
Business Analysts (Part 2)
By Kristen Seer
June 2002
Extended Business Object
Model
By Kamlesh Pandey
May 2002
How to Develop Effective
Business Analysts (Part 1)
By Kristen Seer
March 2002
The Black Box Problem
By Malcolm Chisholm
January 2002
Business Rules Are Meta
Data
Why Enterprise Architecture is an Oxymoron
knowledge they already had to shape quickly their
thinking and, then, their behavior.... We then
introduced models, rules, processes, and measures,
just like you said."
"Right," said McCafferty. "We did this without
consciously knowing we were doing it. That is why I
said normal folks -- sorry again, Alan -- are perfectly
comfortable starting with metaphors and analogies.
Now, just think what would happen if we were do
employ this process on purpose."
"What is your point, Mike?" asked Sverdlow. It was
clear his feelings were a bit damaged. "What does this
have to do with enterprise architecture?"
"What is different here is what I call the angle of
approach to change. Thanks in no small measure to
Frederick "Speedy" Taylor, the conventional angle of
approach or organizational change is the system or
process, coupled with TSE. However, the angle of
approach I firmly believe in is not through processes; it
is through the cognitive structure of the organization,
and the artifacts of that structure are words, laws, and
business rules. The only way this approach is
meaningful is if it is predicated on the notion that an
enterprise is a social complex system and not a 'system
of systems' (or a 'system of system of systems').
By Alan Perkins
December 2001
Constraints & Predicates:
A Brief Tutorial (Part 3)
By C.J. Date
November 2001
The Role Of Reference
Data In Business Rules
By Malcolm Chisholm
October 2001
Powered By Rules
By Barbara von Halle
September 2001
Constraints & Predicates:
A Brief Tutorial (Part 2)
By C.J. Date
August 2001
Business Rules are the
Key to CRM and One-toOne Personalization
By Rolando Hernandez
July 2001
Constraints & Predicates:
A Brief Tutorial (Part 1)
By C.J. Date
May 2001
Business Process Modeling
As A Starting Point For
Information Systems
Design (Part 3)
"If you think about the 6 stages of transformation I
listed, you notice the word 'rule.' Another word for 'law' By Jan L.G. Dietz & Paul J.M.
Mallens
is 'rule.' In this transformational evolution, it is Stage 4
that would constitute the larchitecture stage, and it is
April 2001
Templates For Capturing
the set of rules generated in that stage that would
Business Rules
comprise the larchitecture, itself. But, remember, this
http://www.brcommunity.com/b191.php (11 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
is an architecture of rules, not designs. These rules
focus on the cognitive structure of the enterprise and its
constituents, and let everything else fall into place from
there. "[6]
"Aha," said Sverdlow, "I see where you are headed.
You are headed toward business rules.[7] You have got
to be kidding. Are you saying that business rules are
the complex system's equivalent of architecture?"
"Close, but no cigar. What I am saying is that business
rules comprise the complex system's architecture -- or
larchitecture as you called it -- but there is more. To
avoid the problem we have today with architectures
being gallimaufries of models, there are rules that
govern the quality of the larchitecture; you could call
them metarules. Actually, I would go another step. I
would say that if these rules are not met -- no pun
intended -- the larchitecture would not exist at all,
much less would it be useful for its intended purpose -which is orchestration of the behavior of numerous (and
often temporary) self-regulating, enterprise
constituents."[8]
"And these metarules are ……?" Sverdlow challenged.
"There are six of them," said McCafferty. "The first
metarule says a rule comprises at least one subject
(with its descriptive attributes) one object (also with its
descriptive attributes) and a relationship between the
subject and object and their descriptive attributes; the
second says that every subject and object must
describe a set, even if there are no current instances of
that set, with attributes that uniquely distinguish all
instances of the set one from another; third, no rule
http://www.brcommunity.com/b191.php (12 of 17) [3.2.2008 12:44:58]
By Judi Reeder
March 2001
Business Process Modeling
As A Starting Point For
Information Systems
Design (Part 2)
By Jan L.G. Dietz & Paul J.M.
Mallens
January 2001
Business Process Modeling
As A Starting Point For
Information Systems
Design (Part 1)
By Jan L.G. Dietz & Paul J.M.
Mallens
December 2000
Business Rules Rule
Requirements
By Ellen Gottesdiener
October 2000
Modeling Business Rules
Using the UML and CASE
By Neville Haggerty
September 2000
Knowledge Management The Last Hurrah
By Warren L. Selkow
August 2000
Ten Ways To Improve
Data Resource Quality
By Michael H. Brackett
July 2000
Fact Orientation Before
Object-Orientation (Part
2): Capturing Constraints
With Object Role Modeling
Why Enterprise Architecture is an Oxymoron
stands alone; fourth, no rule can be inconsistent with
any other rule or set of rules within the same
larchitecture; fifth, all rules and their constituent parts
must be transformable in their syntax between and
among natural and machine languages -- and an
isomorphic graphical syntax would be a desired
additional feature; and finally, the larchitecture must be
extensible, which means we should be able to add rules
without violating any of the metarules."
"Hey, aren't you just talking about a big data model
here, McCafferty? And, isn't this larchitecture just an
ontology or a conceptual schema or a universe of
discourse or something like that? Boy, you really had
me fooled there for a while. I thought you were going
to tell me something I did not know or give me some
new insight. This sounds just like warmed over data
stuff. Yah, data will be a part of our architecture.
Corporate requires it. I think the contractor will build
us a data view, or a logical model (or whatever) and we
can map that to our databases and so on. Phew, I
thought we were really off on the wrong tangent here.
But, I guess not."
McCafferty smiled ruefully. "Alan, you are still mired in
the TSE mind set. Get out of it. My whole point is that
enterprises are not 'systems of systems'; they are
social complex systems. Furthermore, as social complex
systems the proper angle of attack for changing their
behavior is at their cognitive structure, not their
systems structure.
"But, I agree, this may not be your goal for spending
Bart's $1.5 million. Your goal may be to pass the
corporate bar for project approval, or it may be to set
http://www.brcommunity.com/b191.php (13 of 17) [3.2.2008 12:44:58]
By Dr. Terry Halpin
May 2000
Project Scope Document:
A "How To" (Part 2)
By Dave Wendelken and
Betty Hilbrant Baker
May 2000
Thin Processes
By Neal Fishman
April 2000
Project Scope Document:
A "How To" (Part 1)
By Dave Wendelken and
Betty Hilbrant Baker
March 2000
Y2K Post Mortem
By William G. Smith
February 2000
Business Rule Basics from
Kindergarten Tee-Ball
By Barbara von Halle
January 2000
Business Rule Practices In
The New Millennium
By Barbara von Halle
September 1999
Implementing Business
Rules With Inferencing
(Part 2): Implementing
Inferencing in Business
Rule Engines
By Kirk D. Wilson, Ph.D
July 1999
Implementing Business
Rules With Inferencing
Why Enterprise Architecture is an Oxymoron
up a portfolio management structure for the IT
executive committee. OK. But, do not fool yourself
into thinking that you are creating a 21st century
enterprise with that architecture or that you are going
to get anywhere near the performance capabilities you
are promising with your business cases. Why? For the
simple reason that enterprises are too complex to
submit themselves to the demands of traditional
systems engineering and the vision of architecture TSE
requires.
"Let's go get a cup of coffee and celebrate your victory."
References
[1] I borrowed the terms 'TSE' and 'SoS' from Douglas
Norman and Michael Kuras of MITRE Corporation.
[2] Christopher Alexander, The Timeless Way of
Building.
[3] Alex and Davd Bennet, Organizational Survival in
the New World, p 29.
[4] Dan Appleton, "Cognodigms," Business Rules
Journal, Vol. 4, No. 3, (March 2003), URL: >http://
www.BRCommunity.com/a2003/b146.html.
[5] Ikujiro Nonaka, The Knowledge Creating Company,
Harvard Business Review.
[6] As an aside, the phrase "falls into place from there"
http://www.brcommunity.com/b191.php (14 of 17) [3.2.2008 12:44:58]
(Part 1): The Importance
Of Inferencing
By Kirk D. Wilson, Ph.D
April 1999
Exploring Business Rules
By Ronald G. Ross
May 1998
Policy Charter As A
Deliverable
By Gladys S.W. Lam
Why Enterprise Architecture is an Oxymoron
implies an heuristic approach to change, not a stepwise
approach as is inherent in TSE. Heuristics and
probabilities of outcomes are integral to enterprise
engineering, and foreign to TSE. More on this in another
McCafferty Chronicle, Enterprise Engineering.
[7] Dan Appleton, Business Rules the Missing Link,
Datamation, April 1984.
[8] In his book, The Heart of Enterprise, Stafford Beer
describes a viable enterprise as an enterprise capable of
surviving on its own.
standard citation for this article:
Dan Appleton, "Why Enterprise Architecture is an
Oxymoron," Business Rules Journal, Vol. 5, No. 4
(April 2004), URL: http://www.BRCommunity.com/
a2004/b191.html
about . . .
DAN APPLETON
http://www.brcommunity.com/b191.php (15 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
Daniel S. Appleton has long been a respected
consultant and thought leader in the field of
business engineering. He has over 35 years of
management and consulting experience in both
the commercial and government environments,
and he has held line positions as Director of
Strategic Planning, CIO, and CEO. In 1984, in a
series of Datamation articles (including his oftenreferenced article, "Business Rules, the Missing Link"), Dan set
forth the concept of 'business rules,' portraying them as the
primary bridge between IT and the user community, and the
primary determinant of organizational behavior in an
information age enterprise.
Dan's essential skills lay in his ability to construct and
subsequently to implement business models that work and
that create value. He has received numerous honors and
awards for his leading edge thinking. Dan is a graduate of the
University of California at Berkeley and has an MBA from
American University. He can be contacted via the DACOM web
site: www.dacom.com. For more information on the
"McCafferty Chronicles" visit www.dacom.com/McCafferty
[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ] [ Technical Support ]
http://www.brcommunity.com/b191.php (16 of 17) [3.2.2008 12:44:58]
Why Enterprise Architecture is an Oxymoron
http://www.brcommunity.com/b191.php (17 of 17) [3.2.2008 12:44:58]