Motivating Software Architecture

or Why Do We Need Software Architecture?

A successful architecture forms the platform for strategic advantage. By contrast, the lack of architecture bonds the organization inescapably to its past. For most organizations, our legacy is a tortuously tangled slew of haphazard systems born of a time of amazing wizardry but little system discipline. These legacy systems are expensive and hard to change, but replacing them threatens the very "life" of the organization.

Brittle monolithic systems, silo applications, and long and unpredictable development times, are symptomatic of architectural decay which causes huge organizational drag. To break the chains of our corporate legacy and build systems that fit the environment, and adapt with the environment as it changes, we need architecture.

Whether we seek to lead through innovation, customer intimacy or operational excellence, architecture is the essential foundation for agility, responsiveness and effectiveness. Architecture addresses complexity, leaving the team mind-space open to innovation. It is the enabler for reliable systems developed in "Internet time," eCommerce systems that scale, and CRM systems that "Wow" customers with an individualized experience.

Architecture serves both technical and organizational purposes. On the organizational side, the architecture helps in:

• communicating the high-level design: A number of stakeholders need to understand the system at a fairly gross level. These include higher-level managers, many of the cross-functional team (e.g., marketing, quality assurance, and learning products or user documentation), and may include customers too. Modeling the system at a high level facilitates communication of the high-level system design or architecture. The reduction in detail makes it easier to grasp the assignment of significant system responsibilities to high-level structures. Moreover, it satisfies the constraint that, though seemingly trivial, has important implications for communication—with suitable leveling and nesting, even large and complex architectures can be conveyed using presentation slides and documented using traditional 8.5 x11'' paper!
• providing the system context: The developers (and future maintainers) also need to understand the overall system. In large systems, developers cannot efficiently understand the details of the entire system. They need a detailed understanding of the more narrowly-scoped portions of the system that they work on. But without an understanding of the responsibilities and interdependencies of the higher-level structures, individual development and optimization of the substructures will tend to result in a sub-optimal system. This is both from the point of view of system characteristics like performance, as well as effort in integration and maintenance.
• work allocation: Where architectures decompose the system into substructures that are relatively independent, have clear responsibilities, and communicate with each other through a limited number of well-defined interfaces, the development work can be partitioned effectively. This allows parallel development work to proceed in relative independence between integration points. This is especially important in large projects, or projects where the teams are geographically dispersed or subcontractors are used. Moreover, since these units tend to be centers of specialization of function or service, they also afford opportunities for skill specialization among developers. This independence and focus makes development more efficient. The design of the system architecture can be viewed as the dual of designing the organization architecture. If this duality is ignored and the organization architecture is not compatible with the system architecture, then it can influence and degrade the system architecture. This is known as "Conway's Law" (Conway, 1968).

On the technical side, architecture allows us to design better systems:

• meet system requirements and objectives: Both functional and non-functional requirements can be prioritized as ``must have'' vs. ``high want'' vs. ``want'', where ``must have'' identifies properties that the system must have in order to be acceptable. An architecture allows us to evaluate and make tradeoffs among requirements of differing priority. Though system qualities (also known as non-functional requirements) can be compromised later in the development process, many will not be met if not explicitly taken into account at the architectural level.
• enable flexible distribution/partitioning of the system: A good architecture enables flexible distribution of the system by allowing the system and its constituent applications to be partitioned among processors in many different ways without having to redesign the distributable component parts. This requires careful attention to the distribution potential of components early in the architectural design process.
• reduce cost of maintenance and evolution: Architecture can help minimize the costs of maintaining and evolving a given system over its entire lifetime by anticipating the main kinds of changes that will occur in the system, ensuring that the system's overall design will facilitate such changes, and localizing as far as possible the effects of such changes on design documents, code, and other system work products. This can be achieved by the minimization and control of subsystem interdependencies.
• increase reuse and integrate with legacy and third party software: An architecture may be designed to enable and facilitate the (re)use of certain existing components, frameworks, class libraries, legacy or third-party applications, etc.

Adapted (with permission) from Malan and Creary, Fusion Newsletter, April 1996.

You are convinced that architecture is important, but how do you convince senior managers? One approach that is very successful, is to integrate their business goals into an architectural vision and present that vision in a way that is compelling to them. For help in doing this, you can consider taking our Architecture Vision Workshop and take a look at:

• our paper titled "Creating an Architectural Vision: Collecting Input" (vision_input.pd, 10kb) for ideas on how to gather input for the vision.
• the Vision Graphic Guide from Grove Graphics International. It provides a great way to collect group inputs to a vision, and to organize vision elements.
• the fictitious newspaper article vision we created as a promotion (Newspaper_ Vision.pdf, 34 kb). Note that vision example was created way back in 2001, when 2003 was in the future!! But you'll still get the idea.

References

• Conway, M.E. "How do Committees Invent?", Datamation, (14) 4, April 1968. pp28-31.
• Morris, Charles and Charles Ferguson. "How Architecture Wins Technology Wars". Harvard Business Review, March 1993.