View
301
Download
3
Category
Tags:
Preview:
DESCRIPTION
This is the deck from my session at TechEd 2009.
Citation preview
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
Recommended