This document provides an overview of the Agile Software Architecture course offered by NISI in 2017. The course consists of 8 sessions covering topics like agile architecture, architectural decision making, quality attributes, feedback and monitoring, and architecture evolution. It is taught by professors from Utrecht University and industry architects. The goal is to help architects think more strategically and discuss real-world cases. Participants come from various roles and companies in consulting, transportation, ERP, public sector and healthcare. They hope to improve their skills and address challenges regarding privacy, security and agility. More information can be found on the course website or by contacting the lead instructor, Slinger Jansen.

1. Agile Software Architecture Course 2017-1
Slinger Jansen
Sjaak Brinkkemper
Jan Vlietland
Garm Lucassen

2. NISI
• Course is part of the Netherlands Institute for theSoftware
Industry
• NISI is a spin-off of Utrecht University
• Mission: “make (scientific) knowledge useful for practice, to
advance the software industry, by means of courses and
consultancy”
• With the results we fund new scientific research

3. NISI Core Team

4. Course Team
• Prof. dr. Sjaak Brinkkemper, Utrecht University
• Dr. Jan Martijn van der Werf, Utrecht University
• Dr. Slinger Jansen, Utrecht University
• Drs. Michiel Overeem, Senior Architect, AFAS Software
• Drs. Martijn Cox, Senior Architect, ARS
• Dr. Jan Vlietland, Director, NISI
• Drs. Garm Lucassen, PhD Student, lecturer

5. Who am I?
Dr. Slinger Jansen, assistant professor, Utrecht
University, the Netherlands
Author of several books
Acquired funding in excess of 2mln euro
Software ecosystems “expert”

6. Goal of the Course
• Promoting thinking from junior architects to senior architects
through
– State of the Art education resources
– Practical cases (AFAS, Netflix, Chrome, etc.)
– Discussion of current architecture
– Exchange of experiences and ideas

7. Program: Session 1
Agile Architecture
• Management decisions
• Software product management and architecture
• Agility in Architecture Design
• Runtime monitoring
• Collaboration in Architecture Design
• Homework: send 2 slides introducing yourself to
slinger.jansen@uu.nl

8. Program: Session 2
Architecture as a Platform for Decision Making
• Making decisions in architecture
• Traceability of decisions
• Decision documentation
• Architecture erosion
• Architecture “smells”
• Homework: Describe three decisions made about your
architecture in three slides.
– One decision that is obvious and adopted well
– One decision that needs to be explained repeatedly
– One decision that is being ignored

9. Program Session 3:
Architecture Perspectives, Styles, and Patterns
• Modelling architecture
• Documenting architecture
• Web architectures
• Simulating architecture
• Green Software
• Homework: Send three slides to slinger.jansen@uu.nl
describing how your software could be greener.

10. Program Session 4:
Quality Attributes
• ISO-standard 9001
• Evaluation of quality attributes
• Safety, privacy, and security
• Architecture evaluation and the TIOBE index
• Architecture evaluation methods
• Homework: What are the issues you encounter regarding
privacy, safety, and security? Max 5 slides.

11. Program Session 5:
Feedback and Monitoring in Architecture
• Monitoring as architecture aspect
• Mechanisms for Feedback
• Who watches the watchmen?
• Distributed systems and Microservices
• Performance engineering
• Read the supplied architecture document. Suggest 3 possible
improvements in an email to slinger.jansen@uu.nl to the
architecture. Max 2A4.

12. Program Session 6:
Architecture Evolution
• Evolvability of an Architecture
• From technical debt to technical surplus
• Transitioning to Cloud
• Internet of Things Architectures
• Homework: How could parts of your architecture be
transitioned to the cloud? Explain in 3-5 slides and send to
slinger.jansen@uu.nl.

13. Program Session 7:
Evaluation in Practice
• How to evaluate an architecture in practice?
– Case: Chrome
– Case: Netflix
• Homework: Present your own architecture.

14. Program Session 8:
Evaluation in Practice II
• Evaluate each other’s architectures
• Exam
• Diploma ceremony

15. Preparing questions
• What is your role?
• Software development, software architecture (support) or a
business role?
• How many years of experience do you have with architecture?
• Which products are developed in your company / unit and for which
markets?
• How often would you like to release new product versions to the
market?
• How large is your company (and your unit)?
• What is your largest customer network and how big is your
network?
• Can you briefly describe the IT landscape?

16. Participants
Various roles:
• Senior Software Developer
• Junior software architect
• Senior software architect
• Technical software product manager

17. Participants
Average years of experience with architecture:
• None to little
• 1 year
• 2-5 years
• 5+ years

18. Participants
Product & Services:
• Consulting (1)
• Public Transport (2)
• Enterprise Resource Planning (4)
• Public sector (2)
• Finance (1)
• Health care (1)

19. Participants
Company size
• >1.000
• 100 – 1000
• 10 – 100

20. Participants
Used technology:

21. Participants Needs
• What is your biggest Architecture impediment?
• What do you hope to find in this course?
• As many needs as participants!

22. Today’s Program (Cont’d)
Agile Software Architecture
• What are management decisions in architecture?
• Software product management and architecture
• Agility in Architecture Design
• Openness in Architecture
• Collaboration in Architecture Design

23. ARCHITECTURE INTRODUCTION

24. Motivation for Architecture
• Software systems are rapidly and continuously growing in size and complexity
• Techniques and tools for developing and maintaining such systems typically play catch-up
• To deal with this problem, many approaches exploit abstraction
– Ignore all but the details of the system most relevant to a task (e.g., developing the user interface
or system-level testing)
– This greatly simplifies the model of the system
– Apply techniques and tools on the simplified model
– Incrementally reintroduce information to complete the “picture”
• Software architecture is such an approach
– Applicable to the task of software design

25. What is Architecture?
• A high-level model of a thing
– Describes critical aspects of the thing
– Understandable to many stakeholders
• architects, engineers, workers, managers, customers
– Allows evaluation of the thing’s properties before it is built
– Provides well understood tools and techniques for constructing the thing
from its blueprint
• Which aspects of a software system are architecturally relevant?
• How should they be represented most effectively to enable
stakeholders to understand, reason, and communicate about a system
before it is built?
• What tools and techniques are useful for implementing an architecture
in a manner that preserves its properties?

26. The architecture of a packing robot control
system

27. Architecture: Our Definition
• An abstraction for a software part (system, program, package, class) that
focuses on uses, structure, issues, and risks
• Uses: How users (people and other software) interact with a part and how the
part responds
• Structure: The collection of parts and their interactions and dependencies
• Issues: Things that developers are concerned about, like complexity for a large
system, ease of use, robustness
• Risks: Potential for unwanted results, often related to performance, safety, and
financial and security threats

28. Intent
• When we develop software, we want our software to have an
architecture developed explicitly, not accidentally.
• Its purpose is to allow us to think critically about a product we are
developing before committing to code.
• For large systems an architecture may be represented by a, possibly
large, document.
• For smaller systems and programs it may be presented on a web page
or small collection of diagrams and notes, bound together in some form
of accessible container.

29. Architecture Level
• Systems:
– We usually think of an architecture as describing some large, distributed system.
• Packages:
– But packages also have architectures: uses, users, structure, and issues.
– Package structure relates to the package’s classes and how they interact.
• Classes
– Even a class has an architecture defined by its methods, data structures,
and how they interact.

30. The organization of the Model-View-Controller
Chapter 6 Architectural design 30

31. Web application architecture using the MVC
pattern

32. What Is Software Architecture?
• The architecture of a software system captures major features and design ideas for
a software development project.
• Describes relationship of users with the system
• Describes structure and organizing principles of the system
– Major partitions within the system and their interfaces
– Responsibilities of, and resources needed by, each partition
– Design concepts: data structures, algorithms, data flows that help developers understand
and implement their piece of the system
• Identifies major threads of execution
• Identifies critical timelines and risk areas
– A timeline is a time-based budget for critical threads.
– A risk area identifies objectives and requirements that will be difficult to meet under the
current architectural and design concept or susceptibility to threats.

33. Architectural Concerns
• Goals: Main objectives of the system
• Uses: How people and other software will interact with the system
• Tasks: Activities for a system and its major partitions
• Partitions: Subsystems, packages, and classes that make up the
system; responsibilities
• Interactions: The relationships and data flows between partitions, and
assumptions that partitions have about each other
• Events: Any occurrence that affects system activities
• Views: Appearance of the system to users and its designers
• Performance: Efficient use of computer resources—processor cycles,
network bandwidth, memory

34. The software architecture of an ATM system

35. Excerpt, slides deliberately left out

36. DECISION MAKING IN ARCHITECTURE

37. Architectural design
• An early stage of the system design process.
• Represents the link between specification and design
processes.
• Often carried out in parallel with some specification activities.
• It involves identifying major system components and their
communications.

38. Architectural abstraction
• Architecture in the small is concerned with the architecture of
individual programs. At this level, we are concerned with the
way that an individual program is decomposed into
components.
• Architecture in the large is concerned with the architecture of
complex enterprise systems that include other systems,
programs, and program components. These enterprise systems
are distributed over different computers, which may be owned
and managed by different companies.

39. Advantages of explicit architecture
• Stakeholder communication
– Architecture may be used as a focus of discussion by system
stakeholders.
• System analysis
– Means that analysis of whether the system can meet its non-
functional requirements is possible.
• Large-scale reuse
– The architecture may be reusable across a range of systems
– Product-line architectures may be developed.

40. The architecture of a language processing
system
Chapter 6 Architectural design 40

41. Architectural design decisions
• Architectural design is a creative process so the process differs
depending on the type of system being developed.
• However, a number of common decisions span all design
processes and these decisions affect the non-functional
characteristics of the system.

42. Architectural design decisions
• Is there a generic application architecture that can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?

43. Architecture reuse
• Systems in the same domain often have similar architectures
that reflect domain concepts.
• Application product lines are built around a core architecture
with variants that satisfy particular customer requirements.
• The architecture of a system may be designed around one of
more architectural patterns or ‘styles’.
– These capture the essence of an architecture and can be instantiated
in different ways.

44. A repository architecture for an IDE

45. Overview
A framework for architectural knowledge management
(domain models, rule engine, and visualization components)
- Automatic annotation of architectural-significant elements
- Population & recommendation of architecture alternatives and software
solutions to realize architectural design decisions
- Extract architectural decisions (focus on technical decisions) from issue
management system
- Classify them as either structural, behavioral, or banned decisions
- Extract – who raised the concern, who took the decision and when was
the decision made from the issue management system (what is implicit)
- Build user profiles based on the above information
Use the AKM model, user model, and a set of simple heuristics to predict
the possible architectural decisions that will be taken by an architect

46. Architecture design decision model
170217 Manoj (© Florian Matthes, 2016)
46

47. • Existing work on ADD models do not consider user preferences, project
context, and heuristics to support the decision making process
• AIM
• Extract who took the decision, how long did it take to implement, complexity of tasks
involved based on source code changes
• Extract a decision makers’ preferences related to technologies and types of issues
handled to build user profiles.
• RESULT
• Combining user profiles with the ADD model should support the
recommendation of
• Who should be responsible to address a specific concern?
• What is the cost of addressing a specific concern?
Who did what, and when?
• Who did what and when?
• Use issue management system as the main input source
• Focus on a specific domain (e.g. analytics domain) and
system (e.g. component-based)
?

48. Example
• Sensitive case information…

49. OPENNESS IN PLATFORM ARCHITECTURES

50. Architecture Openness
• Architectural Openness Model
• Architectural Openness Factors
• Openness in Five Main Mobile Platforms

51. Results: Architectural Openness Model
Applications
Middleware
Kernel
Extended ApplicationsNative Applications
App 1 App 2 App 3 App N...
(Services, Libraries, Frameworks …)
(Device Drivers, Memory Management, Power Management, Security …)
App 1 App 2 App 3 App M...
51
Platform Architecture
Symbian Architecture Android Architecture
+
Platform Accessibility
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
Architecture (Cho and Jeon, 2007) iPhone Architecture

52. Results: Architectural Openness Factors
Layer Factor
Possibility
statuses
If possibleLicensing
statuses
Extended applications
Integrate extended
applications
Possible/
Possible for
some
components/
Not possible
Permission is not
needed/ In some
situation
permission is
needed/ Permission
is always needed
Extend extended applications
Modify extended applications
Native applications
Integrate native applications
Extend native applications
Modify extended applications
Middleware
Integrate middleware
Extend middleware
Modify middleware
Kernel
Integrate kernel
Extend kernel
Modify kernel

53. Results: Openness in Five Main Mobile Platforms
Android
Applications
Middleware
Kernel
Extended ApplicationsNative Applications
Home Contacts Phone Browser... App1 App2 App3 AppN...
Application Framework
Libraries Android Runtime
Activity
Manager
Windows
Manager
Content
ProvidersPackage
Manager
Telephony
Manager
Resource
Manager
View System
Location
Manager
Notification
Manager
Device Drivers (Display,
Camera, IPC, Flash
Memory, Audio, WiFi,
Keypad…)
Power
Management
Surface
Manager
Media
Framework
SQLite OpenGL | ES
FreeType WebKit SGL SSL
Core Libraries
Dalvik Virtual
Machine
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
Security
Memory
Management
...
Possible / Permission is not needed
Possible for some components / Permission is not needed
Possible / In some situation permission is needed
Possible for some components / In some situation permission is needed

54. Results: Openness in Five Main Mobile Platforms
iPhone
Applications
Middleware
Kernel (Core OS)
Extended ApplicationsNative Applications
App 1 App 2 App 3 App N...
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
Integrate
Extend
Modify
...
App 1 App 2 App 3 App M...
Core Services
Drivers Security Framework CFNetwork
Accessory
Framework
...
Address Book
Core Data
Framework
Core Location
Framework
SQLite
Core Foundation
Framework
...
In App Email
Map Kit
Framework
Address Book
UI Framework
UIKit
Framework
Apple Push
Notification Service
...
Cocoa Touch
Graphics Framework Audio Framework Video Framework
Media
Possible / Permission is always needed
Possible for some components / Permission is always needed
Not possible

55. Comparison
Factor Android Symbian Windows Mobile Blackberry iPhone
P L P L P L P L P L
Integrate extended
applications
Extend extended
applications
Modify extended
applications
Integrate native
applications
Extend native
applications
Modify native
applications
Integrate
middleware
Extend middleware
Modify middleware
Integrate kernel
Extend kernel
Modify kernel
P - Possibility: Possible (Green), Possible for Some Components (Yellow), Not Possible (Red)
L - Licensing: Permission is Not Needed(Green), In some cases permission is needed(Yellow),
Permission is Always Needed(R), N/A(Gray)

56. Conclusions
• Proposed architectural openness model shows how
the openness strategies of mobile platform suppliers
affect the software architecture of the platforms
• Proposed architectural openness factors shows how
open the mobile software platforms are
• Based on the model and the factors, the openness
degree of five main mobile platforms is identified
• Qualitative interviews validate the previous conclusion
• Interviews show application developers don’t care
about architectural openness of their favorite
platforms
• Interview with Some Device Manufacturers, and
Mobile Suppliers is recommended

57. Discussion: How could Android be more open?

58. Group discussion: How open is eSDK? EMUI?

59. Excerpt, slides deliberately left out

60. Course website
http://nisi.nl/cursussen/agilesoftwarearchitecture
You will receive the slides by mail or via the website

61. Information
For more information about the course you can contact
• Slinger Jansen
• S.jansen@nisi.nl
• 06 – 19884880
Don’t forget to submit your homework!
www.nisi.nl
info@nisi.nl
+31(0)30 - 268 5398
Copyright © 2017 Netherlands Institute for the Software Industry (NISI) and Utrecht University