Who's On First?

I was sitting in a meeting recently and found myself thinking of the Who's on First Vaudeville comedy routing made famous by Abbott and Costello back in the 1930s. Compare these two conversations -

• Costello: "And you don't know the fellows' names."
• Abbott: "Well I should."
• Costello: "Well then who's on first?"
• Abbott: "Yes."
• Costello: "I mean the fellow's name."
• Abbott: "Who."
• Costello: "The guy on first..."
• Abbott: Who.
• Costello: The first baseman.
• Abbott: Who.
• Costello: The guy playing...
• Abbott: Who is on first!

Compared with:

• Enterprise Architect: "We need an Enterprise Roadmap"
• Executive: "We have a roadmap"
• Enterprise Architect: "But it's not an Enterprise Roadmap"
• Executive: "What's an Enterprise Roadmap?"
• Enterprise Architect: "It's a roadmap with an enterprise scope"
• Executive: "The roadmap we have considers the Enterprise"
• Enterprise Architect: "But it's just all of our portfolio roadmaps lumped together"
• Executive: "But isn't it produced by Enterprise Architects?"

While the conversation on the right is admittedly made up and facetious, more elaborate versions of it go on everyday in many IT shops. We are having a communication issue that comes from a lack of shared meaning. Costello assumes Abbott understands the interrogatives used are the player's names. Abbott clearly does not. When we use words to describe what Enterprise Architecture (EA) is and what we do, are we being understood?
Here are examples of terms we use every day in Enterprise Architecture and how non-architects might interpret our language:

• Term: Enterprise - EAs mean: The entire business; People Hear: Really large scale and complicated technology.
• Term: Future State - EAs mean: A holistic model describing where the organization wants to be in the future; People Hear: a pretty picture of a new enterprise application.
• Term: Pattern - EAs mean: An abstract generalization to a commonly recurring problem. People Hear: Detailed instructions on how to solve exactly the problem they have.
• Term: Abstract Generalization - EAs mean: an general solution that applies to many situations; People Hear: αφηρημένη γενίκευση (yeah, its Greek)

The point is - we use our own lingo, but without shared meaning, we miscommunicate, do not deliver value and ultimately become irrelevant. For a soap-box sermon on this topic, please click over to Dinosaurs Are Extinct for a Reason on my personal blog - practicingea.blogspot.com.


The things that make us good at EA often make us bad at communicating what we do. We reason and speak in the abstract; we are systems thinkers; we consider the long-term, big picture; we are not concerned with next week, but do care about the next year or five years. In short, we are using interrogative pronouns as formal nouns and our colleagues often don't quite know what we mean.


Even the term Enterprise Architecture is a source of confusion and the subject of raging debate within the inner circles of our profession - but that won't stop me from offering a noun form definition:


Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner.
At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to gain competitive advantage (substitute ‘complete mission' for NFP and government organizations).
I end my first post with a few points about this definition and some suggestions regarding what we do about it, i.e. the so what? My definition suggests -

• Architecture is about digesting a complex system and figuring out what to do.
• Architecture becomes Enterprise when we start thinking about the entire business as a system and not just a software application.
• The primary deliverable of any Enterprise Architecture team should be a future state description, just enough current state and an Enterprise Roadmap to get from here to there.
• These deliverables are governance tools that allow organizations to match investment to strategy. Since our customers are not other architects, EAs must deliver these tools in a language understood by the business.

Assuming you agree with me up to this point, what do we do about all of this? Here a few ideas:

• Establish alignment between senior business and IT executives about what EA is, and what value is expected. If EAs are delivering elaborate software design models rather than simple decision aids to help executives, the true value of EA is being missed.
• Consider the reporting structure of EA if you have an EA team. Do they report to the head of technology infrastructure? (danger, Will Robinson), the CTO (better), the CIO (good), the CEO or Chief Strategy Officer (best).
• Closely consider the EA team. Gartner calls out a common pitfalls of EA as having the wrong Lead Architect. The entire composition of the EA team must be evaluated. Have most EAs risen from the ranks of software development and infrastructure technology, or does the EA team have a balance of business and technology people?
• Focus on the few key deliverables the EA team could produce that would have immediate impact to the business in realizing strategy. Make them simple, write them in business language, and include people, process and technology.

Do these and your answer to the question, "Who's on first?" is not "Yes".