“The software architecture of a program or computing is the structure or structures of the system, which comprise

• Software components
• The externally visible properties of those components
• And the relationships among them.“

Bass et. al.’s continues:

“By ‘eternally visible’ properties, we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. The intent of this definition is that a software architecture must abstract away some information from the system (otherwise there is no point looking at the architecture, we are simply viewing the entire system) and yet provide enough information to be a basis for analysis, decision making, and hence risk reduction.”

That’s the simplest, most concise definition I have seen so far for what is software architecture.

• System
• “A system is defined… as a set of different elements so connected or related as to perform a unique function not performable by the elements alone.”
• Architecture
• “The term ‘architecture’ is widely understood and used for what it is – a top-down description of the structure of the system”.

Not only does the system perform a unique function, but it has unique characteristics and qualities that are inherent in the system and not just the parts.

Thinking about systems, or from a systems perspective, has its roots in work by Buckminster Fuller and Russell Ackoff, among others. More recently, it has been recognized as a field in itself, called “systems thinking”, and has intellectual leaders such as Peter Checkland and Peter Senge (author of the “The Fifth Discipline”). Ebert Rechtin’s “Systems Architecting: Creating and building complex systems” (1991) remains one of the most important works in this domain, and has been highly influential in our approach of architecture.

1. We’d already be doing it
2. Our competitors would already be doing it

Architecture translates the business strategy into a technical strategy, and then realizes the implementation. This is what makes architecture challenging.

Some examples of why architecture is hard:

Reuse across a product family: Many organizations are adopting a business strategy of leveraging commonality across products to enhance productivity, thereby decreasing time-to-market and increasing responsiveness to customers. Everyone’s done the “clone-and-go” approach (taking one product’s code base and modifying it to fit new customer base), and found that it quickly deteriorates into a nightmare of schedules slips and quality.

Now, the business strategy is translated into a product family (a.k.a. product line) architecture strategy, which is implemented as infrastructure and common components to be reused by the product family, and unique installations of products. Here, architecture is not simply the high-level decomposition of an application. The complexity goes way up, due to the widened scope of the problem:

• The technical complexity is compounded by having to accommodate the commonality across the products as well as the uniqueness in each product.
• The organizational complexity is compounded because there are greater dependencies across the organization for requirements input and prioritization, and a more diverse set of schedule-driven product developers who can derail the architecture by ignoring it, challenging it, not following it through lack of understanding, etc.

Improving Consistency and Integration Across Applications: Similarly, this objective introduces greater dependencies, for now the application groups are dependent on the architecture team and their schedules. There is also likely to be strong resistance to the loss of independence.

• Become a dominant player in your industry/market
• Deal with organizational or product complexity
• Enable something that is not possible/feasible today
• Establish a shared technology foundation for a product line
• Be in business in 5 years
• Want a product, system or family of applications to have qualities or system characteristics such as a high level of integration, evolvability, understandability, etc.

Good architecture enhances productivity by:

• Allows components to be developed in parallel, by outside contractors (i.e. outsourcing), etc.
• Ensures the components fit together (through standard interfaces and common mechanisms)
• Is flexible, evolvable, adaptable (with replaceable components, localized changes, etc.)
• Provides mechanisms for consistency, interoperability (through common services and infrastructure)

These features enhance productivity and allow the organization to focus on
differentiation.

Reality Check – The architecture(s) that are being discussed are those of significance. The simple application architecture created by a small team for it’s own use in development makes a contribution to that team, but tends to not to be highly strategic to the company. The architecture mentioned are those intended to be strategic, and which by their nature are more complex, both technically and organizationally.

These may be:

• Architectures for a product family/line
• Architectures that span multiple organizations ( divisions, groups, functions, etc.)
• Architectures that have a lot of uncertainty

Architecture – addresses the question “What is architecture?” and associated concerns such as architectural positions, architectural patterns or styles, components and interface specification, etc.
Architecting – addresses the question(s) “How do I create an architecture?”, “How do I recapture an architecture?”, and “How do I migrate an existing system to a new architecture?” Other architecting issues that are handled are modeling and documenting architectures, accessing architectures against requirements and making tradeoffs among architectural alternatives, capturing architectural requirements, etc.
Architects – addresses the question “Who should do it? And associated questions such as “What is the role and responsibilities of an architect?” and “What skills do I need to develop to be most effective as an architect?”
Strategy – addresses the question relating to competitive differentiation through architecture (“Why do it?”), and timing of architecture investments (“When?”).
Context – addresses the question “Where in the organization should the architecting be done?”