Examines the ways in which Business Analysts and Architects should work together in IT projects.

1. Business AnalystsvsArchitects 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

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

7. User Interface Design

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

10. Non-responsive

11. Non-integrated

12. Difficult to develop

13. Difficult to maintain

14. Responsive

15. Attractive

16. Integrated

17. Easier to develop

18. Easier to maintain

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

21. Get up to date with technical options

22. Gather requirements (without making commitments)

23. Design the Architecture

24. Prototyping

25. Non-Functional Requirements

26. The Tension

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

28. Architecture

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

30. Data Design

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

32. Scope Management

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

34. Scope Management Change Request Discuss Options with Architect Estimate Options

35. Test Management

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

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

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