Technical Environment
Current trends: today’s information system will likely employ a • database management system • Web browser for delivery and distribution across platforms This was not true 10 years ago. Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.

Architect’s Background
Architects develop their mindset from their past experiences. • Prior good experiences will lead to replication of prior designs. • Prior bad experiences will be avoided in the new design.

Factors Influenced by Architectures
Structure of the development organization Enterprise goals of the development organization Customer requirements Architect’s experience Technical environment The architecture itself

Architecture Influences the Development Organization Structure
Short term: work units are organized around architectural units for a particular system under construction. Long term: when company constructs a collection of similar systems, organizational units reflect common components (e.g., operating system unit or database unit).

Architecture Influences the Development Organization Enterprise Goals
Development of a system may establish a foothold in the market niche. Being known for developing particular kinds of systems becomes a marketing device. Architecture becomes a leveraging point for additional market opportunities and networking.

Architecture Influences Customer Requirements
Knowledge of similar fielded systems leads customers to ask for particular features. Customers will alter their requirements on the basis of the availability of existing systems.

Architecture Influences the Architect’s Experience and Technical Environment
Creation of a system affects the architect’s background. Occasionally, a system or an architecture will affect the technical environment. • the WWW for information systems • the three-tier architecture for database systems

ABC Summary
Architecture involves more than just technical requirements for a system. It also involves non-technical factors, such as the • architect’s background • development environment • business goals of the sponsoring organization Architecture influences the factors that affect it. • Architects learn from experience. • The development environment is expanded and altered. • Businesses gain new marketing possibilities.

The Definition of Software Architecture
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. Notice this means that • box-and-line drawings alone are not architectures, but a starting point. • architecture includes behavior of components

Architectural Style -1
Architectural style: a description of component and connector types and a pattern of their runtime control and/or data transfer [Shaw 96] Architectural styles are a set of canonical architectural solutions to problems. Styles are underspecified architectures. They suggest patterns of runtime interaction, and topologies of components.

Architectural Style -2
A style may be thought of as • a set of constraints on an architecture • an abstraction for a set of related architectures Styles appearing in the literature include • client server • cooperating process • data-centered • layered

Important of Architecture to a Development Project
Architecture is important for three primary reasons. 1. It provides a vehicle for communication among stakeholders. 2. It is the manifestation of the earliest design decisions about a system. 3. It is a transferable, reusable abstraction of a system.

Reusable Model
An architecture is an abstraction: a one-to-many mapping (one architecture, many systems). Architecture is the basis for product (system) commonality. Entire product lines can share a single architecture. Systems can be built from large, externally developed components that are tied together via architecture.

What Are Structures Used For?
Descriptive: documentation vehicle for • current development • future development • managers • customers To document the architecture, document the views. Prescriptive: engineering tool to help achieve qualities

Architectural Structures Summary
Structures are related to each other in complicated ways. In some systems, different structures collapse into a single one. (For example, process structure may be the same as module structure for extremely small systems.)

Which Views Should I Use?
Rational Unified Process: 4+1 views Siemens 4-view model (C4ISR framework prescribes 3 views, but these are not views of the software architecture. More later.) What to do? Choose the structures that are useful to the system being built and to the achievement of qualities that are important to you.

CelsiusTech’s Response
Business strategy • create a product family • make the software scaleable over a wide range of systems Technical strategy • create a new generation of system - hardware, software - supporting development approach • configure systems from product family; each new project was added to the family

Cummins’ results by the numbers -2
• Customer satisfaction is high. Productivity gains enables new features to be developed (more than 200 to date) • Projects are more successful. Before product line approach, 3 of 10 were on track, 4 were failing, and 3 were on the edge. Now, 15 of 15 are on track. • Widespread feeling that developers are more portable, and hence more valuable.

Cummins’ results by the numbers -4
Cummins management has a history of embracing change, but carefully targeted change. They esimate that process improvement alone has brought a benefit/cost ration of 2:1 to 3:1. They estimate that the product line approach has brought a benefit/cost ration of 10:1. Product line approach let them quickly enter and then dominate the industrial diesel engine market.

What Is a Product Line?
A product line is a group of products sharing a common, managed set of features that satisfy specific needs of a selected market or mission. pertain to
Market strategy/ Application domain

What is a Software Product Line?
A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Lessons in organizational management.
• • • • People issues: how to bring about change, how to launch the effort Organizational structure: Who builds the core assets? Funding: How are the core assets paid for? Interacting with the customer has whole new dimension
Version 1.0 CECOM Course 2, Lecture 1 - page 84

Practice Areas
A practice area is a body of work or a collection of activities that an organization must master to successfully carry out the essential work of a product line. • Are finer chunks than the essential activities • Must be mastered to carry out the essential activities • Provide starting points for organizations wanting to make and measure product line progress

AOSD (cont’d.)
AOSD tools and languages let programmers weave these separate concerns together in discrete elements, so that these global design decisions (that have farreaching effects) can be changed locally. AOSD represents the introduction of truly architectural thinking into program development. For more information: http://www.aosd.net.

Predictable Assembly of Certifiable Components (PACC)
At the vanguard of work on component-based systems. Previous work has concentrated on component selection and qualification, and building frameworks for component-based systems. This work focuses on building systems with provable quality attributes from components.