Slide 1:

The Many Context of Software Architecture Chapter 3

Slide 2:

Some Context of system Architecture Technical. What technical role does the software architecture

play in the system or systems of which its a part?

Project life cycle. How does a software architecture relate to the other phases of a software

development life cycle?

Business. How does the presence of a software architecture affect an organizations business

environment?

Professional. What is the role of a software architect in an organization or a development project?

Slide 3:

3.1 Architecture in a Technical Context Architectures Inhibit or Enable the Achievement of Quality

Attributes

The first three reasons in that List of Thirteen (covered in chapter 2) deal specifically with an

architectures technical impact on every system that uses it:

An architecture will inhibit or enable the achievement of a systems quality attributes.

You can predict many aspects of a systems qualities by studying its architecture.

An architecture makes it easier for you to reason about and manage change.

Slide 4:

Architectures Inhibit or Enable the Achievement of Quality Attributes If your system requires high

performance, then you need to pay attention to managing the time-based behavior of elements, their

use of shared resources, and the frequency and volume of inter element communication. To that list,

well add the following:

If you care about a systems availability, you have to be concerned with how components take over
for each other in the event of a failure, and how the system responds to a fault.

If you care about usability, you have to be concerned about isolating the details of the user interface

and those elements responsible for the user experience from the rest of the system, so that those

things can be tailored and improved over time.

Slide 5:

Architectures Inhibit or Enable the Achievement of Quality Attributes If you care about the testability

of your system, you have to be concerned about the testability of individual elements, which means

making their state observable and controllable, plus understanding the emergent behavior of the

elements working together.

If you care about the safety of your system, you have to be concerned about the behavioral

envelope of the elements and the emergent behavior of the elements working in concert.

If you care about interoperability between your system and another, you have to be concerned

about which elements are responsible for external interactions so that you can control those

interactions.

Slide 6:

3.2 Architecture in a Project Life-Cycle Context There are four dominant software development

processes, which we describe in roughly the order in which they came to prominence:

1. Waterfall. For many years the Waterfall model dominated the field of software development. The

Waterfall model organized the life cycle into a series of connected sequential activities, each with

entry and exit conditions and a formalized relationship with its upstream and downstream neighbors.

The process began with requirements specification, followed by design, then implementation, then

integration, then testing, then installation, all followed by maintenance.

Feedback paths from later to earlier steps allowed for the revision of artifacts (requirements

documents, design documents, etc.) on an as-needed basis, based on the knowledge acquired in

the later stage. For example, designers might push back against overly stringent requirements,
which would then be reworked and flow back down. Testing that uncovered defects would trigger

reimplementation (and maybe even redesign). And then the cycle continued.

Slide 7:

waterfall model

Slide 8:

2. Iterative. Each iteration should deliver something working and useful. The trick here is to uncover

early those requirements that have the most far-reaching effect on the design; the corresponding

danger is to overlook requirements that, when discovered later, will capsize the design decisions

made so far.

An especially well known iterative process is called the Unified Process (originally named the

Rational Unified Process, after Rational Software, which originated it). It defines four phases of each

iteration: inception, elaboration, construction, and transition. A set of chosen use cases defines the

goals for each iteration, and the iterations are ordered to address the greatest risks first. Architecture

in a Project Life-Cycle Context

Slide 9:

Iterative and rational unified process models

Slide 10:

3. Agile. What distinguishes Agile practices is early and frequent delivery of working software, close

collaboration between developers and customers, self-organizing teams, and a focus on adaptation

to changing circumstances (such as late-arriving requirements). All Agile methodologies focus on

teamwork, adaptability, and close collaboration (both within the team and between team members

and customers/end users). These methodologies typically eschew substantial up-front work, on the

assumption that requirements always change, and they continue to change throughout the projects
life cycle. Architecture in a Project Life-Cycle Context

Slide 11:

Agile model

Slide 12:

4. Model-driven development. Model-driven development is based on the idea that humans should

not be writing code in programming languages, but they should be creating models of the domain,

from which code is automatically generated.

Humans create a platform-independent model (PIM), which is combined with a platform-definition

model (PDM) to generate running code. In this way the PIM is a pure realization of the functional

requirements while the PDM addresses platform specifics and quality attributes. Architecture in a

Project Life-Cycle Context

Slide 13:

No matter what software development process or life-cycle model youre using, there are a number

of activities that are involved in creating a software architecture, using that architecture to realize a

complete design, and then implementing or managing the evolution of a target system or

application. The process you use will determine how often and when you revisit and elaborate each

of these activities. These activities include:

1. Making a business case for the system

2. Understanding the architecturally significant requirements

3. Creating or selecting the architecture

4. Documenting and communicating the architecture

5. Analyzing or evaluating the architecture

6. Implementing and testing the system based on the architecture

7. Ensuring that the implementation conforms to the architecture Architecture in a Project Life-Cycle
Context

Slide 14:

Making a Business Case for the System A business case is, briefly, a justification of an

organizational investment. It is a tool that helps you make business decisions by predicting how they

will affect your organization.

Initially, the decision will be a go/no-go for pursuing a new business opportunity or approach. After

initiation, the business case is reviewed to assess the accuracy of initial estimates and then updated

to examine new or alternative angles on the opportunity.

By documenting the expected costs, benefits, and risks, the business case serves as a repository

of the business and marketing data. In this role, management uses the business case to determine

possible courses of action.

Slide 15:

Making a Business Case for the System

Slide 16:

Making a Business Case for the System

Slide 17:

Understanding the Architecturally Significant Requirements There are a variety of techniques for

eliciting requirements from the stakeholders.

For example, object-oriented analysis uses use cases and scenarios to embody requirements.

Safety-critical systems sometimes use more rigorous approaches, such as finite-state-machine

models or formal specification languages.

One fundamental decision with respect to the system being built is the extent to which it is a

variation on other systems that have been constructed.

Another technique that helps us understand requirements is the creation of prototypes.

Prototypes may help to model and explore desired behavior, design the user interface, or analyze

resource utilization.

This helps to make the system real in the eyes of its stakeholders and can quickly build support for

the project and catalyze decisions on the systems design and the design of its user interface.

Understanding the Architecturally Significant Requirements

Slide 19:

Creating or Selecting the Architecture In the landmark book The Mythical Man-Month, Fred Brooks

argues forcefully and eloquently that conceptual integrity is the key to sound system design and that

conceptual integrity can only be had by a small number of minds coming together to design the

systems architecture.

Slide 20:

Documenting and Communicating the Architecture For the architecture to be effective as the

backbone of the projects design, it must be communicated clearly and unambiguously to all of the

stakeholders.

Developers must understand the work assignments that the architecture requires of them, testers

must understand the task structure that the architecture imposes on them, management must

understand the scheduling implications it contains, and so forth.

Toward this end, the architectures documentation should be informative, unambiguous, and

readable by many people with varied backgrounds.

Architectural documentation should also be minimal and aimed at the stakeholders who will use it.

Slide 21:

Analyzing or Evaluating the Architecture In any design process there will be multiple candidate
designs considered. Some will be rejected immediately.

Choosing among these competing designs in a rational way is one of the architects greatest

challenges.

Analysis techniques to evaluate the quality attributes that an architecture imparts to a system have

become much more widespread in the past decade.

Scenario-based techniques provide one of the most general and effective approaches for evaluating

an architecture.

Slide 22:

Implementing and Testing the System Based on the Architecture Having an explicit and

well-communicated architecture is the first step toward ensuring architectural conformance.

Having an environment or infrastructure that actively assists developers in creating and maintaining

the architecture (as opposed to just the code) is better.

Slide 23:

Ensuring That the Implementation Conforms to the Architecture Finally, when an architecture is

created and used, it goes into a maintenance phase.

Vigilance is required to ensure that the actual architecture and its representation remain faithful to

each other during this phase.

And when they do get significantly out of sync, effort must be expended to either fix the

implementation or update the architectural documentation.

Slide 24:

There are many reasons why developers might not be faithful to the architecture:

It might not have been properly documented and disseminated.

It might be too confusing.

It might be that the architect has not built ground-level support for the architecture (particularly if it
presents a different way of doing business than the developers are used to), and so the developers

resist it.

Or the developers may sincerely want to implement the architecture but, being human, they

occasionally slip up. Implementing and Testing the System Based on the Architecture

Slide 25:

3.3 Architecture in a Business Context Architectures and systems serves some business purposes,

although as mentioned before, these purposes may change over time.

Architectures and Business Goals

Systems are created to satisfy the business goals of one or more organizations.

Development organizations want to make a profit, or capture market, or stay in business, or help

their customers do their jobs better, or keep their staff gainfully employed, or make their

stockholders happy, or a little bit of each.

Customers have their own goals for acquiring a system, usually involving some aspect of making

their lives easier or more productive.

Other organizations involved in a projects life cycle, such as subcontractors or government

regulatory agencies, have their own goals dealing with the system

Slide 26:

Architectures and Business Goals Architects need to understand who the vested organizations are

and what their goals are.

Some business goals may lead to quality attribute requirements (which lead to architectures), or
lead directly to architectural decisions, or lead to non architectural solutions.

Slide 27:

Architectures and the Development Organization A development organization contributes many of

the business goals that influence an architecture

The organizational structure can shape the software architecture, and vice versa.

Organizations are often organized around technology and application concepts: a database group, a

networking group, a business rules team, a user-interface group.

So the explicit identification of a distinct subsystem in the architecture will frequently lead to the

creation of a group with the name of the subsystem.

Slide 28:

Architecture in a Professional Context To be an effective architect, then, you will need diplomatic,

negotiation, and communication skills.

Duties, skills, and knowledge form a triad on which architecture competence rests.

You will need to be involved in supporting management and dealing with customers.

You will need to manage a diverse workload and be able to switch contexts frequently.

You will need to know business considerations.

You will need to be a leader in the eyes of developers and management.

Slide 29:

Architects Background and Experience Architectural choices may also come from your education

and training,

exposure to successful architectural patterns, or

exposure to systems that have worked particularly poorly or particularly well.

It may mean that you will take training courses in interesting new technologies.

It may mean that you will invest in exploratory projects, to test the water of a new technology.
Slide 30:

Stakeholders A stakeholder is anyone who has a stake in the success of the system: the customer,

the end users, the developers, the project manager, the maintainers, and even those who market

the system.

Early engagement of stakeholders allows you to understand the constraints of the task, manage

expectations, negotiate priorities, and make tradeoffs.

Having an acceptable system involves appropriate performance, reliability, availability, platform

compatibility, memory utilization, network usage, security, modifiability, usability, and interoperability

with other systems as well as behavior.

Slide 31:

Influence of stakeholders on the architect

Slide 32:

Therefore, one of the best pieces of advice we can give to architects is this: Know your

stakeholders. Talk to them, engage them, listen to them, and put yourself in their shoes.

Stakeholders

Slide 33:

Stakeholders for a system and their interest

Slide 34:

Stakeholders for a system and their interest

Slide 35:

How Is Architecture Influenced? The existence of an architecture affects the technical, project,

business, and professional contexts that subsequently influence future architectures.

giving the customer the opportunity to receive a system (based on the same architecture) in a more

reliable, timely, and economical manner than if the subsequent system were to be built from scratch,

and typically with fewer defects.

Slide 36:

Project context. The architecture affects the structure of the developing organization.

Teams are formed for individual software units; and the development, test, and integration activities

all revolve around the units.

Likewise, schedules and budgets allocate resources in chunks corresponding to the units. How Is

Architecture Influenced?

Slide 37:

Business context. The architecture can affect the business goals of the developing organization.

The architecture can provide opportunities for the efficient production and deployment of similar

systems, and the organization may adjust its goals to take advantage of its newfound expertise to

plumb the market.

This is feedback from the system to the developing organization and the systems it builds. How Is

Architecture Influenced?

Slide 38:

Professional context. The process of system building will affect the architects experience with

subsequent systems by adding to the corporate experience base.

A system that was successfully built around a particular technical approach will make the architect

more inclined to build systems using the same approach in the future.

On the other hand, architectures that fail are less likely to be chosen for future projects How Is

Architecture Influenced?
Slide 39:

Architecture Influence Cycle

This chapter discusses the multifaceted context of software architecture. It explains how architecture

affects technical attributes, the software development life cycle, business goals, and the role of

professional architects. Technical context highlights how architecture enables or hinders qualities

like performance, usability, and testability. Life-cycle context explores models such as waterfall,

iterative, agile, and model-driven development. Business context stresses how architecture aligns

with organizational goals. Professional context emphasizes the need for architects to engage with

stakeholders and maintain architectural integrity. Finally, architecture is both influenced by and

influences technical, project, business, and professional domains.