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

2. Architecture Driven
Analysis
Matt Hessinger

3. Analysis Driven
Architecture
Matt Hessinger

4. Architecture Driven
Analysis
Matt Hessinger

5. My Asks…
Compare what you hear to your
experience
Give me your gut reaction
Help me decide if this warrants
further exploration

6. Overview
Framing the discussion
A few anecdotes
The landscape
Next steps

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

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

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

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

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

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

14. The Practice: Negative Forces
Platform & Tool
Immaturity
Methodology Organizational
Stagnation Practitioner Structures
Segmentation
Conceptual
Variation

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

16. The Practice: Positive Forces
Platform & Tool
Advancement
Methodology Organizational
Maturation Practitioner Flexibility
Integration
Conceptual
Simplification

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

18. 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…)

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

20. Systems Devices
Architecture: Area of
influence (on the “what”)
Resources
External
Databases External Services
Common Capabilities

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

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

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

24. 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)?

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

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