What IS can and should learn from traditional architecture

Architecting in a Virtual World

Not too many years ago, my son stared inquisitively at the fax machine in my home office. "What does it do?" he asked. I gave him what I thought was an accurate explanation--namely, that the fax machine sends documents to another location. "Let me see," he begged. So I placed a memo in the fax machine and sent it on its way.

He became quite perplexed and said it didn't work. After all, the paper was still there; it had simply emerged from another part of the machine. I explained that the machine sends only the content--the words and diagrams--not the paper. But he remained unconvinced: "It still didn't work. The words are still on the paper."

To most of us, the fax machine is ancient technology. The idea that a machine can send thoughts, expressed on paper or in an electronic file, is second nature to us. We communicate ideas and reach consensus with people around the globe via e-mail. More and more, we are living in a virtual world. Executable logic sits on various servers, kicking into action at our command.

The role of the architect takes on new importance in this complex and rapidly changing environment. Years ago, to understand this role more clearly, I contrasted issues facing the enterprise and IS architect with those of the traditional architect. Because of the many changes we've seen since I last broached the comparison, readers have requested that I revisit these issues and provide some updated guidance. This month, then, I address a number of questions--some old, some new--about enterprise and IS architecture.

What is the difference between architecture and design? Jim Sinur of Gartner Group Inc. provided insight into this question at the June 1996 ZIFA Annual Forum. (ZIFA stands for Zachman Institute for Framework Advancement.) He said that if you can implement a drawing in more than one way, you have architecture. If you can implement a drawing in only one way, then the drawing contains exact specifications for instantiation, and you have design.

In traditional architecture, what is the role of the architect versus that of the engineer? The owner or owner's agent commissions the traditional architect for a project. The architect's responsibility is to design the structure, oversee contract negotiations, contain costs, and approve the final product. The architect prescribes the use of customized parts where architectural uniqueness is desired or required and guides the usage of reusable parts, sometimes in creative ways, leveraging the existence of proven parts. For example, in our house, we have diamond-shaped windows, an idea suggested by the architect for unique style. These are, of course, standard square windows, turned on their sides for added flair and creative appeal.

The engineer's role is to support the architect in technical areas for which the architect lacks skills. I was surprised to learn that it is truly not the engineer's role to undermine the architect's credibility! Rather, the engineer's job is to support the architect's design through appropriate technical solutions and suggest better alternatives in line with the architect's vision.

Because some architects are more technical than others, each architect determines his or her own need for engineers. The decision to partner with engineers depends on the target project's size and complexity and on the shortcomings of the architect's own skills in the required technical areas.

How do these roles compare to similar ones in enterprise and IS architecture? In the IS industry, we also have architects and engineers. As in traditional architecture, we probably recognized the need for engineers long before we suspected the need for architects.

In the IS industry, the architect's role is to supply a strategic vision and take on responsibility for the integration of major IS solutions. The engineer's role is to craft technology-specific solutions for an architect's vision.

Unfortunately, all too often, architects and engineers do not work as well together in our industry as they do in traditional architecture and engineering. Engineers might ignore architectural plans, or architects might not be sufficiently skilled to devise practical plans. We can learn the following lessons from our counterparts in traditional architecture:

We should interface directly with the client to coordinate the design and delivery of the final product.
We should aid engineers and builders in using reusable parts.
It would serve us well to estimate the costs for building our designs and find ways to share those costs across the enterprise for common constructs.
We should strengthen our architects' technical backgrounds.

In traditional architecture, why does law require architectural plans for certain kinds of structures? After studying existing structures, experts concluded that structures built without an architect were narrowly focused in their design, poorly integrated with their environment, and inflexible for supporting changing needs over time.

In enterprise and IS architecture, what kinds of structures require an architect's approval? To answer this question, let's consider the following ideas:

In enterprise and IS architecture, we need criteria to determine which electronic structures require architects, which ones require only engineers, and which ones builders can construct without engineers or architects.
To enable such decisions, our architects must deliver a blueprint of the major cornerstones in enterprise and IS architecture. These pieces need not be extremely detailed but must be selected based on their influence on business objectives and their ability to integrate the enterprise. These pieces would be reusable or shareable across organizational boundaries.
Our architects can manage a hierarchy of architectural deliverables. At the top of the hierarchy are architectural components common to the enterprise's industry. At the next level are components specific to but shared across the target enterprise. Below this level may be organization-specific and, eventually, application-specific pieces. Each architectural piece inherits its nature from those above it in the hierarchy. An architect can promote pieces up the hierarchy as appropriate to leverage reuse and sharing.

In traditional architecture, why do people and organizations hire an architect for projects that do not legally require one? We all know that architects cost money, take time (which may slow down the delivery), and deliver not the final product but merely a rendition of it. Yet an architect's vision will minimize mistakes. Some mistakes are fixable but only at great cost; others are too costly ever to fix. Moreover, an architect aims to maximize the owner's dollar investment in designing the desired finished product.

Why would an organization hire an enterprise or IS architect? In the IS world, architects also cost money, take time that delays projects, and deliver only a rendition of the final product. But the vision of enterprise and IS architects can also prevent costly mistakes.

Our architects should follow the lead of traditional architects in the following ways:

Become more cost-conscious in producing deliverables.
Find ways to advertise the costs their services save the enterprise.
Track the cost of changes in system components over time to learn and advertise the value of architect contributions.

In traditional architecture, do engineers ever disagree with an architect's drawings? If so, how are these differences resolved? No one except the architect can change the design as depicted by the architect or the product as seen by the owner. If an engineer finds a structural stability problem in the architecture, the engineer brings it to the architect's attention. After conferring with the engineer, the architect may elect to change the plans.

Do such disagreements occur in enterprise and IS architecture? If so, how are they resolved? Sadly, it's not uncommon for our architects and engineers to disagree strongly over deliverables. Each organization should heed the following guidelines borrowed from traditional architecture:

Develop architectural principles to which all architecture, design, and construction deliverables must adhere.
Develop procedures, such as design reviews and walk-throughs, by which trade professionals (architects, engineers, and builders) review architectural and engineering deliverables.
Document all design decisions, compromises, costs, and benefits, and track their implications to learn for the future.

In traditional architecture, how far does the architect's jurisdiction go? In traditional architecture, the architect has final jurisdiction over the final product prior to its approval by legal officials and final acceptance by the owner. In fact, in legal arbitrations, engineers and builders have no legal defense if their work deviates from the architect's plans.

How does a traditional architect's jurisdiction compare with the jurisdiction of enterprise or IS architects? An architect's jurisdiction certainly varies from one organization to the next. Consider the following ideas:

Each organization should establish an architectural group, comprised of architects and engineers, to set approval policy and procedures.
Each organization must decide which pieces of architecture require an architect's approval.
Perhaps an architectural group should actively pursue prototype testing as part of the architectural approval process.

What kind of training and certification does a traditional architect need? To become certified, a traditional architect completes a five-year college degree program, followed by a prespecified period of practical experience and a standardized certification test. Architectural curriculums include instruction on interfacing with clients as well as an overview--in no great depth--of the engineering discipline.

The more complex the target structure, the greater the likelihood of needing more (and variously specialized) architects. A number of white papers and courses deal with aspects of architectural planning. In fact, there's a certification process for architectural planning, which gives architects the skills to manage larger, more complex projects.

What training and certification do we expect of and provide for enterprise and IS architects? Like traditional architects, enterprise and IS architects are responsible for very complex products, which are becoming increasingly complex with time. But the structures we must deliver are far less tangible and more virtual than the structures traditional architects produce. Also, our technology is changing more rapidly than most other technologies. It is therefore more important than ever that we empower our architects and engineers with the knowledge, skills, and respect required to do their job. Taking a lead from our traditional counterparts, consider a program as follows:

Establish a cross-architectural team to address all important aspects of architecture. Include high-level visionary architects, more technical architects, and engineers.
Select an architectural framework around which to define, manage, and produce architectural deliverables and their reuse. Many organizations adopt John Zachman's Framework for Enterprise Architecture. At the ZIFA conference, Sinur stated that organizations use chart-of-accounts to keep inventory of our enterprise money. Likewise, the Zachman Framework is a chart-of-accounts for keeping track of our architectural deliverables.
Divide the framework into an appropriate set of architectural domains. I have worked with organizations that divide architectural jurisdiction along Zachman rows. For such organizations, one group of people produces row 2 deliverables (the business perspective) and integrates them with related deliverables from other rows and columns. Another group produces row 3 deliverables (the IS perspective). Subhash Chowdary, president of Virtual Integration Technology and also a speaker at the ZIFA conference, defined yet another means of dividing enterprise architecture. He separates it into the following four architectural domains:

1. Business architecture: defines the business in the absence of computers
2. Systems architecture: describes how you use existing systems to support the business
3. Technological architecture: prescribes how you build, purchase, and integrate systems

4. Product architecture: prescribes products purchased for systems use.

For each architectural domain, define a mission tied to the enterprise mission. Support the mission with policies, principles for each policy, strategies for each principle, organizational infrastructure committed to the strategy, and standards for enforcing and implementing the strategy. Behind each strategy, create procedures, tools, accessibility, and guidelines for integrating the architecture with other relevant architectures.
Regardless of how you carve up your architecture, create job-skill matrices for each architectural piece, depicting knowledge, skill, and practical experience required by the architect who will deliver that piece. From here, you can train and strengthen architectural skills.

Are there quick and dirty construction projects in traditional architecture? Even traditional architecture today has its quick and dirty projects (reflecting the pressure of deadlines). To be successful, such a project must be based on a solid vision, and development must proceed logically. For example, with most such projects, it doesn't make sense to build the third floor before the basement. Even when such projects are successful, the track record shows that they are more costly (due to post-construction changes) than projects that have architectural plans prior to building. It is extremely costly to move a kitchen from one floor to another, for example, or to accommodate for handicapped access later. Because of frequent cost overruns, quick and dirty projects are also more vulnerable to legal battles.

How do these quick and dirty projects compare to those in enterprise and IS architecture? Unfortunately, such projects are the rule rather than the exception in enterprise and IS architecture. The lesson we can learn here has already been stated. As architects, we need to set a foundation for defining the stable architectural pieces around which the enterprise can grow and foster change and for delivering them in proper sequence.

How do architects and engineers feel about retrofitting old structures to meet evolving requirements? In traditional architecture, some old structures have historical or unique architectural value. They are museum pieces--worthy of preservation for educational and enjoyment purposes. However, if built without architecture in mind, most old structures are not worth the investment of long-term maintenance because they are unlikely to provide long-term practical use.

How do we deal with such structures in enterprise and IS architecture? In enterprise and IS architecture we also have old structures with historical and perhaps architectural value. We may do well to put them in museums, but they are currently running our business operations! Traditional architecture teaches us the following lessons:

We must define the critical architecture for tomorrow.
We must also deliver a migration plan for today.

In traditional architecture, does the architect have a respected role? If so, why? In the U.S., traditional architecture is a respected profession. One reason for this respect may be that the traditional architect, as the first and most direct contact point for clients, defends client requirements from all other professionals involved. Another source of respect may be the ordinances that require architect stamps for certain types of construction, giving the architect a certain level of publicly recognized sophistication and merit.

Engineers are respected for different reasons, mostly related to their technical expertise.

How do we similarly legitimize the role of the enterprise and IS architect? This question may be the most difficult one facing our architects today. Consider the following three-point strategy:
1. Define our role and skill sets in very tangible terms, linked to technological solutions and integration.
2. Find ways to evaluate our contributions to systems-development projects, advertise our benefits, and communicate failures caused by poor architectural planning.
3. Be practical, not perfect. See Table 1 for common myths often encountered when using the Zachman Framework for delivering architecture. These myths can result in suboptimal priorities and dilute an architect's productivity and credibility.

When considering the state of enterprise and IS architecture, we shouldn't forget that the world of traditional architecture has its enigmas, too. For example, Florence, Italy, has an incredibly beautiful marble cathedral, whose original plans called for a dome larger than any in existence at that time. Unfortunately, the architects did not know how to design such a dome. Surprisingly, construction began prior to the development of a viable solution for supporting the dome. I was amazed that such an expensive construction project could begin without a sound design in place. (But, then, looking at our field of enterprise and IS architecture, why should this lack of proper planning surprise me?)

In the end, the cathedral was built with two domes: an inner one and an outer one. The inner dome is small enough that the techniques of the time could support it; and it, in turn, supports the outer one. I can't resist retelling one of the more creative architectural solutions that was considered: One architect suggested filling the space below the dome with dirt. The dirt would support the dome during construction and could be removed after completion. The obvious challenge was how to remove the dirt. The answer was not a technical but a human one--bury coins in the dirt!

Architecture is truly a marriage of engineering principles, vision, and creative artistic expression. Enterprise and IS architects have a significant impact on the future of our enterprises. We need to formalize our roles and create legitimacy for what we do.

Barbara von Halle is a consultant, journalist, and recipient of the 1996 DAMA International Individual Achievement Award. She is coauthor of The Handbook of Relational Database Design (Addison-Wesley, 1989). She can be reached at bvonhalle@kpiusa.com.

TABLE 1.Common myths about the use of the Zachman Framework for architecture.
Myth 1. You must deliver components for every cell.	Truth 1. You should select only those cells whose deliverables will assist in achieving specific business goals and in integrating the enterprise. Every cell costs money to deliver and manage.
Myth 2. As you define deliverables down the Zachman rows, you add more detail. Thus, row 2, called business model, is a conceptual model and row 3, called information systems model, is a more detailed model.	Truth 2. As you go down the Zachman rows, the deliverables represent the same constructs as in the previous row, but from a different perspective. You may therefore add components to a row that represents items of interest for that perspective, but you are not necessarily adding more detail to the constructs represented in other rows.
Myth 3. The deliverables in each cell must be perfect.	Truth 3. The deliverables in each cell must be useful but not necessarily perfect. In practice, I have delivered row 3 data models in which some entities were analyzed from an enterprise perspective and other entities from a single application's perspective. Statuses that differentiate between model constructs representing an enterprisewide perspective and those representing an application perspective are invaluable. They indicate the constructs' accuracy, completeness, and expected flexibility. If an enterprisewide construct fails to be reusable or shareable, the architect is at fault. If an application-specific construct fails to accommodate a future requirement, it is no one's fault; the construct was never expected to meet future requirements. Efforts should be made to modify such a construct rather than create a new version. The cost of modification or recasting should be captured to document the cost/benefits of architecture.
Myth 4. The network column is the technology column.	Truth 4. The network column is the location column. It prescribes where processes happen, where data is stored, and where business rules execute. Technology implications apply to every column.
Myth 5. You may find it useful to add or delete rows or columns to the Zachman Framework to meet your requirements.	Truth 5. The Zachman Framework is complete in its depiction of the scope of architecture. There are only six interrogatives in any language, corresponding to Who, What, Where, Why, When, and How. You may, of course, elect not to formalize deliverables for some cells. These cells are not deleted from your architecture. You simply make assumptions about them in the absence of formal deliverables.
Myth 6. You must store deliverables from all cells in one repository.	Truth 6. This practice is indeed ideal. Yet some organizations use the Zachman Framework as an index of the deliverables stored in various tools. Indeed, one cell may include a variety of deliverables, such as formal models, word processing documents, and images. For a business audience, a more intuitive business-oriented GUI interface may provide access to an underlying categorization of architecture deliverables based on the Zachman Framework.
Myth 7. The Framework does not lend itself to object orientation.	Truth 7. The Framework is compatible with object orientation. You must express the concept of an object in terms of the interrogatives it addresses and the perspective it serves. If, for example, you consider an object to be the encapsulation of data, process, and rules for the information systems audience, then a deliverable comprising such objects fits into row 3, columns 1,2, and 6.

search - home - archives - contacts - site index

Questions? Comments? We would love to hear from you!