Master Foo defines Enterprise Architecture

by Sean McGrath

September 5, 2007 —

It was dusk - Master Foo's favorite time of day for contemplating the fundamental impermanence of the 1s and 0s of his CD collection. A timid knock on his door signaled the arrival of a visitor. The tired knock of someone exhausted by the travails of a hot trek up Pentimenti Mountain.

"Master Foo. My name is Mr. Klein. In my new job I have responsibility for creating an enterprise wide architecture for a company down in the valley. I seek your advice on the choice of a topology for this architecture."

"You are welcome on Pentimenti Mountain Mr. Klein.", said Master Foo pouring green tea for himself and his visitor. He placed a pad of watercolor paper on his lap and with the aid of a fine sable brush, proceeded to create intricate Sona patterns for use as wall decorations in the server room. "Please sit and tell me more about your architecture while I paint. It helps me to concentrate."

Mr Klein sat down and took a sip of his tea while gathering his thoughts. "My primary options as I see them are hub and spoke and message bus architectures. Both will work but I have been reading about SOAs and I think that..."

Master Foo raised his brush in the air to signal to Mr Klein to stop talking. "What. What is it?", he asked.

Master Foo replied: "That has essentially nothing to do with enterprise architecture Mr Klein. What you speak of is wiring not architecture."

Mr Klein slumped somewhat in his seat and stared into his green tea. "But everything I read and everyone I talk to start out by drawing pictures about how distinct parts are connected together!"

"Indeed," replied Master Foo. "The problem here is not that those drawing the pictures do not understand the true nature of enterprise architecture - although I know of some notable exceptions. No. The problem is more to do with the limitations on the available forms of expression."

Mr Klein sank further into his seat, ruing his decision to make the trip up Pentimenti Mountain without first reading the copy of "Semiotics For Beginners" that a Master Foo acolyte had urged him to read.

"Tell me Mr. Klein, what is an enterprise architecture for? What is it, in and of itself. What is its value proposition?"

"Well, lets see...", Mr Klein began. "We have all these computer systems that need to be made to work together somehow. They all need to talk so we need to hook them up somehow."

"Ok. But why do they need to talk? What value is there in getting them to talk?"

"Well. We currently manually type information from one system into another to get things done. If we hooked all the systems together we would obviate the need for that re-keying."

"Indeed you would. Assume for a moment that your systems are hooked together in that fashion, would you then have an enterprise architecture?", asked Mr Foo.

Mr Klein, sensing where the conversation was going, took a deep breath. "I presume the answer to that is 'no' Master Foo but I confess I do not know why."

"The answer is indeed 'no' Mr Klein."

Master Foo laid aside his drawing, washed his brush in a glass of water and placed it standing upright in a second glass. A droplet of water formed on the brush. Master Foo had watched the droplet form and now waited for it to fall down the stem of the brush. Staring at it intently. Awaiting its falling like some sort of cosmic permission signal to proceed.

"Interconnecting systems in that fashion can be useful in that it alleviates the need for manual intervention in inter-system communication Mr Klein. However, this is merely a wiring problem. Namely, how to effectively transfer information from A to B. Any number of network topologies can be used here but the result will simply be a more efficient inter-connection of existing systems - not an architecture for how the systems currently inter-connect or should inter-connect."

Mr. Klein gave Master Foo that universal look which says "Please, please give me an example!"

Master Foo continued. "Imagine that information about suppliers is stored in multiple computer systems. Inter-connecting these systems can address the question of how to share supplier information amongst systems but it does not address the enterprise architecture questions. These enterprise architecture questions relate to the multiplicity of supplier information repositories - not the effectiveness of their inter-connectivity. Am I making sense here Mr. Klein?"

"Ah!", Mr Klein blurted. For the first time in his encounter with Master Foo he was feeling comfortable. "I see what you are saying I think. As it happens we do have multiple supplier repositories in my company. Keeping them synchronized is a real headache."

"Yes. The enterprise architecture questions here relate to the relationships between those supplier repositories not the quality of the wiring between them. For example, are they disjoint, congruent or overlapping? If they are congruent, how are they synchronized? If overlapping how are the overlapping areas related? And so on."

"Yes, yes and what happens when a lookup for a supplier fails in system A? Should System B be tried? Can we have a single supplier repository? Can we make the two repositories behave as one from the point of view of all the other systems? That sort of thing."

"Exactly," said Master Foo. "All leading to the real goal of enterprise architecture which is to probe the nature of the component parts. To analyze their inter-relationships. To identify and control gaps and overlaps between processes and data. To plan a road ahead that consolidates and harmonizes while providing continuity. To plan for the inevitability of future change. That is enterprise architecture. The rest is just wiring."

The faint smile that had started to cross Mr. Klein's face faded into the pained expression of someone not clear on what they should do next.

"You brought presentation slides and Visio's to show me Mr Klein?"

"Yes Master Foo, but now I feel that I need to revisit them. But..."

"But you are not sure how to visually capture what we talked about?", asked Master Foo.

"Yes."

"That is the nature of enterprise architecture, Mr. Klein. Only the uninitiated think it can be represented on a simple wiring diagram. True enterprise architecture is a state of mind. It cannot be reduced easily to words or pictures. Therein lies its power and its mystery."

"So how can I proceed?"

"Words and diagrams are all we have to work with. Mr. Klein. We need to live within their limitations. Seek not a single diagram to capture your enterprise architecture. Seek not a single sound bite. It is a hyper-dimensional thing you are grappling with. All you can do is capture fleeting glimpses of it with words and 2 dimensional views. Do not start with the wiring diagram. Mr. Klein. End with that as the least important view of your enterprise architecture. One view amongst many and a not-very-important view at that."

And with that, Mister Klein took his leave of Master Foo, his head swimming in images of what Enterprise Architecture is not. Hoping against hope that knowing that would help him zoom in on what it actually is by the time he reaches the valley below.

ITworld.com