Challenging The Role Of The Architect
Upcoming SlideShare
Loading in...5
×
 

Challenging The Role Of The Architect

on

  • 2,624 views

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 ...

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.

Statistics

Views

Total Views
2,624
Views on SlideShare
2,432
Embed Views
192

Actions

Likes
0
Downloads
59
Comments
1

3 Embeds 192

http://softarchitect.wordpress.com 186
http://www.slideshare.net 3
http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Great Material. Thanks
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Challenging The Role Of The Architect Challenging The Role Of The Architect Presentation Transcript

  • Challenging the Role of the Architect
    Kevin Francis
    Practices Manager
    Object Consulting
    Session Code: ARC202
  • 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
  • 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
  • About Projects
  • So How's It All Working Then?
    O%
  • 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?
  • 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)
  • 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
  • Architecture in a ProjectArchitecture is about meeting the requirements
    Functional
    Non-Functional
    Scalability
    Performance
    Security
    Usability
    Integration
    Project
    Schedule
    Budget
  • 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
  • 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
  • Relationships
  • The Architect and the PM
    *
    Project Manager
    Architect
    BA Lead
    Test Lead
    Developer
    Dev. Lead
    Developer
    Tester
    Business Analyst
    Developer
    Tester
    Business Analyst
  • 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’
  • Project Execution
  • 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.
  • 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.
  • 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
  • Designing the Architecture
    Requirements
    Architecture
    Scope
    High Level Architecture
    UI Prototype
    Architecture
    Best Practices
    Application Prototype
    Tools and Products
  • 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
  • Transitions
    Project Management
    Business Analysis
    Testing
    Architecture Support
    Architecture
    Architecture
    Wiki
    High Level Design
    Design, Build, Test, Review
    Developers
    Thin Slice
  • 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.
  • 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
  • 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
  • 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!
  • 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
  • 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
  • question & answer
  • 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
  • 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.