The architecture of a system describes its major components, their relationships

(structures), and how they interact with each other. Software architecture and
design includes several contributory factors such as Business strategy, quality
attributes, human dynamics, design, and IT environment.
Software Architecture Types

We can segregate Software Architecture and Design into two distinct phases:
Software Architecture and Software Design. In Architecture, nonfunctional decisions
are cast and separated by the functional requirements. In Design, functional
requirements are accomplished.
Software Architecture

Architecture serves as a blueprint for a system. It provides an abstraction to

manage the system complexity and establish a communication and coordination
mechanism among components.

It defines a structured solution to meet all the technical and operational

requirements, while optimizing the common quality attributes like performance and
security.

Further, it involves a set of significant decisions about the organization

related to software development and each of these decisions can have a considerable
impact on quality, maintainability, performance, and the overall success of the
final product. These decisions comprise of −

Selection of structural elements and their interfaces by which the system

is composed.

Behavior as specified in collaborations among those elements.

Composition of these structural and behavioral elements into large

subsystem.

Architectural decisions align with business objectives.

Architectural styles guide the organization.

Software Design

Software design provides a design plan that describes the elements of a system, how
they fit, and work together to fulfill the requirement of the system. The
objectives of having a design plan are as follows −

To negotiate system requirements, and to set expectations with customers,

marketing, and management personnel.

Act as a blueprint during the development process.

Guide the implementation tasks, including detailed design, coding, integration,

and testing.

It comes before the detailed design, coding, integration, and testing and after the
domain analysis, requirements analysis, and risk analysis.
Software Design
Goals of Architecture

The primary goal of the architecture is to identify requirements that affect the
structure of the application. A well-laid architecture reduces the business risks
associated with building a technical solution and builds a bridge between business
and technical requirements.

Some of the other goals are as follows −

Expose the structure of the system, but hide its implementation details.

Realize all the use-cases and scenarios.

Try to address the requirements of various stakeholders.

Handle both functional and quality requirements.

Reduce the goal of ownership and improve the organization’s market position.

Improve quality and functionality offered by the system.

Improve external confidence in either the organization or system.

Limitations

Software architecture is still an emerging discipline within software engineering.

It has the following limitations −

Lack of tools and standardized ways to represent architecture.

Lack of analysis methods to predict whether architecture will result in an

implementation that meets the requirements.

Lack of awareness of the importance of architectural design to software

development.

Lack of understanding of the role of software architect and poor communication

among stakeholders.

Lack of understanding of the design process, design experience and evaluation

of design.

Role of Software Architect

A Software Architect provides a solution that the technical team can create and
design for the entire application. A software architect should have expertise in
the following areas −
Design Expertise

Expert in software design, including diverse methods and approaches such as

object-oriented design, event-driven design, etc.

Lead the development team and coordinate the development efforts for the
integrity of the design.

Should be able to review design proposals and tradeoff among themselves.

Domain Expertise

Expert on the system being developed and plan for software evolution.

Assist in the requirement investigation process, assuring completeness and

consistency.
 Coordinate the definition of domain model for the system being developed.

Technology Expertise

Expert on available technologies that helps in the implementation of the

system.

Coordinate the selection of programming language, framework, platforms,

databases, etc.

Methodological Expertise

Expert on software development methodologies that may be adopted during SDLC

(Software Development Life Cycle).

Choose the appropriate approaches for development that helps the entire team.

Hidden Role of Software Architect

Facilitates the technical work among team members and reinforcing the trust
relationship in the team.

Information specialist who shares knowledge and has vast experience.

Protect the team members from external forces that would distract them and
bring less value to the project.

Deliverables of the Architect

A clear, complete, consistent, and achievable set of functional goals

A functional description of the system, with at least two layers of

decomposition

A concept for the system

A design in the form of the system, with at least two layers of decomposition

A notion of the timing, operator attributes, and the implementation and

operation plans

A document or process which ensures functional decomposition is followed, and

the form of interfaces is controlled

Quality Attributes

Quality is a measure of excellence or the state of being free from deficiencies or

defects. Quality attributes are the system properties that are separate from the
functionality of the system.

Implementing quality attributes makes it easier to differentiate a good system from

a bad one. Attributes are overall factors that affect runtime behavior, system
design, and user experience.

They can be classified as −

Static Quality Attributes

Reflect the structure of a system and organization, directly related to

architecture, design, and source code. They are invisible to end-user, but affect
the development and maintenance cost, e.g.: modularity, testability,
maintainability, etc.
Dynamic Quality Attributes

Reflect the behavior of the system during its execution. They are directly related
to system’s architecture, design, source code, configuration, deployment
parameters, environment, and platform.

They are visible to the end-user and exist at runtime, e.g. throughput, robustness,
scalability, etc.
Quality Scenarios

Quality scenarios specify how to prevent a fault from becoming a failure. They can
be divided into six parts based on their attribute specifications −

Source − An internal or external entity such as people, hardware, software, or

physical infrastructure that generate the stimulus.

Stimulus − A condition that needs to be considered when it arrives on a system.

Environment − The stimulus occurs within certain conditions.

Artifact − A whole system or some part of it such as processors, communication

channels, persistent storage, processes etc.

Response − An activity undertaken after the arrival of stimulus such as detect

faults, recover from fault, disable event source etc.

Response measure − Should measure the occurred responses so that the

requirements can be tested.

Common Quality Attributes

The following table lists the common quality attributes a software architecture
must have −
Category Quality Attribute Description
Design Qualities Conceptual Integrity Defines the consistency and coherence of
the overall design. This includes the way components or modules are designed.
Maintainability Ability of the system to undergo changes with a degree of ease.
Reusability Defines the capability for components and subsystems to be
suitable for use in other applications.
Run-time Qualities Interoperability Ability of a system or different systems
to operate successfully by communicating and exchanging information with other
external systems written and run by external parties.
Manageability Defines how easy it is for system administrators to manage the
application.
Reliability Ability of a system to remain operational over time.
Scalability Ability of a system to either handle the load increase without
impacting the performance of the system or the ability to be readily enlarged.
Security Capability of a system to prevent malicious or accidental actions
outside of the designed usages.
Performance Indication of the responsiveness of a system to execute any
action within a given time interval.
Availability Defines the proportion of time that the system is functional and
working. It can be measured as a percentage of the total system downtime over a
predefined period.
System Qualities Supportability Ability of the system to provide information
helpful for identifying and resolving issues when it fails to work correctly.
Testability Measure of how easy it is to create test criteria for the system
and its components.
User Qualities Usability Defines how well the application meets the
requirements of the user and consumer by being intuitive.
Architecture Quality Correctness Accountability for satisfying all the
requirements of the system.
Non-runtime Quality Portability Ability of the system to run under
different computing environment.
Integrality Ability to make separately developed components of the system
work correctly together.
Modifiability Ease with which each software system can accommodate changes to
its software.
Business quality attributes Cost and schedule Cost of the system with
respect to time to market, expected project lifetime & utilization of legacy.
Marketability