Transcript Matt Hessinger Owner Hessinger Consulting ARC302 Agenda Introduction Value proposition for the session Why there is a disconnect Requirements influenced by architecture Your call to action.

Matt Hessinger
Owner
Hessinger Consulting
ARC302
Agenda
Introduction
Value proposition for the session
Why there is a disconnect
Requirements influenced by architecture
Your 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
And Another…
Architects need to use their experience with and
exposure to resources that can reduce the netnew scope of the projects they are involved in
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 lost
Users 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 addressed
Software 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 complexity
Increase in usability and adoption
Quicker time to market
Better manageability and support
More 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 features
Inconsistent realization of common requirements
Replication of existing products and platforms
Broader test scope
High support and management burdens
The Disconnect…
The Roles: Divisive Forces
The Business Analyst
“Focus on business requirements”
Often tasked with gathering “nonfunctional” requirements
Requirements are concrete
Considered by stakeholders to be
more connected to the “business”
Clearly in the line of communication
from subject matter expert
to developer
Can be performed by
“commodity” resources
The Architect
“Focus on architectural
attributes”
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…)
Resource
Access
Layer
Business
Logic
Layer
External
Resources
Business Logic Components
Data Access Components
Storage
Service Adapters
Boundary of new system
Services
User
Interface
Layer
UI Components
UI Process Components
Client Proxies
Service Interfaces
Runtimes: Workflow, Rules Engine, etc
Services: Reference Data, Auditing, Search
Components: Messaging, Data Access
Application Core: Logging, Data Access, Exception Handling
Users
OS Core: Authentication, Authorization, Instrumentation
Shared Data Contracts
Service
Interface
Layer
Systems
Devices
Common Capabilities
Analysis: Area of
Influence on the “what”
Resource
Access
Layer
Business
Logic
Layer
External
Resources
Business Logic Components
Data Access Components
Storage
Service Adapters
Boundary of new system
Services
User
Interface
Layer
UI Components
UI Process Components
Architecture: Area of
influence on the “what”
Client Proxies
Service Interfaces
Common Capabilities
Runtimes: Workflow, Rules Engine, etc
Services: Reference Data, Auditing, Search
Components: Messaging, Data Access
Application Core: Logging, Data Access, Exception Handling
Users
OS Core: Authentication, Authorization, Instrumentation
Shared Data Contracts
Service
Interface
Layer
Systems
Devices
The Roles: Integrating 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
Resource
Access
Layer
Business
Logic
Layer
External
Resources
Business Logic Components
Data Access Components
Storage
Service Adapters
Boundary of new system
Services
User
Interface
Layer
UI Components
UI Process Components
Client Proxies
Service Interfaces
Common Capabilities
Runtimes: Workflow, Rules Engine, etc
Services: Reference Data, Auditing, Search
Components: Messaging, Data Access
Application Core: Logging, Data Access, Exception Handling
Users
OS Core: Authentication, Authorization, Instrumentation
Shared Data Contracts
Service
Interface
Layer
Systems
Devices
The Architect's Stake...
Architectural Requirements
Non-functional requirements
Framework requirements
Platform 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
Resource
Access
Layer
Business
Logic
Layer
External
Resources
Business Logic Components
Data Access Components
Storage
Service Adapters
Boundary of new system
Services
User
Interface
Layer
UI Components
UI Process Components
Client Proxies
Service Interfaces
Common Capabilities
Runtimes: Workflow, Rules Engine, etc
Services: Reference Data, Auditing, Search
Components: Messaging, Data Access
Application Core: Logging, Data Access, Exception Handling
Users
OS Core: Authentication, Authorization, Instrumentation
Shared Data Contracts
Service
Interface
Layer
Systems
Devices
“Interesting”
Frameworks
Platforms
Non-functional
Architectural Requirements
Non-functional requirements
“Properties that a system must possess”
Example: The killer app…that almost got killed off
Framework requirements
Platform requirements
“Interesting” requirements
The toe in the water
http://www.fedex.com/index.html
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.
Marketing saves the day
http://www.fedex.com/index.html
Business
Performance
Where did package
tracking go?
Are we a marketing
company, or a
shipping company?
Large images over
very low average
bandwidth
Usability
Accessibility
Lots of links.
Orange text on
black background
Image maps and other
visually driven navigation.
Tabular layouts
Business
Performance
Where did package
tracking go?
Are we a marketing
company, or a
shipping company?
Large images over
very low average
bandwidth
Usability
Accessibility
Lots of links.
Orange text on
black background
Image maps and other
visually driven navigation.
Tabular layouts
Business
Performance
Where did package
tracking go?
Are we a marketing
company, or a
shipping company?
Large images over
very low average
bandwidth.
(hint…they’re sitting in this room)
Usability
Accessibility
Lots of links.
Orange text on
white background.
Image maps and other
visually driven navigation.
Tabular layouts.
Requirements Examples
Performance
Availability
Usability
Accessibility
Supportability
Instrumentation
Installation and updates
Operations
Security
Data constraints (privacy, etc.)
Data operations (integrity, restoration, etc.)
And more…
Why Architects Care
Cross cutting concerns
Affects design choices
Impact on complexity
Harder to fix downstream
Understanding of impact
What You Can Do About it
Be aware of standards
In your organization (ex: Uptime SLAs)
External (W3C, HIPAA, etc.)
Look for existing requirements catalogs
Usability: 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 modeling
Performance: Models and tools
Architectural Requirements
Non-functional requirements
Framework 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 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
Varied layouts
Raw estimates of multiple effort months for each search
Allowed for very little flexibility
Outlook 2007: Search Execution
Single text box search
Prompt for broader
search scope if
no results in
current scope
Also includes field
based options
I’ve never used them…
have you?
Architecture
No search results we found for “architecture”
Example: Search…With Architects
Requirements for 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
Very successful adoption…almost too successful
Requirements Examples
Meta-data management
End-user customization
Business rule authoring and management
Search
Workflow
Visualization tools
Broadly used client applications
And more…
Why Architects Care
Opportunities to reduce engineering scope
Greater consistency leads to greater adoption
No prizes for wheel reinvention
Chance to drive reuse within project
Reduce surface area of complex problems
Getting framework right is fun work
What You Can Do About it
Be aware of higher order frameworks
On 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 consistency
Mock up user experiences to demonstrate concepts
Foster use of frameworks within your company
Evangelize reuse…really…this time we mean it!
Be proactive in building analysis of options
Architectural Requirements
Non-functional requirements
Framework requirements
Platform 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
Scope of development
(building on…)
Customer perception of value
(using…)
Solutions
Users live here.
Always.
Seriously.
Increasing Scope
Libraries and Frameworks
We love tackling
gnarly problems
down here
Operating Systems
Hardware
Increasing Value
Applications
Solution Platform (What You See)
Collaboration
Content Mgt
Portal
Search
BPM
BI
Discussions
Calendars
E-Mail
Presence
Project Mgt
Offline
Authoring
Approval
Web Publishing
Policy & Auditing
Rights Mgt
Retention
Multi-Lingual
Staging
MySites
Targeting
People Finding
Social Networking
Privacy
Profiles
Site Directory
Indexing
Relevance
Metadata
Alerts
Customizable UX
Rich\Web Forms
Biz Data Catalog
Data in Lists
LOB Actions
Single Sign-On
BizTalk Integ.
Excel Services
Report Center
KPIs
Dashboards
SQL RS\AS Integ.
Data Con. Library
Site Model
APIs
Rendering
Templates
Navigation
Visual Blueprint
Fields\Forms
OM and SOAP
Events
Deployment
Applications
Management
Security
Storage
Delegation
Provisioning
Monitoring
Staging
Rights\Roles
Pluggable Auth.
Per Item
Rights Trimming
Topology
Core Services
Repository
Metadata
Versioning
Backup
Config. Mgmt.
Farm Services
Feature Policy
Extranet
Web Parts | Personalization | Master Pages | Provider Framework (Navigation, Security…)
Database services
IIS
Base Platform
Search services
Workflow services
ASP.NET
Windows Workflow Foundation
Operating System Services
Solution Platform (What Users See)
Collaboration
Content Mgt
Portal
Search
BPM
BI
Unified search
Excel workbooks
Indexing
Rich\Web Forms
Excel Services
Biz Data Catalog
Report Center
and UDFsRelevance
Metadata
Data in Lists
KPIs
Policy & Auditing
LOB Actions
Dashboards
accessible onAlerts
the
Workflow
logic
Rights Mgt
Sign-On
SQL RS\AS Integ.
server Customizable UX Single
Retention
BizTalk Integ.
Data Con. Library
changes
without
Multi-Lingual
Staging
developers
Easy business
intelligence
Desktop
Management
Security
Storage
Topology
Site Model
APIs
application
Delegation
Rights\Roles
Repository
Config. Mgmt.
Rendering
Fields\Forms
Provisioning
Pluggable Auth.
Metadata
Farm
Services
Templates
OM and SOAP
integration
Elimination of
Monitoring
Per Item
Versioning
Feature Policy
Navigation
Events
Staging requests
Rights Trimming
Backup
Extranet
Visual Blueprint
Deployment
change
Infinite storage
User authored
forms
available
Web Parts | Personalization | Master
Pages
| ProviderinFramework (Navigation, Security…)
aSearch
browser
Self provisioning
services
Workflow services
Database
services
Taking over the
of new solution
ASP.NET
Windows
Foundation
IIS
UIWorkflow
for all other
instances
Single sign-on
applications
InfiniteAuthoring
UI
Approval
customization
Web Publishing
Discussions
Calendars
E-Mail
Presence
Project Mgt
Offline
MySites
Targeting
People Finding
Social Networking
Privacy
Profiles
Site Directory
Applications
Core Services
Base Platform
Operating System Services
Requirements Examples
Self-provisioning of new application instances
Organic, configurable solutions
Ability to adapt rapidly to change needs
Use of standard user interface concepts
Existing applications connected to common UI
Single authentication method
Single authorization store
Minimal deployment impact
Desktop application integration
And more…
Why Architects Care
Must justify any new development
Tradeoffs between user requirements and
platform capabilities
Decisions on how best to address platform
limitations and gaps
Many non-functional requirements are already
bounded by the platform
If platform not already adopted, steeper hill to
climb to gain acceptance
Platform may require approaches that are
new to the team
What You Can Do About It
Watch out for the platforms in your organization
The 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 tradeoffs
Know the platform, and assess its malleability
Prototype on platform…always…no exceptions
Architectural Requirements
Non-functional requirements
Framework requirements
Platform 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 platforms
Extension to mobile devices
Novel user interaction schemes
Integration with long running
business processes
Complex message formats
Use of rich media
Why Architects Care
These are the boundary cases where complexity
can quickly escalate
There is often a serious technology component
that must be considered
Often treated as nice-to-haves in the process,
but must-haves in the actual system
Can 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 definition
Prototype 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 requirements
Framework requirements
Platform 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 Action
Take 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
Matt Hessinger
SkyDrive with architecture/analysis resources
email: matth {at} hessingerconsulting.com
I will ALWAYS respond…
blog: http://architectcenter.com/blogs/mhessinger/default.aspx
Infrequent, but hopefully interesting, posts
More about me:
http://www.linkedin.com/in/matthewhessinger
If we work together, collaborate, etc. we will link
Resources
www.microsoft.com/teched
www.microsoft.com/learning
Sessions On-Demand & Community
Microsoft Certification & Training Resources
http://microsoft.com/technet
http://microsoft.com/msdn
Resources for IT Professionals
Resources for Developers
www.microsoft.com/learning
Microsoft Certification and Training Resources
Related Content
Breakout Sessions
• ARC201 - A Lap around Team System 2010 Architecture Edition
• ARC307 - Using Architectural Skills to Increase Solution Adoption Success Rates
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 search
Conceptual 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 scope
When 80% of the scope isn’t the actual system
“We need our own authentication”
Barriers to reuse of existing services
The Practice: Negative Forces
Platform & Tool
Immaturity
Methodology
Stagnation
Practitioner
Segmentation
Conceptual
Variation
Organizational
Structures
The Practice: Negative Forces
Platform and Tool
Immaturity
Methodology
Stagnation
Organizational
Structures
Conceptual Variation
Practitioner
Segmentation
• 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
• Lack of integration between “functional” and “non-functional” work streams
• Focus on production of documents, not data
• One word: Waterfall
• Valuation of “pure” business roles over integrated business/technical
• Valuation of logistical/management roles over delivery
• Valuation of paper over experience
• Lack of common language, terms, grammar
• Lack of standardization on common concepts
• Higher value placed on “new thinking” vs. reuse of concepts
• No integration between communities of practice
• Artificial competition and barriers created by other forces
• Different histories
The Practice: Positive Forces
Platform & Tool
Advancement
Methodology
Maturation
Practitioner
Integration
Conceptual
Simplification
Organizational
Flexibility
The Practice: Positive Forces
Platform and Tool
Advancement
Methodology
Maturation
Organizational
Flexibility
Conceptual
Simplification
Practitioner
Integration
• More and more existing services available for use
• Investments in tooling and runtimes for use by analysts
• Business-driven alignment of analysis with implementation
• Improvement on “classic” requirements gathering
• Visibility into and support for architectural attributes
• Valuation of integrated business/technical roles
• Removal of communication barriers
• Valuation of paper over experience
• More functional patterns with real-world adoption
• Business drive for simpler solution
• This is our quest (among other things…)
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.