Architecture Is Architecture
Wednesday, May 6, 2009, 9:00 am
Introduced by Rolf Siegers of Raytheon. Siegers introduces Zachman Framework as a thinking tool for enterprise architecture.
Zachman’s talk was titled “Enterprise Design Objectives: Complexity and Change.” He spoke passionately about architecture and the Zachman Framework at a breathlessly frenetic pace, using physical transparencies as visual aids.
Object of enterprise architecture is to make enterprise run better and faster. The context of the enterprise today is that complexity and change drive issues of architecture.
Enterprise architecture is grossly misunderstood. It’s not an IT issue, it’s an enterprise issue. It’s perceived as an IT issue because
- awareness tends to surface through the IT community. IT raises the issue, but it’s not an IT issue.
- IT people have skills to do enterprise architecture if any enterprise architecture is being done.
Enterprise needs IT people in the information age. But EA (enterprise architecture) has nothing to do with building and running systems. Anybody can do that.
References IT Doesn’t Matter, by Nicholas Carr, originally in Harvard Business Review. “He’s right. So why does the enterprise need IT people? It has to do with engineering the enterprise.” We (IT people) bring drafting skills to engineer the enterprise so it works better.
Everyone needs to be reading off the same page. Enterprises are more complex than Boeing 747s. The ability to describe things and build models–that’s what IT provides. It took 25 to 30 years of experience to engineer a 747, and enterprises are more complex than 747s. We bring the drafting skills to do enterprise engineering that needs to be done.
EA has origins in Frederich Taylor (1911), Shewhart, Drucker, Forrester, Senge, Helfer, Anthony, Bluumenthal, Toffler, Steiner. A lot of work has gone on since Taylor. Kuhn, Structure of Scientific Revolutions: Invention is a function of time, not of personality. There is no need to start with a blank sheet of paper. A lot of work has already been done.
Two implications of “enterprise”:
- Scope – The enterprise in its entirety. The whole thing. You can’t start with the pieces.
- Content – Has nothing to do with the enterprise’s systems or its IT. The objective is to engineer and manufacture the ENTERPRISE, NOT simply to build and run systems.
“ENTERPRISE ACTUALLY MEANS ENTERPRISE.”
[Displays a photo of the Roman Coliseum.] Some people think this is architecture. People misconstrue architecture as being big, monolithic, etc. The Coliseum is the RESULT of architecture. The result is an implementation, an instance. The architecture is the set of representations relevant for describing a complex object such that an instance of the object can be created and such that descriptive representations serve as the baseline for changing an object instance.
If what you’re trying to create is simple, you don’t need an architecture. If it’s complex, you do. Reasons you need architecture: complexity and change.
Complexity: If you can’t describe it, you can’t create it (whatever “it” is). If you don’t retain descriptive representations, you have three options:
- Change the instance and see what happens (high risk)
- Recreate (reverse engineer) the architecture representations from existing implementation (takes time, costs money)
- Scrap the whole thing and start over again
There’s not a single descriptive representation for a complex object. One dimension typically includes “abstractions” – what (building materials), how (functional specs), where (drawings), who (operating instructions), when (timing diagrams), why (design objectives). These are the abstractions that enable the engineering of complexity.
Another dimension typically includes perspectives:
- scoping boundaries (strategists perspective)
- requirements concepts (owner perspective)
- design logic (designers perspective)
- plan physics (builders perspective)
- part configurations (implementers perspective)
- product instances (operators perspective)
As soon as you start looking at more than one thing at one time, things become unmanageably complicated. You have to look at one thing at a time. The reason to do engineering is to manage complexity by making things as simple as possible. But for implementation, you need the composite of all these things. Engineering needs primitives–single-variable models. Programming is manufacturing, not engineering (Frederick Brooks).
Problem today is that we’ve been manufacturing before the enterprise has been engineered.
Dewey wrote about business-systems planning in late 1960s: How to articulate the strategy of the enterprise. Architecture has to do with getting the implementation aligned with strategy.
To understand enterprise architecture, we looked at architectures for buildings, airplane manufacturing, etc. Sought to understand what architecture is and looked for patterns. Began to see the pattern. Put enterprise names on descriptions of other domains.
Architecture for anything is the total set of descriptive representations relevant for describing a complex object such that it can be created and that constitute a baseline for changing the object once it has been instantiated. So enterprise architecture is the set of models relevant for describing an enterprise–abstractions and perspectives.
If you build a system based on an organization and you want to change the organization, the system will be affected. Dewey said to define processes independently of organization. This is the principle of separation of independent variables, which is what gives flexibility. Engineering for flexibility = separation of independent variables.
The Zachman Framework is an ontology, not an implementation. We learned about architecture for enterprises by looking at architecture for airplanes, buildings, locomotives, computers: complex industrial products. “I simply put enterprise names on the same descriptive representations relevant for describing anything. ARCHITECTURE IS ARCHITECTURE IS ARCHITECTURE. Why would anyone think that descriptions of an enterprise are going to be any different from descriptions of anything else humanity has ever described? I didn’t invent Zachman’s Framework. I just accepted definitions of architecture that were already established in other disciplines.”
Zachman Framework schema is an ontology, a theory of existence of a structured set of essential components of an object for which explicit expression is necessary for design, operating, and changing the object. NOT a methodology for creating an implementation of the object. It’s an ontology, a structure, a theory of existence, not a methodology.
To close, Zachman displayed a list of problems identified at IBM in 1965 with systems (development took too long, projects were systems were over budget, systems were incomprehensible, etc.), then he displayed the identical list with a different heading, “2009 System Problems,” followed by a long list of technologies and buzzwords from the past 40+ years–technologies that haven’t fixed the problems.
Punchline: “IT MAKES ONE WONDER IF THERE ACTUALLY IS A TECHNICAL SOLUTION TO ALL OF THOSE PROBLEMS.”
He closed by quoting Indira Gandhi: “My grandfather once told me that there were two kinds of people: those who do the work and those who take the credit. He told me to try to be in the first group; there was much less competition.”
A comment from an audience member at the close of the talk led Zachman to consider his remarks in the context of today’s economic situation. Architecture is an asset, he said, and implementation is an expense. We have a culture that optimizes for the short term. We’re paying the price today. “You can eat your lunch at breakfast time, but lunch is going to come.” Enterprise architecture separates the players from the non-players.
Bill Pollak – SEI