Embed Size (px)
DESCRIPTION
Examines the ways in which Business Analysts and Architects should work together in IT projects.
Citation preview
Business Analystsvs
Architects
Kevin Francis, Principal Architect
Business Analyst World, Melbourne, July 2009
2
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
3
Agenda
Architects defined. Responsibilities – BAs and Architects Interface Points Processes and Best Practices Tools
4
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
6
Interface Points
User Interface Design Non-Functional Requirements Architectural Design Data Design Scope Management Test Management
User Interface Design
8
The Usual Process
Screens
UI Components (Data Items)Technology
Flow
9
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
10
Web Application Technologies
HTML SharePoint etc Silverlight Desktop applications
11
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
12
Get up to date with technical options
13
Gather requirements (without making commitments)
14
Design the Architecture
15
Prototyping
Non-Functional Requirements
17
The Tension
NFRs
Availability
Performance
Scalability
Cost
18
Non-Functional Requirements
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
20
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
22
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
24
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
25
Scope Management
Change RequestDiscuss Options
with ArchitectEstimate
Options
Test Management
27
Test Management
Test Early Decipher requirements Prioritise testing Support non-functional testing
Project
Testing
BA Requirement
28
Tools
Why use a tools-based approach to managing the interface?
Process tools Rational Tools Microsoft Tools Open Source Options
29
Thank you
Questions (and hopefully) Answers
http://msmvps.org/blogs/architecture www.objectconsulting.com.au [email protected]
