Columns

Architecture, planning and design

• By John D. Williams
• July 1, 2002

''Time is what keeps everything from happening all at once. Space is what keeps everything from happening to you.'' -- Neill D. Hicks, Writing the Action-Adventure Film: The Moment of Truth

Often, a developer's time is spent scattered across a hodgepodge of activities. One moment you are writing code, the next moment you are gathering requirements. At the same time, you need to create plans for completing your projects. You are driven by deadlines and yet you strive to add value to the company beyond your immediate project. You live in a world where time and space collapse into a single focal point. Everything is needed now, and you are the only one who can deliver.

This is a problem -- in more ways than one. One way to manage the pressure that comes from being a focal point is to understand the purpose of different activities and to appreciate what activities add what value and in what fashion. I raise this issue because recently I've seen developers confuse the activities they are doing with those that are needed. This leads to frustration, unsuccessful projects and an inability to help IT add value to the business. Most of the confusion seems to come from a fuzzy understanding of the differences between architecture, planning and design. In particular, developers may confuse architecture with design.

I know the words sound different but, in practice, people confuse the three. I've seen developers who are deep into an implementation design, who believe they are doing architecture. Others think planning is just stuff that happens while doing architecture and design. These distinct activities require different skill sets and bring a particular value to the business. They are used at different times to accomplish specific purposes. Under pressure to get many things accomplished, it's easy for developers to blur the distinctions between these activities. As a result, developers may spend their time doing one thing, while thinking they are actually accomplishing something else. Let's explore these three activities and see if we can shed some light on their purpose, value and differences.

Architecture is an overloaded word. We have many different types of architecture. There are enterprise architectures, target architectures and system architectures. Other architects might add even more types. No wonder developers are not clear about what architecture is. It's easiest to understand the distinctions if we start at a high level and work our way down to greater levels of detail.

Enterprise architecture is the practice of using models to represent various stages of transformation to assist in the assessment of opportunities, the development of plans and the governance of change programs. What does this mean? In enterprise architecture, we develop an understanding of the business, its operational functions, the systems that support the operations and the technology that supports the systems. This understanding becomes the basis for other activities. Enterprise architecture is not about implementing a system or finding the best projects. It is about understanding the various aspects of the business and the relationships between these aspects. It is the groundwork we build from in our other activities.

Target architecture plays a similar role. Target architecture is the representation, through the use of architecture models, of a desired end state or an interim state in a migration strategy. Don't confuse target architecture with its implementation. Its role is to show a desired end state, not to specify how you get there. Target architecture has a role similar to that of enterprise architecture -- it provides a basis for further work. In a similar fashion, system architectures show how various systems and families of systems support a business's operational capability. They show the information flows that support operational functions and denote which system serves as the system of record for a given piece of information. This is not the same as the design of the system. System architectures provide no details of how a system manages a piece of information. What they do provide is a map to a particular automated subset of the enterprise, its various components and their relationships.

In many ways, architecture is like a framework or context in which we can accomplish other activities. You could build a house without a blueprint, but would you want to live in the result? A blueprint is not the finished house. Depending on the purpose of the blueprint, it may not show many of the details that must be addressed to implement the house. That's OK. It still provides the guidance appropriate to its purpose. This is true for architecture as well. An architecture's value comes from its ability to help us make informed decisions and build upon the foundation it provides. It helps us make good decisions through its alignment with the business and helps us to understand the various factors impacted by our decisions.

Planning, for many developers, is a haphazard activity that may or may not happen with any formality. Merriam Webster's Collegiate Dictionary defines planning as ''the act or process of making or carrying out plans.'' Planning also means to devise or project the realization of achievement of a program. In the context provided by an enterprise architecture, planning is typically focused on some type of opportunity assessment. An opportunity assessment uses the architecture as a basis for analyzing various types of opportunity improvements, prioritizing the ones identified and selecting projects for implementation. Opportunity assessments come in many flavors. These include assessments for operational effectiveness, new system opportunities, infrastructure consolidations, resource rationalization, organizational design, business process reengineering and product portfolio strategy development. Because the enterprise architecture covers the entire business, we can use it to assess many different aspects of the business, not just IT issues. The value of combining architecture and planning is that we come up with prioritized programs that are aligned with the needs and priorities of the business.

Design is focused on the implementation of the projects we selected through planning, guided by architecture. Merriam Webster's defines design as, ''to create, fashion, execute, or construct according to plan.'' Notice that design is not the same as creating the plan, gathering information and/or providing a context for a plan. Design is where we take our architectures and plans and turn them into something concrete. Design is not the same as writing code to implement a system. However, for purposes of this discussion, it is useful to group it with implementation to help us distinguish between architecture, planning and design. Too often, developers confuse the detailed work they are doing in design with creating an architecture. They are not the same. Design fleshes out the implementation details of a context provided by an architecture. Planning helps you know which things you ought to be designing in the first place.

Sequence leads to value
Reuse provides us with an example of how all three activities can work together. If we begin with an enterprise architecture, we can drive it down through a domain analysis and create a reuse architecture that clearly identifies which components add the most value when they are reused and where it is best to reuse them. We can then take the reuse architecture and, with a planning activity, create a roadmap for prioritizing the development or acquisition of the reusable components. A design activity can flesh out the implementation details or requirements needed for building or buying the reusable components.

Notice that this reuse process does not begin with designing components and then making them available for use elsewhere. That bottom-up approach will not lead to reuse. Any components you make available in this fashion will be off-target because you don't have a blueprint to show you how they fit into the big picture. The sequence in the process is important. The activities in the process each add their unique value to the process. Confusing one step for another will not lead to the desired outcome.

Avoid being the focal point of all time and space by using architecture, planning and design to their best advantage.