Agile software architecture
2 likes995 views
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.
Agile software architecture
- 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
- 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
Editor's Notes
- #9: - The first meetings with the customer also include one UX and developer