Format: Lecture
Duration: 60 minutes
Abstract
Software Architects traditionally have been expected to be well versed in the technologies and software platforms on which their organization run, as well as the businessses they serve. Software Architect's need to balance both sides of this coin: business and technology.
Today traditional ways in which architects engage with development groups often conflict with Agile methods. This presentation explores best practices for architects working in an Agile world and ways in which Agile methods might benefit architects. Additionally it attempts to address some of the concerns that many architects express about Agile, and attempts to provide practical ideas as to how architects and agile development teams can become allies.
It is my intention to cover 30 Best Practices with a view that these best practices do not contravene the Agile Manifesto. Specifically an architect can attempt to provide the 1,000ft view on behalf of the development team who in effect are the domain experts and the ultimate custodians of a product's architecture. That said the following best practices could be used to provide a unified view of the longer-term evolutionary path and the processes by which it could be more easily obtained. Today Architect's should not sit in their ivory towers armed with UML modeling tools and interaction charts, instead they have an opportunity to provide coaching and leadership and ensure projects match their objectives both today and tomorrow.
Best Practices:
1. Acknowledge Technology is not Your Biggest Problem
2. Seek the Value in Requested Functionality
3. Look for Working Code not Specifications
4. Ensure Business Drives
5. Use before Reuse, Avoid Generalization Patterns
6. Architects Must Be Hands On
7. Embrace Uncertainty, Its Your Friend
8. Reuse Is Also About People, Not Just Architecture
9. Be Subjective, Try Before Choosing
10. There is no 'I' only 'We'
11. Continuously Integrate
12. Empower Developers
13. Talk the Talk, Ensure you can code your own system
14. Record your Rationale
15. Don't Repeat Yourself
16. Don't Control, Observe Instead
17. Challenge Preconceived Ideas, Especially Your Own
18. Share Knowledge and Experience
19. Focus on Application Support and Maintenance
20. Invite Peer Review, 2 Minds are Better Than 1, 5 Are Better Than 2
21. Take Responsibility for Your Decisions
22. Choose Technology That Plays Well With Others
23. Avoid Toxic Technical Debt
24. Think About Performance Early
25. Realise The Interface is the System
26. Start With A Walking Skeleton
27. Communicate Architectural Trade Offs
28. Avoid tick-the box Culture, Champion Competitiveness
29. Fail Early: Learn from Mistakes
30. Prefer Principles, Convention and Analogies over Personal Opinion and Taste
Biography
James Cooper is the Lead Platforms Architect with F-Secure Corporation, one of Europe's leading Intrusion Detection and Malware Prevention companies and is currently based out of Helsinki Finland. A keen technologist, his professional interests include Cloud Computing, Web Application Security, Federated Identity management; Grid based services and Asynchronous I/O usage patterns.
Comments (2)
Jul 21, 2009
Vasco Duarte says:
The content seems to be quite interesting from a point of view of management als...The content seems to be quite interesting from a point of view of management also, meaning that managers should also learn what the role of an architect is so that they don't just expect architects to be these "tech gurus" and "design" what the lowly programmers will do later.
However the intro/abstract does not entice managers to this session. Am I correct in assuming that this content would also be interesting to managers? If so, should the abstract also "ask some questions" that would interest managers?
Regarding the format of the abstract, it is quite descriptive, but lacks the "gist" for the session. What can architects (and/or managers) expect from this session? What questions will be answered in the session (top 2-3) that would make them want to attend the session?
Aug 05, 2009
James Cooper says:
Sorry I missed your comment, so I cannot amend the presentation, since the deadl...Sorry I missed your comment, so I cannot amend the presentation, since the deadline has elapsed. My initial focus would be for the more technology orientated agile practitioners and as such whilst I think those who work on the management track could find something interesting of note, they are not my primary audience.
I think those that might attend would get an insight into which best practices might be appropriate for them. Some of course have been suggested by the community of architects in the past, but we've seen them play out differently. Ultimately it's my intention to share those experiences and how architects can have a roll in agile that's not contrary to agile methods.How they can help a team realize its vision, remove obstactions and ultimately, enable the team achieve its goal. The top 5, would be based on personal choice more than anything else.