- Conway's Law
- Applying Conway's Law
- Summary
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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:
Follow a number of change process threads.
Build relationships with the "real architects."
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.