Conway's Law Revisited: Successfully Aligning Enterprise Architecture
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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?