Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SAF 2008 - Analysis and Architecture

308 views

Published on

This is my deck from my session at Microsoft\'s Strategic Archicture Forum in November, 2008.

  • Be the first to comment

SAF 2008 - Analysis and Architecture

  1. 1. Architecture Driven Analysis Matt Hessinger
  2. 2. Analysis Driven Architecture Matt Hessinger
  3. 3. Architecture Driven Analysis Matt Hessinger
  4. 4. My Asks… Compare what you hear to your experience Give me your gut reaction Help me decide if this warrants further exploration
  5. 5. Overview Framing the discussion A few anecdotes The landscape Next steps
  6. 6. The Idea To get to S+S, we need A*A By aligning the practice and roles of architecture and analysis, a force multiplier can be achieved that has a positive impact on key software project factors.
  7. 7. Why Now There are forces that are pushing the practices of architecture and analysis into closer alignment Closer alignment between architectural attributes and business requirements will be an important factor in solutions in an S+S world Subject matter experts (not to mention end users) are being given more and more direct control of system behavior Software vendors are recognizing the value of systems whose runtime behavior can be affected by users
  8. 8. Key Questions What should enable the alignment of architecture and analysis thinking? What has limited this in the past? What should motivate architects and analysts to work together? What reasons have they not worked as closely in the past? What do we, the architecture community, need to do to make this happen?
  9. 9. A Couple Anecdotes “Architects don’t contribute to requirements” The impact of dogmatic role adherence Greenfield search Conceptual complexity in the face of overwhelming common patterns Authoring tool scope vs. system scope When 80% of the scope isn’t the actual system “We need our own authentication” Barriers to reuse of existing services
  10. 10. A Couple Anecdotes “Architects don’t contribute to requirements” The impact of dogmatic role adherence Greenfield search* Conceptual complexity in the face of overwhelming common patterns Authoring tool scope vs. system scope When 80% of the scope isn’t the actual system “We need our own authentication” Barriers to reuse of existing services
  11. 11. Greenfield search: Initial state Business requirements defined as brand new Did not take into account existing adopted search patterns No architecture input Each search scope had its own full set of requirements User experience Pattern matching Some inconsistency between searches of “own” data and those supported by external services Advanced search approach was the default Structured fields Raw estimates of multiple effort months for each search Allowed for very little flexibility
  12. 12. Greenfield search…with architects Single configurable runtime defined Business requirements for each scope could be defined within the bounds of the framework Consistent approach for “owned” data searches, API/Service supported, etc. Single textbox search as the default Accepted user expectation Effort for defining and implementing a single search lowered dramatically Weighed against the non-trivial effort to build the framework Reasonable degree of flexibility to support future change
  13. 13. The Practice: Negative Forces Platform & Tool Immaturity Methodology Organizational Stagnation Practitioner Structures Segmentation Conceptual Variation
  14. 14. The Practice: Negative Forces Platform and Tool • Need to repeatedly define and build the same features over and over • Challenge in linking requirements to services Immaturity • Lack of analyst-driven development support in tools Methodology • Lack of integration between “functional” and “non-functional” workstreams • Focus on production of documents, not data Stagnation • One word: Waterfall Organizational • Valuation of “pure” business roles over integrated business/technical • Valuation of logistical/management roles over delivery Structures • Valuation of paper over experience Conceptual • Lack of common language, terms, grammar • Lack of standardization on common concepts Variation • Higher value placed on “new thinking” vs. reuse of concepts Practitioner • No integration between communities of practice • Artificial competition and barriers created by other forces Segmentation • Different histories
  15. 15. The Practice: Positive Forces Platform & Tool Advancement Methodology Organizational Maturation Practitioner Flexibility Integration Conceptual Simplification
  16. 16. The Practice: Positive Forces Platform and Tool • More and more existing services available for use • Investments in tooling and runtimes for use by analysts Advancement • Business-driven alignment of analysis with implementation Methodology • Improvement on “classic” requirements gathering • Visibility into and support for architectural attributes Maturation Organizational • Valuation of integrated business/technical roles • Removal of communication barriers Flexibility • Valuation of paper over experience Conceptual • More functional patterns with real-world adoption • Business drive for simpler solution Simplification Practitioner • This is our quest (among other things…) Integration
  17. 17. The Roles: Divisive Forces The business analyst The architect “Focus on business “Focus on architectural requirements” attributes” Often tasked with gathering Indirectly influences business “non-functional” requirements requirements Requirements are concrete Requirements change Considered by stakeholders to Considered by stakeholders to be more connected to the be more connected to the “business” “technology” Clearly in the line of Considered to be outside the communication from subject direct line of communication matter expert to developer Can be performed by Not considered to be a “commodity” resources commodity (yet…)
  18. 18. Users Interface UI Components Layer User UI Process Components Interface Client Proxies Service Layer Service Interfaces Business Shared Data Contracts Layer Logic Business Logic Components Resource Access Layer Data Access Components Service Adapters Boundary of new system Analysis: Area of Influence on the “what”.
  19. 19. Systems Devices Architecture: Area of influence (on the “what”) Resources External Databases External Services Common Capabilities
  20. 20. The Roles: Integrative Forces Common platform for communication Agreement on shared responsibility Building awareness and capability of practitioners Shared tools for capturing and leveraging requirements Dropping of functional/non-functional distinctions Common capabilities that support the business need
  21. 21. External Resources Resource Business Service Access Logic Interface Layer Layer Layer Systems Boundary of new system Databases Client Proxies Service Interfaces User Interface Data Access Components Business Logic Components Layer Users UI Components UI Process Components Service Adapters External Services Shared Data Contracts Devices OS Core: Authentication, Authorization, Instrumentation Application Core: Logging, Data Access, Exception Handling Common Capabilities Components: Messaging, Data Access Services: Reference Data, Auditing, Search Runtimes: Workflow, Rules Engine, etc
  22. 22. Summary There is value in alignment and integration of analysis and architecture, of analysts and architects If accomplished well, this integration is a positive force multiplier on the success of a project Anecdotal evidence can be presented to support this argument The environment is at a point that this alignment can be achieved The architecture community needs to play a role in making this happen
  23. 23. My Asks…revisited Compare these thoughts to your experience • How has your experience as an architect been affected by requirements practitioners? • What have you contributed to requirements process? • How has business analysis affected your architectures (and vice versa)? Give me your gut reaction • Do you feel that the topic discussed has merit? • Is there anything that elicited a strong response (positive or negative)? Help me decide if this warrants further exploration • Is this an important topic to pursue? • Do you feel that you have something to contribute to this discussion? • Are you willing to work with a group to shape that contribution (and the contribution of others)?
  24. 24. Next Steps Enjoy the rest of SAF Get connected to the Architecture Community Site Watch for progress on this topic Decide if you want to join in
  25. 25. © 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.

×