Architecture Without Big Design Up Front

1. TL15 Architecture Without Big Design Up Front  Peter Provost Sr. Program Manager Microsoft Corporation

2. Introduction • How many times have you walked into a legacy codebase and had no idea what was there? • All systems have an architecture, whether you plan it or not • Most systems today have evolved into Big Ball of Mud architectures • Understanding and discovering what is there is a serious challenge today • Ending with a system you want and can maintain is more important than defining the right thing before you start

3. Architectural Discovery • Everyone has existing code bases • Key architectural elements are undocumented • Maintenance is hard, changes are expensive • What can we do? • Let’s begin by discovering what we have using Architecture Explorer…

4. demo Architectural DiscoveryThe Big Picture

5. demo Architectural DiscoveryDigging Deeper

6. demo Architectural Discovery

7. Results And Next Steps • Key dependencies • Architectural anti-patterns • The “death star” dependency diagram • Important layering and dependency management issues • Now let’s look at one of those key components in greater detail…

8. demo Reverse EngineeringSequence Diagrams

9. demo Reverse EngineeringClass Diagrams

10. Results And Next Steps • So far we have discovered… • Namespace issues • A few key classes may be overly complex • Better understanding how to add our change • Create new models to describe the architecture we want at a high level • Layer Diagram with Validation • Component Diagrams • Class Diagrams • Activity Diagrams

11. demo Communicating With ModelsProject System and Version Control

12. demo Communicating With ModelsUsing Team Foundation Server

13. Results And Next Steps • Continue to use models as appropriate to communicate the work that needs to be done • Class Diagrams • Component Diagrams • Activity Diagrams • Use Case Diagrams • Check them into version control and associate them with work items

14. How Does This Relate To Agile? • For agile teams, Architecture is a way to organize and communicate about work and not to define the work • All agile teams use models. They just don’t often do a lot of modeling up front • Agile teams will create models on the fly as needed to describe, design and define a candidate design for a user story or task • In today’s globally disbursed environments, whiteboards won’t always suffice. We need to share in a way that can cross geographies and time zones

15. Conclusions • Every system has an architecture, the trick is figuring out what you have and what you want to do • Communicating effectively with your entire team is paramount • Architectural modeling and discovery tooling is useful regardless of development methodology

16. Related Sessions

17. VSTS 2010 Hands On Labs

18. Questions?

19. Evals & Recordings Please fill out your evaluation for this session at: This session will be available as a recording at: www.microsoftpdc.com

20. © 2008 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.