Applying Proven Business Analysis Concepts to Architectural Tasks

Matt HessingerOwnerHessinger ConsultingARC302

Agenda

IntroductionValue proposition for the sessionWhy there is a disconnectRequirements influenced by architectureYour call to action

My Goals

Demonstrate why the architect’s involvement in requirements is crucial

Inspire you to get involved in the requirements process

Give you tools to assist in your architectural requirements work

One way of Thinking About it

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

And Another…

Architects need to use their experience with and exposure to resources that can reduce the net-new scope of the projects they are involved in.

For solutions that work, find what already works

The Need

Users need software to help them accomplish their tasks and processes, as quickly as easily as possible, and need to know that their work is secure and won’t be lostUsers need the builders of software to take into account all of the things that they know, their “business” requirements, along with all of the things that they are not aware of or haven’t been exposed to

The Approach

Those responsible for defining systems, namely business analysts and software architects, need to work more closely together to ensure that all of the right requirements are considered and addressedSoftware Architects must stake a stronger claim on the requirements that they are best suited to own, and must also be able to appropriately influence the business requirements to ensure that all system goals are met

The Benefits

A closer alignment of software architecture practices with the definition and analysis of the business’ requirements can yield many benefits

Reduction in complexityIncrease in usability and adoptionQuicker time to marketBetter manageability and supportMore flexibility for future change

The Considerations

By not increasing the architecture role’s ownership and participation in the definition of a system, we will continue the status quo

Re-development of commodity featuresInconsistent realization of common requirementsReplication of existing products and platformsBroader test scopeHigh support and management burdens

The disconnect…

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

Common CapabilitiesBoundary of new system

ExternalResources

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

Storage

Business Logic Components

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

Analysis: Area of Influence on the “what”.

Common CapabilitiesBoundary of new system

ExternalResources

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

Storage

Business Logic Components

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

Architecture: Area of influence on the “what”

The Roles: Integrating 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 CapabilitiesBoundary of new system

ExternalResources

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

Storage

Business Logic Components

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

The architect's stake...

Architectural Requirements

Non-functional requirementsFramework requirementsPlatform requirements“Interesting” requirements

You are not only responsible for figuring out HOW these requirements will be achieved; you have a responsibility to ensure that WHAT is asked for makes sense.

Common CapabilitiesBoundary of new system

ExternalResources

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

Storage

Business Logic Components

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

Frameworks

Platforms

“Interesting”

Non-functional

Architectural Requirements

Non-functional requirements“Properties that a system must possess”Example: The killer app…that almost got killed off

Framework requirementsPlatform requirements“Interesting” requirements

Welcome to FedEx’s home on the World Wide Web.To track a package, enter the tracking number and click the “Request Tracking Info” button.

You can track the status of your package any time of day, anywhere in the world. You'll be able to follow your package's journey even while it is still in transit. Complete the fields above and the delivery and/or the scan information for the package will be displayed.

http://www.fedex.com/index.htmlThe toe in the water.

http://www.fedex.com/index.htmlMarketing saves the day.

Performance

AccessibilityUsability

Business

Where did package tracking go?

Are we a marketing company, or a

shipping company?

Lots of links. Orange text on

black background.

Large images over very low average

bandwidth.

Image maps and other visually driven navigation.

Tabular layouts.

Performance

AccessibilityUsability

Business

Where did package tracking go?

Are we a marketing company, or a

shipping company?

Lots of links. Orange text on

black background.

Large images over very low average

bandwidth.

Image maps and other visually driven navigation.

Tabular layouts.

Performance

AccessibilityUsability

Business

Where did package tracking go?

Are we a marketing company, or a

shipping company?

Lots of links. Orange text on

white background.

Large images over very low average

bandwidth.

Image maps and other visually driven navigation.

Tabular layouts.

Who’s to blame?(hint…they’re sitting in this room)

Requirements ExamplesPerformanceAvailabilityUsabilityAccessibilitySupportabilityInstrumentationInstallation and updatesOperationsSecurityData constraints (privacy, etc.)Data operations (integrity, restoration, etc.)And more…

Why Architects Care

Cross cutting concernsAffects design choicesImpact on complexityHarder to fix downstreamUnderstanding of impact

What You Can Do About it

Be aware of standardsIn your organization (ex: Uptime SLAs)External (W3C, HIPAA, etc.)

Look for existing requirements catalogsUsability: Achieving Usability Through Software Architecture (Bass, John, Kates)Security standards: Recommended Standard Application Security Requirements (DISA)

Be aware of, and use, external evaluation tools Security: Threat modelingPerformance: Models and tools

Architectural Requirements

Non-functional requirementsFramework requirements

“Common requirements, expressed in differing business domains, that may be supported by building or buying a specific technology that can be shared across the solution.”Example: A definition of search capabilities that ignores the obvious (and expected)

Platform requirements“Interesting” requirements

Example: Search…Initial StateBusiness requirements defined as brand new

Did not take into account existing adopted search patternsNo architecture input

Each search scope had its own full set of requirementsUser experiencePattern matching

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

Structured fieldsVaried layouts

Raw estimates of multiple effort months for each searchAllowed for very little flexibility

Outlook 2007: Search Execution

Single text box searchPrompt for broader search scope if no results in current scopeAlso includes field based options

I’ve never used them… have you?

No search results we found for “architecture”

Architecture

Example: Search…With ArchitectsRequirements for 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 expectationEffort for defining and implementing a single search lowered dramatically

Weighed against the non-trivial effort to build the frameworkReasonable degree of flexibility to support future changeVery successful adoption…almost too successful

Requirements Examples

Meta-data managementEnd-user customizationBusiness rule authoring and managementSearchWorkflowVisualization toolsBroadly used client applicationsAnd more…

Why Architects Care

Opportunities to reduce engineering scopeGreater consistency leads to greater adoptionNo prizes for wheel reinventionChance to drive reuse within projectReduce surface area of complex problemsGetting framework right is fun work

What You Can do About it

Be aware of higher order frameworksOn platform: Workflow, Authentication, etc.ISV Products: Business Rules Engines, etc.

Review and analyze business requirements to look for framework-related capabilities

Document the opportunities for consistencyMock up user experiences to demonstrate concepts

Foster use of frameworks within your companyEvangelize reuse…really…this time we mean it!Be proactive in building analysis of options

Architectural Requirements

Non-functional requirementsFramework requirementsPlatform requirements

“Requirements that lead to or that can be realized by a versatile product foundation, supporting a family (line) of solutions built over time.”Example: A solution platform that has gained pretty good adoption, driven primarily by users

“Interesting” requirements

Platform Value

Hardware

Operating Systems

Libraries and Frameworks

Applications

Scope of development(building on…)

Solutions

Customer perception of value(using…)

Increasing ScopeIn

crea

sing

Val

ue

We love tackling gnarly problems

down here.

Users live here. Always.

Seriously.

Solution Platform (what you see)

Base Platform

Core Services

Applications

Operating System Services

Web Parts | Personalization | Master Pages | Provider Framework (Navigation, Security…)

Database services Workflow servicesSearch services

Collaboration

DiscussionsCalendarsE-MailPresenceProject MgtOffline

Content Mgt

AuthoringApprovalWeb PublishingPolicy & AuditingRights MgtRetentionMulti-LingualStaging

Portal

MySitesTargetingPeople FindingSocial NetworkingPrivacyProfilesSite Directory

Search

IndexingRelevanceMetadataAlertsCustomizable UX

BPM

Rich\Web FormsBiz Data CatalogData in ListsLOB ActionsSingle Sign-OnBizTalk Integ.

BI

Excel ServicesReport Center KPIsDashboardsSQL RS\AS Integ.Data Con. Library

Site Model

RenderingTemplatesNavigationVisual Blueprint

Storage

RepositoryMetadataVersioningBackup

Security

Rights\RolesPluggable Auth.Per ItemRights Trimming

Management

DelegationProvisioningMonitoringStaging

Topology

Config. Mgmt.Farm ServicesFeature PolicyExtranet

APIs

Fields\Forms OM and SOAPEventsDeployment

ASP.NET Windows Workflow FoundationIIS

Solution Platform (what users see)

Base Platform

Core Services

Applications

Operating System Services

Web Parts | Personalization | Master Pages | Provider Framework (Navigation, Security…)

Database services Workflow servicesSearch services

Collaboration

DiscussionsCalendarsE-MailPresenceProject MgtOffline

Content Mgt

AuthoringApprovalWeb PublishingPolicy & AuditingRights MgtRetentionMulti-LingualStaging

Portal

MySitesTargetingPeople FindingSocial NetworkingPrivacyProfilesSite Directory

Search

IndexingRelevanceMetadataAlertsCustomizable UX

BPM

Rich\Web FormsBiz Data CatalogData in ListsLOB ActionsSingle Sign-OnBizTalk Integ.

BI

Excel ServicesReport Center KPIsDashboardsSQL RS\AS Integ.Data Con. Library

Site Model

RenderingTemplatesNavigationVisual Blueprint

Storage

RepositoryMetadataVersioningBackup

Security

Rights\RolesPluggable Auth.Per ItemRights Trimming

Management

DelegationProvisioningMonitoringStaging

Topology

Config. Mgmt.Farm ServicesFeature PolicyExtranet

APIs

Fields\Forms OM and SOAPEventsDeployment

ASP.NET Windows Workflow FoundationIIS

Infinite UI customization

Easy business intelligence

Unified searchExcel workbooks and UDFs

accessible on the server

User authored forms available in

a browser

Workflow logic changes without

developers

Elimination of change requests

Self provisioning of new solution

instances Single sign-on

Taking over the UI for all other

applications

Infinite storage

Desktop application integration

Requirements Examples

Self-provisioning of new application instancesOrganic, configurable solutionsAbility to adapt rapidly to change needsUse of standard user interface conceptsExisting applications connected to common UISingle authentication methodSingle authorization storeMinimal deployment impactDesktop application integrationAnd more…

Why Architects Care

Must justify any new developmentTradeoffs between user requirements and platform capabilitiesDecisions on how best to address platform limitations and gapsMany non-functional requirements are already bounded by the platformIf platform not already adopted, steeper hill to climb to gain acceptancePlatform may require approaches that are new to the team

What You Can Do About It

Watch out for the platforms in your organizationThe ones that you might expect: SharePoint, etc.The ones that you might not

Get schooled on platform thinking“The Power of Product Platforms” (Meyer, Lehnerd)“Product Strategy for High Technology Companies” (McGrath)

Know that you will have to address tradeoffsKnow the platform, and assess its malleabilityPrototype on platform…always…no exceptions

Architectural Requirements

Non-functional requirementsFramework requirementsPlatform requirements“Interesting” requirements

“Any user requirement that falls outside the bounds of what is normal and expected within the current environment.”

Requirements Examples

Use of special hardware platformsExtension to mobile devicesNovel user interaction schemesIntegration with long running business processesComplex message formatsUse of rich media

Why Architects Care

These are the boundary cases where complexity can quickly escalateThere is often a serious technology component that must be consideredOften treated as nice-to-haves in the process, but must-haves in the actual systemCan be at odds with some of the non-functional requirements defined for the broader system

What You Can Do About It

Look for industry reference models for feature definitionPrototype early

Using real environment (sweet…)Using emulators: Mobile devices, etc.

Have fun…this is the part of our job where we get to let our hair down (well…some of us do)

Architectural Requirements

Non-functional requirementsFramework requirementsPlatform requirements“Interesting” requirements

You are not only responsible for figuring out HOW these requirements will be achieved. You have a responsibility to ensure that WHAT is asked for makes sense.

Call to ActionTake ownership of the critical requirements

• And stay connected to the rest

Use this deck to connect with your organization

• Tune it with your own stories

Use the resources on my SkyDrive

• And start to harvest and build your own

Stay in touch

• See next slide

Staying connected

SkyDrive with architecture/analysis resourcesemail: matth {at} hessingerconsulting.com

I will ALWAYS respond…blog: http://architect-center.com/blogs/mhessinger/default.aspx

Infrequent, but hopefully interesting, postsMore about me: http://www.linkedin.com/in/matthewhessinger

If we work together, collaborate, etc. we will link

Matt Hessinger

question & answer

www.microsoft.com/teched

Sessions On-Demand & Community

http://microsoft.com/technet

Resources for IT Professionals

http://microsoft.com/msdn

Resources for Developers

www.microsoft.com/learningMicrosoft Certification and Training Resources

www.microsoft.com/learning

Microsoft Certification & Training Resources

Resources

Related Content

Breakout Sessions•ARC201 - A Lap around Team System 2010 Architecture Edition•ARC307 - Using Architectural Skills to Increase Solution Adoption Success Rates

Complete an evaluation on CommNet and enter to win!

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

Appendix Slides

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?

Several Anecdotes

“Architects don’t contribute to requirements”The impact of dogmatic role adherence

Greenfield searchConceptual complexity in the face of overwhelming common patterns

“I want it to work just like…”Building new systems that mimic existing platforms

Authoring/management 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 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” work streams•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