1.

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

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

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

5.
About Projects<br />

6.
So How&apos;s It All Working Then?<br />O%<br />

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

8.
The Big Question….<br />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?<br />YES!<br />(in Fairyland)<br />

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

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

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

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

13.
Relationships<br />

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

15.

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

17.
Project Execution<br />

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

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

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

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

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

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

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

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

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

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

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

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

30.

31.
question & answer<br />

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

33.
Required Slide<br />© 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.<br />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.<br />