Business Analysts V Architects

Business AnalystsvsArchitects
Kevin Francis, Principal Architect
Business Analyst World, Melbourne, July 2009

Learning Objectives
Understand the points of interface between Business Analysts and Architects from an Architect’s perspective
Learn the best practices available in the space and the division of labour across the roles
Review tools available to support the analysis, design and architecture of solutions

Agenda
Architects defined.
Responsibilities – BAs and Architects
Interface Points
Processes and Best Practices
Tools

Architects:
Develop the architecture
Choose the technologies
Design the development approach
Oversee the development
Manage technical change

BA and Architect Responsibilities
Business Analyst:
Gather requirements
Document Requirements
Work out design
Focus on business processes
Change management
Training
Process Change
Interface to the business
Project vision/purpose
Scope Management
Architect:
Design system to meet requirements
Manage the Development Team
Implement technology
Focus on non-functional, technical and UI
Interface to Enterprise Architecture
Project vision/purpose
Scope Management

Interface Points
User Interface Design
Non-Functional Requirements
Architectural Design
Data Design
Scope Management
Test Management

User Interface Design

The Usual Process
Screens
Technology
UI Components (Data Items)
Flow

UI Approaches

Easily deployed
Non-responsive
Non-integrated
Difficult to develop
Difficult to maintain
Responsive
Attractive
Integrated
Easier to develop
Easier to maintain
Easily deployed

Web Application Technologies
HTML
SharePoint etc
Silverlight
Desktop applications

Best Practice
BAs understand the requirements
BAs understand the business
Architects understand the technology and best practices for implementation
Technical UI design is a specialised Designer/Developer task, with assistance from the BA
Poor result without BA, Architect and Designer working together

Get up to date with technical options

Gather requirements (without making commitments)

Design the Architecture

Prototyping

The Tension

Balance between cost and requirements
Architects understand this balance
Needs BAs to translate to the business though
Can't be a one-way street

Architecture

Architectural Design
Architecture is a set of trade-offs
They need to be understood from a business perspective
The trade-offs impact the requirements
Cooperation therefore produces the best outcome

Data Design

Data Design
Data requirements come through the BAs
Database design is a specialist Architecture job
BAs can assist the Architect to understand the data
Focus is needed on aspects like availability, recovery, auditing and archiving

Scope Management

Scope Management
Scope is always a trade-off between cost and functionality
There are always multiple ways to achieve the end-game
The aim is efficiency and minimum wasted cost
BA and Architects work together with ongoing change:
Estimate early
Manage trade-offs
Present alternatives

Scope Management
Change Request
Discuss Options with Architect
Estimate
Options

Test Management

Test Management
Test Early
Decipher requirements
Prioritise testing
Support non-functional testing
Testing
Project
BA Requirement

Tools
Why use a tools-based approach to managing the interface?
Process tools
Rational Tools
Microsoft Tools
Open Source Options

Thank you
Questions (and hopefully) Answers
http://msmvps.org/blogs/architecture
www.objectconsulting.com.au
kevin.francis@objectconsulting.com.au