Definition (Top)
See text pages 2 thru 4

As the text and some of the assigned readings indicate, there are a number of attempts to define what is meant by a software architecture. Given that our interest is in architectures for enterprise applications, the following definition from Bass, Clements, and Kazman [Bass98, p23] may be the most appropriate:

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

"Externally visible" properties refers to those assumptions other components can make of a component, such as provided services, performance characteristics, fault handling, shared resource usage, and so on.

Although our focus is on software architectures, it is almost impossible to completely automate an enterprise application system. One of the early architecture decisions will be to determine which events should be processed using manual processors (humans) and which events should be processed using automated processors.

Their definition is followed by a discussion of its implications:

• Architecture defines components
  Architecture is an abstraction of the system. It describes how components interact with each other. The architecture concentrates on the interfaces between components. It supresses details that do not affect how a component uses, is used by, relates to, or interacts with another component. This means that the private details having to do solely with internal implementation are not architectural. Those details are engineering details.

• Systems can comprise more than one structure
  

• Every software system has an architecture
  This is true because every system can be shown to be composed of components and relations among them. Although trivial, a system with only one component has an architecture that satisfies the definition.

• The behavior of each component is part of the architecture
  The architecture is concerned with the behaviour that can be observed or discerned from the point of view of another component. Because a graphical model does not fully describe the interfaces and functionality of the interacting components, graphical models are not, in themselves, the architecture.

Purpose (Top)
See text pages 10 thru 11

There are three main reasons why architecture is important [Bass98, p28] :

• Communication Among Stakeholders
  

• Represents Early Design Decisions
  
  • Define Constraints on Implementation
    
  • Dictates Organizational Structure
    
  • Inhibits or Enables a System's Quality Attributes
    
  • Permits Prediction of System Qualities
    
  • Makes it Easier to Reason About and Manage Change
    
  • Helps in Evolutionary Prototyping
    

• Transferable Abstraction of a System
  
  • Product Lines Share a Common Architecture
    
  • Permits Use of Large, Externally Developed Components
    
  • Restricts Vocabulary of Design Alternatives
    
  • Permits Template-Based Component Development
    
  • Basis for Training
    

Stakeholders (Top)
See text pages 10 thru 11