InformIT

Conway's Law Revisited: Successfully Aligning Enterprise Architecture

Date: May 1, 2002

Article is provided courtesy of Prentice Hall Professional.

Return to the article

For investments in enterprise architecture to pay off, they must be based on a clear understanding of the organization. Whatever approach you choose to implement your enterprise strategy, an understanding of Conway's Law can help to make your alignment efforts successful.

Those faced with the task of building enterprise architectures for large and even not-so-large organizations are likely to find information systems whose fuzzy boundaries and complex interconnections are matched by the organizations from which they came. The challenge of the task expands exponentially as size and complexity grows. Federal agency CIOs (pressured by Congress and the Office of Management and Budget) and industry CIOs (themselves pressured by corporate boards of directors) are no longer interested in funding duplicative, incompatible, or just plain antiquated IT projects. Both Federal agencies and commercial firms find themselves very much aware of demands to align information technology investments and business objectives. So, what do you do when you find yourself in an architecture leadership role?

Conway's Law

In a landmark 1968 article, Melvin Conway stated that the structure of a system reflects the organization that designed the system [Conway68]. This has come to be known as "Conway's Law" [Jargon02][Copelien95]. There is no shortage of aging stovepipe information systems that reflect Conway's insight. On the surface, Conway's insight suggests a "clean slate" approach to alignment: 1) Define the business mission; 2) Learn the business processes from business owners; 3) Re-engineer these business processes to fit the mission; and 4) Structure the IT organization to support the reengineered business processes. Then, if the theory holds, IT systems will naturally align themselves to support the business mission. A number of organizations have tried to implement enterprise architecture using a similar process. However, this approach does not always yield the expected results.

According to the Office of Management and Budget, enterprise architecture describes and documents the current and desired relationships among business and management processes and information technology, and lays out a blueprint for incremental change to both business and technology [OMB00]. Done well, enterprise architecture can transform an organization. However, you don't have to look very far to find organizations that have been through three or more unsuccessful multi-million dollar efforts reflecting a surface understanding of Conway's Law.

It's not hard to see why the clean slate approach has so much appeal. For example, you could easily spend 40 person years modeling just the applications used within some Federal agencies. So, why not clean up—re-engineer the IT organizational structure? Doesn't Conway's Law say that [software] system structure reflects organization structure? Why not capture the business rules from those involved in carrying out the business of the organization, and re-engineer accordingly? Then, build a new set of systems to meet their needs.

Many organizations have tried this clean slate approach: identifying goals, gathering business rules from business owners, and then restructuring the IT organization. A particularly significant problem is that "business owners" don't always know all the business rules. Some very important business rules are often embedded within the software and within the IT culture. Similarly, IT owners don't always know about all IT applications—this is often because business owners get frustrated with long delays and build their own solutions. All too often, a lot of money, effort, fanfare, and pain produce few positive results—everyone keeps doing what they always did. So why does it appear that Conway's Law does not work in these cases?

Applying Conway's Law

What is missing can be found if we revisit the original 1968 article. The first sentence in Conway's conclusion reads, "...organizations which [sic] design system...are constrained to produce designs which are copies of the communication structures of these organizations." [Conway68](emphasis added). Conway's insight ran a lot deeper than org charts; how the organization actually communicates is essential.

This is not to say that restructuring is bad. However, restructuring can be very risky if you don't have a clear idea of the communication paths within your organization, and is even more risky if you don't have a clear idea of the communication paths within the systems your organization has built. Unless you know the organization's communication paths, you may even spend all your time reorganizing people who have little to do with what actually gets done.

Another way of looking at Conway's Law is to clarify both organization and information technology before attempting to simplify them [Dikel01]. Pay attention to organizational structure when you determine how to simplify technology. If you don't, you may find the changes you make to be temporary. For example, if ownership of two components lies within two groups and you arbitrarily simplify system design so that only one component remains, each group may find very good reasons why its team is uniquely capable of building the one component. Very quickly, each will have its own version of the "simplified" design. The result is more complexity. And if some design rationale wasn't hidden before, it will be partially hidden now because turf issues are rarely articulated. The functional behavior of an organization is worth an equally careful look. Hidden agendas, protocols, cultures, and feuds over resources can blindside an unsuspecting architect.

Here's a three-step approach that should help you clarify enterprise architecture:

  1. Follow a number of change process threads.

  2. Build relationships with the "real architects."

  3. Look for, record, and test your observations.

Follow a Number of Change Process Threads

What formal processes are in place? Look carefully at the current maintenance process for a small but important area of IT. However, the formal process, and even those who are named as its responsible parties, may not yield as much information as you expect. Start with requests for significant changes. If there is a formal process, find out who is involved in scoping requests. For a non-trivial request, find the person who determines which groups will make changes, and who gets answers about the scope and impact of a request. Who did he or she talk to? Did he or she ask a gatekeeper, or did they just know? As in any research, collect artifacts and organization names of those involved, and map your results. You may find that most of this information is kept in someone's head or drawer if you are lucky.

Suppose your organization's initial efforts find a number of formal processes that don't quite map one to another. For example, you may find that an approved change request may not shed much light on which applications will require change. An approved budget request may not identify which change requests the budget will be used to fulfill. One very productive way to get past the gobbledygook is to trace the communication paths actually used to get things done. Although you will need to understand the formal channels for background and context, you need to focus your efforts to identify and understand those actually used.

Build Relationships with the "Real Architects"

Learning the "whos" and the "whats" that actually get things done is not always easy. In some cases, unless you have worked in an organization for 20 years, these channels are very hard to identify. And even then, few if any people in a multi-thousand-person organization may be able to articulate all the critical communication paths. Unfortunately, many corporate downsizing efforts result in the departure of many of these key people. Recovering this information after the fact can be expensive and arduous. In any case, you will probably need an experienced guide. You are likely to find a small number of what you could call the "real architects"—those who hold everything together. To aid your research, negotiate a clear and rewarding role for these folks.

Look For, Record, and Test Your Observations

Document organizational patterns and anomalies; then talk to people to see if they resonate. You'll know you are on the right track when you hear old-timers pick up your characterizations, and use the documents you helped build. There are several approaches you can use to make sense of the information you collect. Some organizations make use of Zachmann frameworks [Zachman02]. UML is an additional tool that many use, although it is worth noting that UML 2.0 will be much better suited to an architectural context. Jim Coplien used an approach based on CRC cards in the development of his organizational patterns [Coplien94][Coplien95]. The model and approach described in our book, Software Architecture: Organizational Principles and Patterns, can help you understand the organizational dynamics [Dikel01]. Some of the tools that we prepared to collect information using our model are located at the end of this article.

However, regardless of what approach you use, you should avoid "death by modeling." The model is just a tool. All too often, groups can get caught up in the modeling activity instead of the goals to be satisfied by the model.

Apply these steps until you identify a critical mass of patterns and communication paths; and establish a formal way to recognize, reward, and engage the core group of architects and others you have found that will help their organization change for the better. The idea here is not to provide lifetime employment. The idea is to gain a foothold so that you can triangulate, comparing written policies, processes, and structure charts with the statements of people who make the real process work and with the rules and tools they actually use.

By tracing and documenting communication paths, identifying organizational patterns, and establishing a core group who will tell you when you are off-track, you gain a foothold. These measures can work to reduce the risk and increase the effectiveness of your enterprise architecture efforts.

Summary

For investments in enterprise architecture to pay off, they must be based on a clear understanding of the organization. Whatever approach you choose to implement your enterprise strategy, an understanding of Conway's Law can help to make your alignment efforts successful. Conway observed that there is a strong relationship between the software created in an organization and both the structure of that organization, and how the people in that organization really communicate. To put this insight into practice, you need to use not just the formally documented structure and processes of your organization is, but you also need to observe and learn the informal communication paths as well.

References

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240