SOF 204 – Software
Architecture and Design
Patterns
Chapter 3:The many contexts of
software architecture
Instructor: Tee Sim Hui
Prepared by SH Tee 1
Overview of this chapter
This chapter introduces many contexts in which a software architecture
functions.
Prepared by SH Tee 2
Architecture in a technical context
Software architecture cannot exist outside of any context.
Context defines the use, purposes, and objectives of a software architecture.
In a technical context, an architecture enables or inhibits the achievement of
various quality attributes (e.g., accuracy, reliability, extensibility,
modifiability, fault-tolerance, etc)
In a technical context, architecture is used to predict a system’s qualities.
For example, how reliable a system is when the concurrent access to the
system exceeds specified number.
Different software or hardware components have different performance
threshold and constraints.
3
Prepared by SH Tee
An architecture is used (from the technical perspective) to optimize the
interoperability of various software and hardware components.
An architecture is used to strike a balance between the performance and
features of various software and hardware components.
An architecture can be used to minimize potential risk of interoperation
failure among software and hardware components.
An architecture enables technical reasoning about the system, and facilitates
technical changes.
Many concerns need to be addressed by a software architecture from the
technical perspective. E.g., to achieve system’s availability, software
architect has to be concerned about how the system would have responded to
a fault.
Prepared by SH Tee 4
Other technical concerns:
usability—a concern about isolating the GUI and the aspects of user experience
from the technical implementation (e.g., the end user should not get involved in
programming, or complicated database operations, etc).
Testability—a concern about the testability of individual elements (these elements
are controllable and unfailing).
Safety—a concern about the acceptable behavioural patterns of software
components.
Interoperability—a concern about the interdependency between the software and
hardware components in performing a task.
Reliability—a concern about high degree of failure-free operations.
Prepared by SH Tee 5
An architecture is influenced by its technical environment, which includes
standard industry practice and software engineering techniques.
Some important elements or trends adopted in current technical environment
are web-based systems, cloud computing, object-oriented paradigm, and
service-oriented framework.
It is important that a software system is designed to be inline with the
current technical trend, if not leading the trend.
It is costly and unwise if a software architecture is designed against the
prevalent practices adopted in the technical environment.
Technical environment tends to be global rather than local.
Prepared by SH Tee 6
Architecture in a project life-cycle
context
Software project life-cycle involves standard processes in developing and
maintaining a software system.
A project life-cycle exhibits the stages of a software system, and allows the
software team to understand the current status of a system and what to do
next.
There are four dominant software development processes:
The waterfall model—this model organizes the project life-cycle into a series of
connected activities, beginning with requirement specification or analysis,
followed by design, implementation, integration, testing, installation, and
maintenance. Feedback paths from a later stage to an earlier one allowed for
revision when the need arises.
Prepared by SH Tee 7
Iterative model—this model captures the feedback paths in the waterfall model as
a series of short cycles through stages (e.g., multiple iteration between the design
and implementation stage)
Agile model—this model defines the project life-cycles in an incremental and
iterative manner. This model emphasizes on team work and adaptability (viz.,
capable of adapting to changing circumstances. E.g, change of data requirement)
Model-driven development process—this model emphasizes the creation of a
platform-independent model from which program codes can be automatically
generated.
Prepared by SH Tee 8
Changing from one development process to another in the middle of a
software project requires the architect to integrate the relevant information
from the old process to the new one. This could be a daunting task.
Prepared by SH Tee 9
Regardless of which software development processes being used, the follow
activities are required in creating a software architecture:
(i) making a business case for the system
(ii) understanding the architecturally significant requirements
(iii) creating, reusing, or selecting the architecture
(iv) documenting and communicating the architecture
(v) analysing or evaluating the architecture
(vi) implementing and testing the system based on the architecture.
(vii) maintaining consistency between the implementation and the architecture.
Prepared by SH Tee 10
Architecture in a business context
A software architecture must serve business purposes.
An architecture must be inline with the business goals.
Many business goals will be manifested as quality attribute requirements
(e.g., secured online payment, fast system response time, etc)
However, some business goals will not be reflected as quality attribute
requirements. (e.g., if the goal of a business is to minimize operating cost,
putting up additional databases may works against the business goal)
Some business goals will have no effect on the architectural design. For
example, a business goal to lower costs can be achieved by cutting
unnecessary expenses.
Prepared by SH Tee 11
Architecture in a professional context
Architects need more than technical skills. Other skills are soft skills such as
communication skills and negotiation skills.
Architects work from both technical and business perspectives.
An architect will need to address various issues and concerns, some of which
are beyond technical scopes.
Architects are required to equip with updated knowledge about the macro
aspects of various software and hardware components, such as knowledge
about architectural patterns, database platforms, and web services
standards.
For example, an architect needs to familiarize with web standards defined in
web architectures. See [Link]
Prepared by SH Tee 12
Web protocols defined by the World Wide Web Consortium (W3C) for a web
architecture include HTTP and SOAP.
To be professional, a software architect working on web architecture has to
know about the latest specification status of identifiers (e.g. URI and web
services addressing) and all web standards.
The latest status of web standards is available at W3C’s official website
[Link]
Apart from the professional technical knowledge, an architect always need to
be involved in supporting management and dealing with customers.
Prepared by SH Tee 13
Influences of stakeholders on the
architect
A stakeholder is the person who has a stake in the success of the system—the
customers, the end-users, the developers, the manager, the programmer, etc.
Different stakeholders have different concerns that they wish the system to deliver.
The architect needs to know and understand the nature of these different concerns,
and the constraints in addressing them.
The architect manage expectations, negotiate priorities and make tradeoffs when
dealing with stakeholders.
Some of the concerns from stakeholders could be contradictory.
Can you think of any example of contradictory concerns?
Having an acceptable system to the stakeholders implies that there is an acceptable
level of attribute quality achieved by the system.
Prepared by SH Tee 14
Additional resources
Architecture in the context of codes: [Link]
v=0fSRadBepYk
A talk on a modern application architecture:
[Link]
Prepared by SH Tee 15
Case study: Java Enterprise System’s
solution life-cycle
Source:
[Link]
Prepared by SH Tee 16