Presentation from Microsoft Tech.Ed Australia and Tech.Ed New Zealand Sept 2009. It discusses the role of the Solution and Application Architect in the successful delivery of software projects. It is also applicable to Infrastructure Architects. The role of the Agile approach to software development is also discussed and issues highlighted.

2. Challenging the Role of the Architect Kevin Francis Practices Manager Object Consulting Session Code: ARC202

3. Who Is This Anyway?Do I know anything about this? I’ve been an Architect for a while (erk!) Project experience of different sizes Agile Consulting Big and small teams Governance

4. Challenging the Role of the ArchitectAgenda Discuss project delivery Issues with Agile project delivery Examine the role of the Architect in projects To explain what works and what doesn't To propose some better approaches 60 minutes + questions Slides will be available – Commnet and my blog

5. About Projects

6. So How's It All Working Then? O%

7. What Matters in Project Delivery?Hint: Not the technology... Projects range from $100,000 to $100,000,000 Delivery matters most to the people that put their neck on the line to support the initiative Most are ‘fixed price’ What matters is delivery: On time On budget Meets all the requirements Who’s responsible for making sure this happens?

8. The Big Question…. Can a team of developers, working with an agile approach, work with the business to deliver a technically excellent solution that meets all requirements without the need for an Architect? YES! (in Fairyland)

9. What’s Wrong With Agile? It can encourage scope creep It can discourage architecture It can disconnect control It can absolve the team of design responsibility Change! Re-factoring on re-factoring It can lead to project failure

10. Architecture in a ProjectArchitecture is about meeting the requirements Functional Non-Functional Scalability Performance Security Usability Integration Project Schedule Budget

11. The role of the ArchitectThe Architect is a professional! Architecture Technologies Frameworks Design Approach Development approach Team make-up Direction Managing Change Owning technical issues

12. Further Information www.slideshare.net/KevinFrancis and look for ‘Career Development for Architects’ www.objectconsulting.com.au www.iasahome.org MCA Program: www.microsoft.com/learning/en/us/certification/architect.aspx

13. Relationships

14. The Architect and the PM * Project Manager Architect BA Lead Test Lead Developer Dev. Lead Developer Tester Business Analyst Developer Tester Business Analyst

16. The Architect and the BAInterface Points Breakdown the wall!: Functional Requirements User Interface Design Non-Functional Requirements Architectural Design Data Design Scope Management Test Management www.slideshare.net/KevinFrancis and look for ‘Business Analysts v Architects’

17. Project Execution

18. A Word About Scope Management In any project with a budget, change in a project is EVIL! It upsets the rhythm of the project. It can damage the architecture. It costs money and time, even if no change results. The biggest issue with a truly Agile project is that it is all about change. Change doesn’t fix issues with a project. Deflect as much as possible to v2.0.

19. Starting a ProjectStep by Step High Level Requirements High Level Estimate High Level Design Approx. Approach Enterprise Architecture This approach works in all cases – waterfall, iterative and agile. Use it to create a baseline estimate and scope. Start managing change from here. Choose a development approach here.

20. About High Level Architecture Designed to put scope around the project Designed to provide a high level estimate Use to lock down the architecture at a high level Allows a conversation and early approval from Enterprise Architecture First approval point Baseline to progress from

21. Designing the Architecture Requirements Architecture Scope High Level Architecture UI Prototype Architecture Best Practices Application Prototype Tools and Products

22. Architecture in Agile Projects Lock down the architecture up front Architecture should be reuse before buy before build Regardless of the approach, architecture is an upfront exercise Document clearly and make available. Document to a depth suitable to answer all technical questions

23. Transitions Project Management Business Analysis Testing Architecture Support Architecture Architecture Wiki High Level Design Design, Build, Test, Review Developers Thin Slice

24. During Development Manage change during the project Especially stop movement in architecture Push as much as possible to next project Maintain the architecture Maintain the design in the chosen tool Architecture and design should flow. The level of documentation completed should be enough to allow a support team to take over without a learning curve.

25. Tools VSTS is required: Allows management of requirements Allows management of work items Allows management of risks Allows management of scope Supports agile and iterative processes SharePoint Integrated with VSTS, allows shared view of project and artefacts Process Mentor See www.processmentor.com

26. Justifying Architecture The conversation with management: Reduced risk Greater efficiency Improved maintainability Overall better outcome A project with a strong architectural approach is much more likely to succeed at lower cost than without

27. Summary Project delivery expectations must be high Target what matters to your customers, not to you Beware of the development approach you are using Address the capabilities needed to be an excellent architect Stand up and be a professional!

28. Required Slide Speakers, TechEd 2009 is not producing a DVD. Please announce that attendees can access session recordings at TechEd Online. www.microsoft.com/teched Sessions On-Demand & Community www.microsoft.com/learning Microsoft Certification & Training Resources http://microsoft.com/technet Resources for IT Professionals http://microsoft.com/msdn Resources for Developers Resources

29. Related Content Required Slide Speakers, please list the Breakout Sessions, TLC Interactive Theaters and Labs that are related to your session. Breakout Sessions SEC312 – The "everything developers need to know about security" talk OFC205 – Planning the people AND the project ARC304 – Silverlight won’t save your user experience – you will DEV205 – A tour of CodePlex

31. question & answer

32. Contact Points Kevin Francis Blog: msmvps.org/blogs/architecture Twitter: Kevster009 Email: kevin.francis@objectconsulting.com.au Mobile: +61 438 307 080 www.objectconsulting.com.au www.processmentor.com

33. Required Slide © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.