Software Architecture

The Architecture Business Cycle

Taken from Chapter 1 of

Len Bass, Paul Clements, and Rick Kazman,

Software Architecture in Practice, 2nd Edition,

Addison Wesley, 2003.

The Role of Architecture

Traditionally,
Requirements beget design, which begets system.

Software Architecture,
encompasses the structures of large software systems.

Preliminary Def.
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Architecture as a Tool
An important tool for:
Communication Reasoning Analysis Growth And, ... Publication!

Influences on the Architecture

Stakeholders
Low Cost Keeping people employed Leveraging existing corporate assets Performance Security Reliability End User

Development Management

Modifiability Neat Features Short time-to-market

Marketing

NAAAH! Low cost Parity with competing products Architect Customer

Not changed very often

Maintenance

Developing Organization
Structure and Nature Staff Skills Schedule and Budget Three Categories:
Immediate Business Long-term Business Organizational Structure

Architect's Experience
Education and training Exposure to successful architectural patterns Exposure to systems that have worked particularly Wish to experiment

Technical Environment
The environment that is current when an architecture is designed will influence that architecture.
It is a brave architect who, in today's environment, does not at least consider a Webbased, object-oriented, middleware-supported design for an information system.

Requirements
Identify and actively engage the stakeholders
Architecture reviews Iterative prototyping

More than just technical skills

Diplomacy Negotiation Communication

Feedbacks

Effects on Dev. Org.

Teams are formed for individual software units Schedules and budgets allocate resources in chunks corresponding to the units Families of similar systems Establish a foothold in a particular market area

Other Effects
The customer may be willing to relax some requirements to gain economy Architect's experience with subsequent systems Change the software engineering culture

Activities Around Architecture

Creating the business case for the system Understanding the requirements Creating or selecting the architecture Documenting and communicating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Ensuring that the implementation conforms to the architecture

What Makes a Good Architecture?

There is no absolute good or bad! Architectures are either more or less fit for some stated purpose. Architectures can in fact be evaluated but only in the context of specific goals

Process Recommendations
Single architect (or a small group) Should have
Functional requirements Prioritized list of quality attributes

Well documented Circulation to the system's stakeholders

Process Recommendations
Analysis for applicable quantitative measures Creation of a skeletal system Specific (and small) set of resource contention areas

Structural Guidelines
Information-hiding modules Well-defined interfaces Quality attributes Independent of a particular version of a commercial product or tool Modules that produce data should be separate from modules that consume data.

Structural Guidelines
A small number of simple interaction patterns For parallel processing systems:
Well-defined processes or tasks Assignment to specific processors should be changed