The document provides best practices that architects should follow when working in an agile world, as presented by James Cooper in his talk. Some key best practices include continuously integrating code, empowering developers, choosing technologies that work well with others, avoiding toxic technical debt, and thinking about performance early in the development process. The document emphasizes that architecture is about people, not technologies, and that architects should focus on principles over personal opinions.

1. Architecture in an Agile World - Best Practices Every Architect Should Follow James Cooper - james.cooper@f-secure.com Lead Platforms Architect

2. Agenda Intro Best Practices Questions & Answers October 16, 2009 2

3. About the Speaker James Cooper is the Lead Platforms Architect with F-Secure Corporation. Prior to joining F-Secure, James worked for Wificom Technologies(Finland) and EDB Maxware Benelux(Netherlands) on a variety of projects ranging from Wi-Fi access management to Access Control Solutions(NATO, Dutch Ministry of Defence) and Finance(ING). James has been has been working in Java since 1996, Java EE since 1999, RoR since 2008 and hacking some Visio since 2009. He still codes. Particularly hacking Objective-C and creating his own DSL called NIH in Haskell. October 16, 2009 3

4. Disclaimer October 16, 2009 4 Religious application of principles learned from a presentation during a conference is not a substitute for common sense.

5. Invite Peer Review Architects need to invite reviews. Discussing something always helps to show its weaknesses. 3 Minds are better than 1. Depending on the environment they’re also used to code reviews. Use Model Storming and Stand Up Design. The eventual design will be stronger for it. October 16, 2009 5

6. Acknowledge Technology is not Your Biggest Problem Projects fail every day. Its most likely not their chosen framework. Projects are delivered by people. There will be someone “Who’s not doing it right”. Remember conversations not confrontations. Mark Ramm October 16, 2009 6

7. Seek the Value in Functionality Henry Ford stated. “If I'd asked my customers what they wanted, they'd have said a faster horse.” The answer can be found in the Agile Manifesto. “Collaboration over Contract” Help your customers with the “Why?” part. EinarLandre -“97 Things Every Software Architect Should Know” October 16, 2009 7

8. Ensure Business Drives Architects often act as mediators. Transparency is crucial. Developers make decisions, but not business decisions. Ensure that business lives up to their responsibility of providing direction and answering questions. The side effect is otherwise accidental delegation. David Muirhead October 16, 2009 8

9. Reuse Is Also About People We’ve long known of the productivity benefits of reuse. Even the best architecture or language can fail user adoption. Developers need know its there. They know how to use it. Are convinced its better than writing their own. October 16, 2009 9

11. Continuously Integrate Build environment must be easily reproducible. “It works on my machine” should be a thing of the past. Big bang build and assembly processes are more relic’s from the “Waterfall” period. Augment continuous integration with unit/functional testing. Consider Build Federation for cross platform native assembly. October 16, 2009 11

12. Empower Developers Focus on the team. Architecture is not about your ego nor your CV. Ensure that internal tools and conventions are honored. Promote that tools, operating systems are for the most part left to the decision of the team. Listen to developers, if they say there’s a problem with the design, there probably is. Philip Nelson- “97 Things Every Software Architect Should Know” October 16, 2009 12

13. Talk the Talk Eat your own dog food. Lead by example and be able to fulfill any role on the team. Do not sit in an ivory tower dictating the way forward. Be an expert in at least one tool, preferably an IDE. Avoid suggesting the latest technology if you have no experience with it. Specification’s alone have no inherent value. The goal is deployed production software. October 16, 2009 13

14. Don’t Repeat Yourself Duplication is evil. Repetition is a huge waste of time. Does you framework induce repetition? Has simple far from exemplary example code been the victim of “slash & paste”? October 16, 2009 14

15. Don't Control, Observe Instead You often need to balance Control vs. Chaos. You’ll need to trust the domain experts. Visualize what happens and get the 1,000 ft view. Resist the temptation to create an area of useless documentation. It might pass as contemporary art, but is useless as a model. Dean Leffingwell – “Scaling Software Agility – Best Practices for Large Enterprises” October 16, 2009 15

16. Challenge Preconceived Ideas Its architecture best practice to document, the reasons behind architectural decisions. “costs, performance, skills, time, politics…” Uncover assumptions. Assumptions are often based on “historical reasons”, FUD, resistance to change or coffee machine talk. “Ruby is insecure” or “Python is slow” or “Java has loads of XML files” Aids possible future re-evaluation. Justify those decisions NOT based on empirical evidence. October 16, 2009 16

17. Choose Technology That Plays Well With Others You need to be aware not only of their features, but also how well it works with existing systems. How does it play with existing skill sets, what sort of retraining will you need? What sort of baggage will it bring? Does it create excess complexity that stops you from interoperating with other internal systems. Is it opinionated in the fact it see’s only one view of the world? Never select technology for yourself. October 16, 2009 17

18. Record your Rationale You will have great idea’s which look great on paper. Sadly often it might not work out how you envisaged it. It might not scale, not pass UX design, it might prove to be unreliable. Decision’s will be made on why architectural choices are made, prototypes dropped or elaborated. Record results, reasons and other alternatives. Timothy High - “97 Things Every Software Architect Should Know” October 16, 2009 18

19. Share Knowledge and Experience Asking “What’s it in for me?” defeats the purpose. During the course of our careers, we’ll be tasked with building larger systems with greater zone’s of responsibility. You don't really understand something, until you can explain it easily to your peers. Sharing also helps in bonding, happens in little steps and is about creating an environment that communicates best and worst practices. Promote knowledge sharing, skill’s improvement session’s and common training curriculums. Viewing the system success as a whole rather than simply doing your own bit. October 16, 2009 19

20. Take Responsibility for Your Decisions Recognize your decision making process. Record your decision and the reasons for it. Make sure you’ve communicated it to all those directly and indirectly. Conduct a review process, evaluate whether or not they remain valid or not. Ensure you have team buy-in, after all they will actually enforce decisions they believe in. Delegate decisions to domain experts. Acknowledge there are those who subject matters in areas in which you are not. October 16, 2009 20

21. Support and Maintenance Support should not be an after thought. Especially since the majority of an application lifecycle is spent in maintenance. Ignore this and your system will turn into a vile beast forever synonymous with failure. Architect’s need to focus on maintenance and happy administrators. Plan for developer input during support. Get support involved in planning for maintenance early, preferably as a core member of the maintenance team. Plan for backlash. October 16, 2009 21

22. Avoid Toxic Technical Debt Every project encounters a time when a bug must be fixed or a new feature added. You can “do it right”, “take a shortcut” or implement an “evolutionary dead end”. You’ll be under pressure to get it “done” quickly. As with most architectural issues there is a trade-off involved. There's a hidden cost to making these quick and dirty fixes. Remedy in the near term. Martin Fowler, Bob Martin October 16, 2009 22

23. Think About Performance Early Often performance, fault tolerance, uptime and maintenance are over looked by product owners. Often introduced very late in the project’s lifecycle. Start small and start early. Understand the theoretical achievable performance. You need to know the kinds of changes that lead to a degradation in performance. When you encounter performance problems, you can focus on the most recent changes. You can easier understand the costs as a result. Cameron Purdy - “10 Patterns for Scaling Out Java Applications” October 16, 2009 23

24. Realize The Interface is the System Too many good products are hidden behind poor user interfaces. Users don’t care about your chosen technology platform. User-interface experts should be involved at an early stage. UX should be an integral part of the decision-making process. October 16, 2009 24

25. Communicate Architectural Trade Offs You can't have it all. It is virtually impossible to design an architecture that meet expectation all the time. Trying to fulfill each and every requirement creates an unstable architecture that excels at nothing. You need to be able to convey actual reality. October 16, 2009 25

26. Avoid tick-the box Culture Often Product Owners will be driven by short term benefit. This often delivers little by way of value to end users. But might reward a Product Owner for reaching their targets. You need to think differently, challenge the status quo and bring different ideas to your project. Adding features that a user does not need simply because the competition has them, brings no value to the user and hardly is a competitive differentiator. October 16, 2009 26

27. Fail Early: Learn from Mistakes Success is relative and short lived. But failure is a near-constant. Things will not all work out as expected. Learning will not happen from failure but how you analyze it and what you ultimately learn. The quicker this happens, the sooner you learn “It ain't about how hard ya hit. It's about how hard you can get it and keep moving forward. How much you can take and keep moving forward. That's how winning is done!” – Rocky Balboa(2006) October 16, 2009 27

28. Prefer Principles, Convention over Personal Opinion and Taste Start by describing the principles that were followed. This is easier for those tasked with understanding and implementing the architecture. Architecture that’s clear and principle orientated is easier to empower developers and ensure consistency. Disagreements are resolved with more reasoned discussion to occur without issues being personalized. It also helps to communicate and reason an architecture to those unfamiliar with a given a technology. After all those with limited technical skill sets might have little to contribute technology wise. But principles they can contribute to. Michael Harmer - “97 Things Every Software Architect Should Know” October 16, 2009 28

29. Thank You! Questions ? October 16, 2009 29