Architecture is like a Bridge

Architecture is like a bridge that connects between business and technology.

Business connects to one side of the bridge The other side of the bridge connects to IT

Its purpose is twofold:

• Helps business people better understand technology


• Helps technology people better understand business

Architecture is a lot like teaching technologists the same lessons Peter Drucker, the "father" of modern management, taught to business executives. His message was very simple: "Look at people, not at machines or buildings."

Technologists need to learn that there's more to organizing information besides "command and control" methods.

A technologist's principle task ought to be:

• making people capable of joint performance
• making an organization's strengths more effective
• making an organization's weaknesses irrelevant

Business people literally need to learn how to think about and manage technology in precisely the same way that they currently know how to think about and manage:

• money
• people
• property

The business side of architecture is based on the logic of rational organization and production. Rationalization works by applying scientific management to the creation of defined, quantifiable, repeatable production and organizational processes. Almost every facet of modern industry takes some quantifiable process, maximizes it for efficiency based on a distinct division of labor, with defined inputs and outputs, and then manages it based on a rules-bound bureaucratic structure.

The technology side of architecture is not quite the same. That's not to say that inside IT there haven't been efforts to rationalize, such as: IT resource planning (sometimes referred to as ERP for IT); or IT service management. The result of rationalization is a process supposedly capable of being engineered.

Multiple craft industries over the past two centuries -- all of which were once considered impossible to manufacture or mass-produce -- have yielded to the resulting benefits of efficiency and quality that rationalization achieves. Yet, the creation of software has still somehow managed to elude an engineered approach to its production, even after 30 years of tremendous effort. In attempting to engineer the process, software developers cannot agree on the details of a defined, quantifiable, repeatable process. Instead, highly skilled professionals still craft most of the world's software.

Why haven't basic industrial patterns -- software industrialization, software manufacturing, software engineering, and software assembly lines -- become dominant? By the time the automotive industry had reached its 30th anniversary, around 1930, the fundamental issues of production, as exemplified by Ford's assembly line; product, as exemplified by standardized design; and industry, as exemplified by the few dominant national players like Ford and GM, had all been clearly established.

Is software an act of engineering or communication?

If, indeed, software is a rational endeavor, then it should be possible to improve quality by providing better and more resources. "Better and more resources" means better management, better tools, more disciplined production, and more programmers.

If, on the other hand, software is a craft, then improving quality involves the exact opposite: focusing on less hierarchy, better knowledge, more-skilled programmers, and greater development flexibility.

The essential limit of software development is communication. Communication is inherently difficult, mediated by always-contextual codes, norms, culture, and perceptions. Translating knowledge from one context to another, like translating any language involves not just basic grammar and syntax rules, but also issues of meaning and intent that are contextual and subjective.

Software is the execution of knowledge. Much of knowledge is tacit, undefined, uncodified, and developed over time, often without being explicit even to the individuals participating in the process. More importantly, such knowledge and practices are dynamic, constantly evolving and transforming.

Modeling the execution of knowledge has proven to be exceedingly difficult -- often incomplete, impractical, or unsatisfactory. The less broadly accepted and understood the knowledge within a domain, the more difficult the task becomes of translating that knowledge. The issues are inevitably about context and communication.