Architecture Driven Analysis

Matt Hessinger

Analysis Driven Architecture

Matt Hessinger

Architecture Driven Analysis

Matt Hessinger

My Asks…

Compare what you hear to your experience

Give me your gut reaction

Help me decide if this warrants further exploration

Overview

Framing the discussionA few anecdotesThe landscape Next steps

The Idea

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.

To get to S+S, we need A*A

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 worldSubject matter experts (not to mention end users) are being given more and more direct control of system behaviorSoftware vendors are recognizing the value of systems whose runtime behavior can be affected by users

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?

A Couple Anecdotes

“Architects don’t contribute to requirements”

The impact of dogmatic role adherenceGreenfield search

Conceptual complexity in the face of overwhelming common patterns

Authoring tool scope vs. system scopeWhen 80% of the scope isn’t the actual system

“We need our own authentication” Barriers to reuse of existing services

A Couple Anecdotes

“Architects don’t contribute to requirements”

The impact of dogmatic role adherenceGreenfield search

Conceptual complexity in the face of overwhelming common patterns

Authoring tool scope vs. system scopeWhen 80% of the scope isn’t the actual system

“We need our own authentication” Barriers to reuse of existing services

*

*The conference planners regret any confusion between

this story and the recently released “Where’s Jack: Lost in

the Software Factory” (now available on Xbox Live)

Greenfield search: Initial state

Business requirements defined as brand newDid not take into account existing adopted search patternsNo architecture input

Each search scope had its own full set of requirements

User experiencePattern matching

Some inconsistency between searches of “own” data and those supported by external servicesAdvanced search approach was the default

Structured fieldsRaw estimates of multiple effort months for each searchAllowed for very little flexibility

Greenfield search…with architects

Single configurable runtime definedBusiness requirements for each scope could be defined within the bounds of the frameworkConsistent 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

The Practice: Negative Forces

MethodologyStagnation

OrganizationalStructures

Platform & ToolImmaturity

ConceptualVariation

PractitionerSegmentation

The Practice: Negative Forces

•Need to repeatedly define and build the same features over and over•Challenge in linking requirements to services•Lack of analyst-driven development support in tools

Platform and Tool Immaturity

•Lack of integration between “functional” and “non-functional” workstreams•Focus on production of documents, not data•One word: Waterfall

Methodology Stagnation

•Valuation of “pure” business roles over integrated business/technical•Valuation of logistical/management roles over delivery•Valuation of paper over experience

Organizational Structures

•Lack of common language, terms, grammar•Lack of standardization on common concepts•Higher value placed on “new thinking” vs. reuse of concepts

Conceptual Variation

•No integration between communities of practice•Artificial competition and barriers created by other forces•Different histories

Practitioner Segmentation

The Practice: Positive Forces

MethodologyMaturation

OrganizationalFlexibility

Platform & ToolAdvancement

ConceptualSimplification

PractitionerIntegration

The Practice: Positive Forces

•More and more existing services available for use•Investments in tooling and runtimes for use by analysts•Business-driven alignment of analysis with implementation

Platform and Tool Advancement

•Improvement on “classic” requirements gathering•Visibility into and support for architectural attributes

Methodology Maturation

•Valuation of integrated business/technical roles•Removal of communication barriers•Valuation of paper over experience

Organizational Flexibility

•More functional patterns with real-world adoption•Business drive for simpler solution

Conceptual Simplification

•This is our quest (among other things…)Practitioner Integration

The Roles: Divisive Forces

The business analyst“Focus on business requirements”Often tasked with gathering “non-functional” requirementsRequirements are concreteConsidered by stakeholders to be more connected to the “business”Clearly in the line of communication from subject matter expert to developerCan be performed by “commodity” resources

The architect“Focus on architecturalattributes”Indirectly influences business requirements Requirements change Considered by stakeholders to be more connected to the “technology”Considered to be outside the direct line of communication

Not considered to be a commodity (yet…)

Boundary of new system

Reso

urce

Acce

ss

Laye

r

Serv

ice

Inte

rfac

e La

yer

Busi

ness

Lo

gic

Laye

r

Use

rIn

terf

ace

Laye

r

Data Access Components

UI Components

Service Interfaces

Business Logic Components

Service Adapters

Client Proxies

UI Process Components

Users

Shar

ed D

ata

Cont

ract

sAnalysis: Area of

Influence on the “what”.

Exte

rnal

Reso

urce

s

Databases External Services

DevicesSystems

Common Capabilities

Architecture: Area of influence (on the “what”)

The Roles: Integrative Forces

Common platform for communicationAgreement on shared responsibilityBuilding awareness and capability of practitionersShared tools for capturing and leveraging requirementsDropping of functional/non-functional distinctionsCommon capabilities that support the business need

Common Capabilities

Boundary of new system

Exte

rnal

Reso

urce

sRe

sour

ceAc

cess

La

yer

Serv

ice

Inte

rfac

e La

yer

Busi

ness

Lo

gic

Laye

r

Use

rIn

terf

ace

Laye

r

Data Access Components

UI Components

Service Interfaces

Databases

Business Logic Components

External Services

DevicesUsersSystems

Appl

icati

on C

ore:

Log

ging

, Dat

a Ac

cess

, Exc

eptio

n H

andl

ing

OS

Core

: Aut

henti

catio

n, A

utho

rizati

on, I

nstr

umen

tatio

n

Service Adapters

Client Proxies

Com

pone

nts:

Mes

sagi

ng, D

ata

Acce

ss

Serv

ices

: Ref

eren

ce D

ata,

Aud

iting

, Sea

rch

Runti

mes

: Wor

kflow

, Rul

es E

ngin

e, e

tc

UI Process Components

Shar

ed D

ata

Cont

ract

s

Summary

There is value in alignment and integration of analysis and architecture, of analysts and architectsIf accomplished well, this integration is a positive force multiplier on the success of a projectAnecdotal evidence can be presented to support this argumentThe environment is at a point that this alignment can be achievedThe architecture community needs to play a role in making this happen

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

Next Steps

Enjoy the rest of SAFGet connected to the Architecture Community SiteWatch for progress on this topicDecide if you want to join in

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