The document discusses agile software architecture, emphasizing the importance of early system understanding and continuous documentation to adapt to changing requirements. It outlines a typical project flow and offers a case example of developing a web system for ticket sales, showcasing iterative development and the challenges faced. Key takeaways include maintaining flexibility in design and documenting important decisions to ensure project continuity despite personnel changes.

1. AGILE SOFTWARE ARCHITECTURE
BOYAN MIHAYLOV
// bm@ebita.dk
// linkedin.com/in/bmihaylov

2. / Introduction
/ Software architecture
/ System requirement specifications
/ Software architecture documentation
/ Agile software architecture
/ Case example
/ Conclusion
/ Q & A
2
AGENDA

3. / M.Sc. in Computer Science @ The University of Copenhagen (2013)
/ 6+ years professional experience
/ 2.5 years in Ebita
/ Conference speaker
/ Interests
/ Software architecture
/ Design patterns & architecture tactics
/ API development
/ Web
3
BOYAN MIHAYLOV

4. 4
EBITA
10 years old
12 employees today
IT consultancy & concept development
Part of Nørgård Mikkelsen since 2013

5. 5
OUR CUSTOMERS

6. / Involves a flow
/ Users have to go through a series of steps
/ Data manipulation
/ E.g. buying tickets or insurance
/ Lasts around 2-3 months
/ Often there are add-ons afterwards
/ Is web-based
/ MVC-style
/ JavaScript, C#, SQL
/ Integration of 3rd-party systems
6
A TYPICAL PROJECT

7. / Over 90 definitions
http://www.sei.cmu.edu/architecture/start/glossary/community.cfm
/ As defined by IEEE 1471
/ Set of decisions, governed by a context
/ An abstraction of a system
7
SOFTWARE ARCHITECTURE
Architecture is the fundamental organization of a system
embodied in its components, their relationships to each
other, and to the environment, and the principles guiding its
design and evolution.

8. / Start as early as possible
/ Get-to-know-the-system process
/ Questions to ask:
/ Who are the stakeholders? Is it B2B or B2C?
/ How many users are going to use the system?
/ Are there external systems to be involved?
/ What information will be managed, stored, and presented?
/ What is the most important function of the system?
/ How many environments are necessary? (development, test, production, etc.)
/ Where will the system be hosted? Any special requirements for access? VPN?
8
THE BEGINNING

9. / Any kind of documentation that specifies what the system should do
/ Word documents
/ Wireframes/drawings that describe the desired functionalities
/ Post-it notes
/ White board notes
/ Photo shots
/ Details – depend on the project
9
SPECIFICATION OF THE SYSTEM

10. / Advantages
/ Core functionalities are described very quickly
/ Visual representation (even a simple one) of the future system
/ Customer can see it on-the-fly and add input
/ Disadvantages
/ Can potentially include too many and too different artifacts
/ Can become chaotic
/ Documents are often left with old content due to time/resource limitations
10
SPECIFICATION OF THE SYSTEM (2)

11. / Motivation
/ Write decisions down
/ People leave projects, people join projects
/ Future maintenance of the system
/ Challenges
/ How to document many views?
/ How to keep documents up-to-date?
/ UML?
/ KISS principle (keep it simple, stupid)
11
DOCUMENTING THE ARCHITECTURE

12. 12
EXAMPLES

13. 13
EXAMPLES (2)

14. / Requirements change constantly
/ Priorities among tasks too
/ Customers want to see how we progress
/ Use iterations
/ SCRUM-based approach
/ Constant communication
/ Find problems as early as possible
/ Pair programming
14
AGILE SOFTWARE ARCHITECTURE

15. 15
WATERFALL VS. ITERATIONS
http://www.ibm.com/developerworks/rational/library/4029.
html

16. 16
CASE EXAMPLE

17. A big company wants to have a new web system to sell tickets for ferries. They already
have an administrative system used internally for managing all the inventory. This system
exposes a web service for external communication. The company wants a decoupled
website so that the back-end can easily be rewritten in other programming language in
the future.
17
REQUIREMENTS

18. / Issues
/ The provided inventory web service has some limitations related to the provided data
/ It requires an access token to be obtained and refreshed on a regular basis
18
1ST ITERATION

19. / Issues
/ The provided inventory web service is very slow
/ If it is stressed “too much”, it stops functioning
19
2ND ITERATION

20. / Issues
/ The customer complains about sold-out tickets offered to buyers
20
3RD ITERATION

21. 21
4TH ITERATION

22. / Start simple, grow slowly
/ Add complexity only when needed
/ Try to postpone it as much as possible
/ Do NOT predict the future, it changes a lot
/ Write your code such that changes can happen ”painlessly”
/ Document important decisions
/ You will regret not doing this at a later point
22
TAKE-AWAY TIPS

23. 23
Q & A