Enterprises today operate in complex and competitive markets. They are always trying to optimize business functions, introduce new business capabilities and tap into new markets quickly and efficiently. For the business to be agile, software systems that’s used for providing business capability need to be agile. The ability to build and integrate new capability in a short time becomes valuable. At the same time, enterprise software systems should help with evolutionary as well as revolutionary changes that will affect core business functions. Iterative architecture is about taking an iterative approach when introducing architectural changes to support business and technical requirements. We’ll also look at an example of using open source middleware for evolving an architecture in iterations.

1. Iterative Architecture
Chintana Wilamuna
Solutions Architect
chintana@wso2.com

2. Architect!

3. Metaphor for an architect
Like a gardener or a tour guide
Erik Dörnenburg - Architecture without Architects
https://www.youtube.com/watch?v=qVyt3qQ_7TA

4. What is software architecture?
http://geekandpoke.typepad.com/geekandpoke/2009/11/enterprise-architecture-made-easy-part-1.html

5. What is software architecture?
The highest-level breakdown of a system into
its parts; the decisions that are hard to
change; there are multiple architectures in a
system; what is architecturally significant can
change over a system's lifetime
Martin Fowler – Patterns of Enterprise Application Architecture
http://amzn.to/1pQe39r

6. Highest level breakdown of a system
http://wso2.com/whitepapers/a-reference-architecture-for-the-internet-of-things/

7. Decisions that are hard to change
● Programming language
● DB schema
● Infrastructure
● Monitoring solution

8. Multiple architectures
● Solution architecture - Overall structure of solution
● Integration architecture - How integration is done
● Security architecture - How each component is secured
● Application architecture - How the application is
structured
● Component architecture - UML diagrams

9. Architectural significance can change overtime
● DB choice
○ NoSQL → MySQL
● Infrastructure
○ AWS → Hosting provider (VMs)

10. Why do software architecture?
http://martinfowler.com/bliki/DesignStaminaHypothesis.html

11. Enterprise systems are complex
http://www3.cis.fiu.edu/conferences/icac2011/files/Keynote_Kephart.pdf

12. Why enterprise systems are complex?
● Overtime
○ Developers/team structure change
○ Acquire functionality
● Mindset – don’t change what works
○ Change is very expensive
● Find ways to incorporate new requirements
○ Often time make architecture more complex

13. Managing complexity – Idealistic!
● Autonomic computing
○ Self configuring
○ Self healing
○ Self optimizing
○ Self protecting
● Long way to go!
http://www3.cis.fiu.edu/conferences/icac2011/files/Keynote_Kephart.pdf

14. Managing complexity – an algorithm!
● Follow this simple algorithm
a. Write down the problem
b. Think real hard
c. Write down the solution
● True IFF you’re Richard Feynman

15. Managing complexity – Practically
● Ongoing challenge
● No Silver Bullet - Fred Brooks, 1986
● Every enterprise / people are different
● Complexity in multiple stages
○ Software development
○ Deployment / operations
○ On going maintenance

16. Software evolution
Over 90% of software cost happen during
maintenance phase
Fred Brooks – Mythical Man Month
http://amzn.to/1Mb3QiR

17. Agile manifesto
● Individuals and interactions over processes and
tools
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan

18. Traditional – Waterfall method
http://scrumreferencecard.com/scrum-reference-card/

19. Scrum
http://scrumreferencecard.com/scrum-reference-card/

20. SAFe - Scaled Agile Framework
http://www.scaledagileframework.com

21. SAFe - Good or bad?
● Criticism from Ken Schwaber - https://kenschwaber.
wordpress.com/2013/08/06/unsafe-at-any-speed/
● Relevant good parts
○ Architecture epics
○ Change architecture based on new
requirements / functionality

22. Iteratively improve - WEST solution

23. Iteratively improve - WEST solution

24. Iteratively improve - WEST solution

25. Iteratively improve - WEST solution

26. Iteratively improve - Legacy auth

27. Iteratively improve - Legacy auth

28. Iteratively improve - Legacy auth
● Interim security architecture change
● Support legacy authentication mechanism
● Prove pluggable nature
● Show business value
● Continue onboarding on subsequent
scrums

29. Iteratively improve

30. Iteratively improve

31. Thank You