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 21^st 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 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. 

While Sverdlow had become enamored of EA (the seeds 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]

"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 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, 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."

"And the plot thickens," quipped McCafferty.  "The track we are headed down not only wants us to develop an imaginary enterprise architecture, but now corporate is 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."

"Ok. Ok.  I will bite.  If enterprise architecture is not the 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.

"But, to answer your 'if you're so smart, McCafferty' question, I need to redefine the idea of system.  Sure, an enterprise can be viewed as a system ... but not as a linear or deterministic system as TSE wants to view it.  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?"

"Alan, your very crude attempt at degradation disguised as humor actually makes my fundamental point here.  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 constituents transact with that cognitive structure, the behavior of the whole changes."

"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."

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."

"It is my belief," said McCafferty, picking up again, "and 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 bi-product.  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 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').

"If you think about the 6 stages of transformation I listed, you notice the word 'rule.'  Another word for 'law' is 'rule.'  In this transformational evolution, it is Stage 4 that would constitute the larchitecture stage, and it is the set of rules generated in that stage that would comprise the larchitecture, itself.  But, remember, this 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 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 up a portfolio management structure for the IT executive committee.  OK.  But, do not fool yourself into thinking that you are creating a 21^st 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" 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.  

# # #