Content

Architecture business cycle –Architectural patterns –Reference

model
 The software architecture of a program or computing
system is the structure or structures of the system,
which comprise software elements, the externally
visible properties of those elements and the
relationships among them.
 Software architecture is a result of technical, business
and social influences. Its existence in turn affects the
technical, business and social environments that
subsequently influence future architectures. We call
this cycle of influences, from environment to the
architecture and back to the environment, the
Architecture Business Cycle (ABC).
 An architecture is the result of a set of business and
technical decisions. There are many influences at work
in its design, and the realization of these influences will
change depending on the environment in which the
architecture is required to perform.

 Even with the same requirements, hardware, support

software, and human resources available, an architect
designing a system today is likely to design a different
system than might have been designed five years ago.
 Many people and organizations interested in the
construction of a software system are referred to as
stakeholders. E.g. customers, end users, developers,
project manager etc.

 Figure in next slide shows the architect receiving

helpful stakeholder “suggestions”.
 Having an acceptable system involves properties such
as performance, reliability, availability, platform
compatibility, memory utilization, network usage,
security, modifiability, usability and interoperability
with other systems as well as behavior.
 Each stakeholder has different concerns and goals,

some of which may be contradictory.

 The reality is that the architect often has to fill in the

blanks and mediate the conflicts.

 Architecture is influenced by the structure or nature of
the development organization.
 There are three classes of influence that come from the

developing organizations: immediate business, long-

term business and organizational structure.
 An organization may have an immediate business

investment in certain assets, such as existing

architectures and the products based on them.
 An organization may wish to make a long-term
business investment in an infrastructure to pursue
strategic goals and may review the proposed system as
one means of financing and extending that
infrastructure.

 The organizational structure can shape the software

architecture.
 If the architects for a system have had good results
using a particular architectural approach, such as
distributed objects or implicit invocation, chances are
that they will try that same approach on a new
development effort.

 Conversely, if their prior experience with this approach

was disastrous, the architects may be reluctant to try it
again.
 Architectural choices may also come from an
architect’s education and training, exposure to
successful architectural patterns or exposure to systems
that have worked particularly poorly or particularly
well.

 The architects may also wish to experiment with an

architectural pattern or technique learned from a book
or a course
 A special case of the architect’s background and
experience is reflected by the technical environment.

 The environment that is current when an architecture is

designed will influence that architecture.

 It might include standard industry practices or software

engineering prevalent in the architect’s professional
community.
 Influences on an architecture come from a wide variety
of sources. Some are only implied, while others are
explicitly in conflict.

 Architects need to know and understand the nature,

source, and priority of constraints on the project as
early as possible.

 Therefore, they must identify and actively engage the

stakeholders to solicit their needs and expectations.
 Architects are influenced by the requirements for the
product as derived from its stakeholders, the structure
and goals of the developing organization, the available
technical environment and their own background and
experience.
 Relationships among business goals, product
requirements, architects experience, architectures and
fielded systems form a cycle with feedback loops that a
business can manage.
 A business manages this cycle to handle growth, to

expand its enterprise area, and to take advantage of

previous investments in architecture and system
building.
 The architecture affects the structure of the developing
organization.
 An architecture prescribes a structure for a system it
particularly prescribes the units of software that must be
implemented and integrated to form the system.
 Teams are formed for individual software units; and the
development, test, and integration activities around the units.
Likewise, schedules and budgets allocate resources in chunks
corresponding to the units.
 Teams become embedded in the organization’s structure. This
is feedback from the architecture to the developing
organization.
 The architecture can affect the goals of the
developing organization.
 A successful system built from it can enable a

company to establish a foothold in a particular market

area. The architecture can provide opportunities for
the efficient production and deployment of the
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.

 The architecture can affect customer requirements for
the next system by giving the customer the opportunity
to receive a system in a more reliable, timely and
economical manner than if the subsequent system were
to be built from scratch.
 The process of system building will affect the

architect’s experience with subsequent systems by

adding to the corporate experience base.
 A few systems will influence and actually change the

software engineering culture. i.e, The technical

environment in which system builders operate and
learn.
 Software process is the term given to the organization,
ritualization, and management of software development
activities. The various activities involved in creating
software architecture are:
1.Creating the business case for the system
 It is an important step in creating and constraining any

future requirements.
 How much should the product cost?
 What is its targeted market?
 What is its targeted time to market?
 Will it need to interface with other systems?
 Are there system limitations that it must work within?
 These are all the questions that must involve the

system’s architects.
 They cannot be decided solely by an architect, but if an

architect is not consulted in the creation of the business

case, it may be impossible to achieve the business
goals.
 There are a variety of techniques for eliciting
requirements from the stakeholders.
For ex:
 Object oriented analysis uses scenarios, or “use cases”

to embody requirements.
 Safety-critical systems use more rigorous approaches,

such as finite-state-machine models or formal

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

 Regardless of the technique used to elicit the

requirements, the desired qualities of the system to be
constructed determine the shape of its structure.
 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
system's architecture.
 For the architecture to be effective as the backbone of
the project’s design, it must be communicated clearly
and unambiguously to all of the stakeholders.
 Developers must understand the work assignments it

requires of them, testers must understand the task

structure it imposes on them, management must
understand the scheduling implications it suggests, and
so forth.
Choosing among multiple competing designs in a
rational way is one of the architect’s greatest
challenges.
 Evaluating an architecture for the qualities that it

supports is essential to ensuring that the system

constructed from that architecture satisfies its
stakeholders needs.
 Use scenario-based techniques or architecture tradeoff

analysis method (ATAM) or cost benefit analysis

method (CBAM).
 This activity is concerned with keeping the developers
faithful to the structures and interaction protocols
constrained by the architecture.

 Having an explicit and well-communicated

architecture is the first step toward ensuring
architectural conformance.
 Finally, when an architecture is created and used, it
goes into a maintenance phase.

 Constant vigilance is required to ensure that the actual

architecture and its representation remain to each other
during this phase.
 Given the same technical requirements for a system,
two different architects in different organizations will
produce different architectures, how can we determine
if either one of them is the right one?
 We divide our observations into two clusters: process

recommendations and product (or structural)

recommendations.
 The architecture should be the product of a single
architect or a small group of architects with an
identified leader.

 The architect (or architecture team) should have the

functional requirements for the system and an
articulated, prioritized list of quality attributes that the
architecture is expected to satisfy.
 The architecture should be well documented, with at
least one static view and one dynamic view, using an
agreed-on notation that all stakeholders can understand
with a minimum of effort.

 The architecture should be circulated to the system’s

stakeholders, who should be actively involved in its
review.

 The architecture should be analyzed for applicable

quantitative measures (such as maximum throughput)
and formally evaluated for quality attributes before it is
too late to make changes to it.
 The architecture should lend itself to incremental
implementation via the creation of a “skeletal” system
in which the communication paths are exercised but
which at first has minimal functionality.

 This skeletal system can then be used to “grow” the

system incrementally, easing the integration and testing
efforts.

 The architecture should result in a specific (and small)

set of resource contention areas, the resolution of
which is clearly specified, circulated and maintained.
 The architecture should feature well-defined modules
whose functional responsibilities are allocated on the
principles of information hiding and separation of
concerns.
 Each module should have a well-defined interface that

encapsulates or “hides” changeable aspects from other

software that uses its facilities. These interfaces should
allow their respective development teams to work
largely independent of each other.
 Quality attributes should be achieved using well-known
architectural tactics specific to each attribute.

 The architecture should never depend on a particular

version of a commercial product or tool.

 Modules that produce data should be separate from

modules that consume data. This tends to increase
modifiability.
 For parallel processing systems, the architecture
should feature well-defined processors or tasks that do
not necessarily mirror the module decomposition
structure.
 Every task or process should be written so that its

assignment to a specific processor can be easily

changed, perhaps even at runtime.
 The architecture should feature a small number of

simple interaction patterns.