This presentation covers the IEEE 1471/4210 Architecture Standard for the Software Intensive System. Following areas such as Stakeholders and their concerns, Architecture Description and System Qualities Attributes were mainly addressed. The audience consisted of Development leads, developers & testers. Hope other disciplines such as Architects and Business Analysts will find it useful as well.

1. 1IEEE 1471
SOFTWARE ARCHITECTURE STANDARD
Recommended Practice for Architecture Description of Software-
Intensive Systems
JUN 2017

2. 22
2
INTRODUCTION
What IEEE 1471 is about and why it is vitally important to follow this standard?
When you need to apply this standard and when it is not recommended?
What is a history behind the IEEE 1471 and it’s future development roadmap?
Is IEEE 1471 is only one choice or there are alternatives?

3. 33
3
KEY FACTS
IEEE 1471 was developed by the IEEE Architecture
Working Group under the sponsorship of the IEEE
Software Engineering Standards Committee. In
September 2000, the IEEE Standards Board approved
IEEE 1471 for use.

4. 44
4
STAKEHOLDERS AND CONCERNS
Stakeholder Description Concern
Acquirer
Project sponsor, the person who invest personal
money or external resources to the project
development.
Strategic alignment, return on
investment, costs, timescales and plans
Assessor
Oversee the system’s conformance to standards and
legal regulation, check for compliance (for example
internal/external audit).
Testing and compliance to industry
standards
Communicators
Explain the system to other stakeholders via its
documentation and training materials
Understanding benefits, rationale,
motivation and implications
Developer
Construct and deploy the system from specifications
(or lead the teams that do this)
Specification, designing, building and
testing the system
Maintainer
Manage the evolution of the system once it is
operational
Development documentation,
instrumentation, debug capabilities,
change management
STAKEHOLDER: is a person, group, or entity with an interest in or concerns about the realization of the product.

5. 55
5
STAKEHOLDERS AND CONCERNS
Stakeholder Description Concern
Production Engineer
Design, deploy and manage the hardware and
software environments in which the system
will be built, tested and run
Operational & support documentation,
system monitoring, backup & restore
plan
Suppliers
Build and/or supply the hardware, software, or
infrastructure on which the system will run
Commercial and licensing issues,
successful deployment of their products
Support Staff
Provide support to users for the product or
system when it is running
User and troubleshoot guide, training,
usability
System
Administrators
The person who keeps system running, as
well as provides IT Infrastructure support
System monitoring and management,
business continuity, availability and
resilience, scalability
Tester
Test the system to ensure that it is suitable for
use
Establishing requirements, defining tests,
test coverage, test harnesses
Users
Define the system’s functionality and ultimately
make use of it
Scope, functionality, ease of use

6. 6
6
ARCHITECTURE DESCRIPTION (AD)
An ARCHITECTURAL DESCRIPTION (AD) is a set of products that documents an architecture in a way its
stakeholders can understand and demonstrates that the architecture has met their concerns
Assessor
Deployment
View
Functional
View
Development
View
Operational
View
Concurrency
View
Acquirer
Communicators
Developer
Maintainer
Suppliers
System
Administrators
Tester
Users
Information
View
Architecture
Description
Solution
•identifying the stakeholders of the system
and their concerns;
•choosing and defining viewpoints that
frame, or cover, those concerns;
•documenting the views of the architecture,
such that each satisfies one of those
viewpoints;
•linking together those views with
correspondences and recording any known
inconsistencies between views; and
•providing rationale for key decisions made
in the AD.

7. 7
7
VIEWPOINT CATALOG

8. 8
8
VIEWPOINT CATALOG
Functional Describes the system’s functional elements, their responsibilities, interfaces, and primary interactions. A
Functional view is the cornerstone of most ADs and is often the first part of the description that stakeholders
try to read. It drives the shape of other system structures such as the information structure, concurrency
structure, deployment structure, and so on. It also has a significant impact on the system’s quality properties
such as its ability to change, its ability to be secured, and its runtime performance.
Informational Describes the way that the architecture stores, manipulates, manages, and distributes information. The
ultimate purpose of virtually any computer system is to manipulate information in some form, and this
viewpoint develops a complete but high-level view of static data structure and information flow. The objective
of this analysis is to answer the big questions around content, structure, ownership, latency, references, and
data migration.
Concurrency Describes the concurrency structure of the system and maps functional elements to concurrency units to
clearly identify the parts of the system that can execute concurrently and how this is coordinated and
controlled. This entails the creation of models that show the process and thread structures that the system
will use and the interprocess communication mechanisms used to coordinate their operation.

9. 9
9
VIEWPOINT CATALOG
Development Describes the architecture that supports the software development process. Development views
communicate the aspects of the architecture of interest to those stakeholders involved in building, testing,
maintaining, and enhancing the system.
Deployment Describes the environment into which the system will be deployed, including capturing the dependencies the
system has on its runtime environment. This view captures the hardware environment that your system
needs (primarily the processing nodes, network interconnections, and disk storage facilities required), the
technical environment requirements for each element, and the mapping of the software elements to the
runtime environment that will execute them.
Operational Describes how the system will be operated, administered, and supported when it is running in its production
environment. For all but the simplest systems, installing, managing, and operating the system is a significant
task that must be considered and planned at design time. The aim of the Operational viewpoint is to identify
system-wide strategies for addressing the operational concerns of the system’s stakeholders and to identify
solutions that address these

10. 10
10
VIEWPOINT CATALOG: FUNCTIONAL
CONCERNS

11. 11
11
VIEW CATALOG: FUNCTIONAL
The functional view of the system defines the system’s architecturally significant functional elements, the
responsibilities of each, the interfaces they offer and the dependencies between elements
Definition Describes the system’s runtime functional elements and their responsibilities,
interfaces, and primary interactions
Concerns Functional capabilities, external interfaces, internal structure, and design philosophy
Models Functional structure model
Problems and
Pitfalls
Poorly defined interfaces, poorly understood responsibilities, infrastructure modeled as
functional elements, overloaded view, diagrams without element definitions, difficulty in
reconciling the needs of multiple stakeholders, inappropriate level of detail, “God
elements,” and too many dependencies
Stakeholders All stakeholders
Applicability All systems

12. 12
12
VIEWPOINT CATALOG: FUNCTIONAL
The functional model - UML Component diagram

13. 13
13
VIEWPOINT CATALOG: FUNCTIONAL: ELEMENTS
The Functional Scenario explains how the functional
elements interact, via their interfaces, in order to meet some
of the key requirements
Element Name Orders
Responsibilities Manage Orders
Interfaces-Inbound REST
Interfaces-Outbound Flat File
The Functional Element Description define
the responsibilities and interfaces offered
and/or required by each functional element.

14. 14
14
VIEWPOINT CATALOG: INFORMATION
CONCERNS

15. 15
15
VIEWPOINT CATALOG: INFORMATION
Definition Describes the way that the architecture stores, manipulates, manages, and distributes
information
Concerns Information structure and content; information flow; data ownership; timeliness,
latency, and age; references and mappings; transaction management and recovery;
data quality; data volumes; archives and data retention; and regulation
Models Static data structure models, information flow models, information lifecycle models,
data ownership models, data quality analysis, metadata models, and volumetric
models
Problems and
Pitfalls
Data incompatibilities, poor data quality, unavoidable multiple updaters, key matching
deficiencies, poor information latency, interface complexity, and inadequate
volumetrics
Stakeholders Primarily users, acquirers, developers, and maintainers, but most stakeholders have
some level of interest
Applicability Any system that has more than trivial information management needs

16. 16
16
VIEWPOINT CATALOG: INFORMATION
Data Structure Data Flow Information Lifecycle

17. 17
17
VIEWPOINT CATALOG: CONCURRENCY
Definition Describes the concurrency structure of the system, mapping functional elements to
concurrency units to clearly identify the parts of the system that can execute
concurrently, and shows how this is coordinated and controlled
Concerns Task structure, mapping of functional elements to tasks, interprocess communication,
state management, synchronization and integrity, startup and shutdown, task failure,
and reentrancy
Models System-level concurrency models and state models
Problems and
Pitfalls
Modeling of the wrong concurrency, excessive complexity, resource contention,
deadlock, and race conditions
Stakeholders Developers, testers, and some administrators
Applicability All information systems with a number of concurrent threads of execution

18. 18
18
VIEWPOINT CATALOG: CONCURRENCY

19. 19
19
VIEWPOINT CATALOG: CONCURRENCY5WERTY
Concurrency Model: defines processes, process groups and threads,
and the interposes communication channels between them.
State Model: defines the states that the systems runtime elements
can be in, the transitions between those states and the events which
drive those transitions..

20. 20
20
VIEWPOINT CATALOG: DEPLOYMENT
Definition Describes the environment into which the system will be deployed, including the
dependencies the system has on its runtime environment
Concerns Types of hardware required, specification and quantity of hardware required, third-
party software requirements, technology compatibility, network requirements, network
capacity required, and physical constraints
Models Runtime platform models, network models, and technology dependency models
Problems and
Pitfalls
Unclear or inaccurate dependencies, unproven technology, lack of specialist technical
knowledge, and late consideration of the deployment environment
Stakeholders System administrators, developers, testers, communicators, and assessors
Applicability Systems with complex or unfamiliar deployment environments

21. 21
21
VIEWPOINT CATALOG: DEPLOYMENT
Deployment View includes the details of the processing nodes that the
system requires for its installation (i.e. its runtime platform), the software
dependencies on each node (such as required libraries) and details of the
underlying network that the system will require.
Network Model defines
details of the network
configuration, in case of
complex and distributed
system

22. 22
22
VIEWPOINT CATALOG: DEVELOPMENT
Definition Describes the architecture that supports the software development process
Concerns Module organization, common processing, standardization of design, standardization
of testing, instrumentation, and codeline organization
Models Module structure models, common design models, and codeline models
Problems and
Pitfalls
Too much detail, overburdening the AD, uneven focus, lack of developer focus, lack of
precision, and problems with the specified environment
Stakeholders Software developers and testers
Applicability All systems with significant software development involved in their creation

23. 23
23
VIEWPOINT CATALOG: DEVELOPMENT

24. 24
24
VIEWPOINT CATALOG: DEVELOPMENT
Package Diagram SDLC

25. 25
25
VIEWPOINT CATALOG: OPERATIONAL

26. 26
26
VIEWPOINT CATALOG: OPERATIONAL
Definition Describes how the system will be operated, administered, and supported when it is
running in its production environment
Concerns Installation and upgrade, functional migration, data migration, operational monitoring
and control, configuration management, performance monitoring, support, and backup
and restore
Models Installation models, migration models, configuration management models,
administration models, and support models
Problems and
Pitfalls
Lack of engagement with the operational staff, lack of backout planning, lack of
migration planning, insufficient migration window, missing management tools, lack of
integration into the production environment, and inadequate backup models
Stakeholders System administrators, developers, testers, communicators, and assessors
Applicability Any system being deployed into a complex or critical operational environment

27. 27
27
SYSTEM QUALITIES

28. 2828
28
REFERENCES
www.viewpoints-and-perspectives.info Nick Rozanski & Eoin Woods site, dedicated to the book “Software
System Architecture. Working with Stakeholders using Viewpoints
and Perspectives”
www.iso-architecture.org/ieee-1471 The web recourse, dedicated for the IEEE 1471 standard.
Book: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd
Edition) 2nd Edition
www.iso-architecture.org/ieee-1471/templates/

29. 29
+373-79770257
VICTOR CONOVALOV
Victor.Conovalov@Endava.com
SOFTWARE ARCHITECT