Business Analysts V Architects


Published on

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

Published in: Technology, Design, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Business Analysts V Architects

  1. 1. Business AnalystsvsArchitects<br />Kevin Francis, Principal Architect<br />Business Analyst World, Melbourne, July 2009<br />
  2. 2. Learning Objectives<br />Understand the points of interface between Business Analysts and Architects from an Architect’s perspective<br />Learn the best practices available in the space and the division of labour across the roles<br />Review tools available to support the analysis, design and architecture of solutions<br />
  3. 3. Agenda<br />Architects defined.<br />Responsibilities – BAs and Architects<br />Interface Points<br />Processes and Best Practices<br />Tools<br />
  4. 4. Architects:<br />Develop the architecture<br />Choose the technologies<br />Design the development approach<br />Oversee the development<br />Manage technical change<br />
  5. 5. BA and Architect Responsibilities<br />Business Analyst:<br />Gather requirements<br />Document Requirements<br />Work out design<br />Focus on business processes<br />Change management<br />Training<br />Process Change<br />Interface to the business<br />Project vision/purpose<br />Scope Management<br />Architect:<br />Design system to meet requirements<br />Manage the Development Team<br />Implement technology<br />Focus on non-functional, technical and UI<br />Interface to Enterprise Architecture<br />Project vision/purpose<br />Scope Management<br />
  6. 6. Interface Points<br />User Interface Design<br />Non-Functional Requirements<br />Architectural Design<br />Data Design<br />Scope Management<br />Test Management<br />
  7. 7. User Interface Design<br />
  8. 8. The Usual Process<br />Screens<br />Technology<br />UI Components (Data Items)<br />Flow<br />
  9. 9. UI Approaches<br /><ul><li>Easily deployed
  10. 10. Non-responsive
  11. 11. Non-integrated
  12. 12. Difficult to develop
  13. 13. Difficult to maintain
  14. 14. Responsive
  15. 15. Attractive
  16. 16. Integrated
  17. 17. Easier to develop
  18. 18. Easier to maintain
  19. 19. Easily deployed</li></li></ul><li>Web Application Technologies<br />HTML<br />SharePoint etc<br />Silverlight<br />Desktop applications<br />
  20. 20. Best Practice<br />BAs understand the requirements<br />BAs understand the business<br />Architects understand the technology and best practices for implementation<br />Technical UI design is a specialised Designer/Developer task, with assistance from the BA<br />Poor result without BA, Architect and Designer working together<br />
  21. 21. Get up to date with technical options<br />
  22. 22. Gather requirements (without making commitments)<br />
  23. 23. Design the Architecture<br />
  24. 24. Prototyping<br />
  25. 25. Non-Functional Requirements<br />
  26. 26. The Tension<br />
  27. 27. Non-Functional Requirements<br />Balance between cost and requirements<br />Architects understand this balance<br />Needs BAs to translate to the business though<br />Can&apos;t be a one-way street<br />
  28. 28. Architecture<br />
  29. 29. Architectural Design<br />Architecture is a set of trade-offs<br />They need to be understood from a business perspective<br />The trade-offs impact the requirements<br />Cooperation therefore produces the best outcome<br />
  30. 30. Data Design<br />
  31. 31. Data Design<br />Data requirements come through the BAs<br />Database design is a specialist Architecture job<br />BAs can assist the Architect to understand the data<br />Focus is needed on aspects like availability, recovery, auditing and archiving<br />
  32. 32. Scope Management<br />
  33. 33. Scope Management<br />Scope is always a trade-off between cost and functionality<br />There are always multiple ways to achieve the end-game<br />The aim is efficiency and minimum wasted cost<br />BA and Architects work together with ongoing change:<br />Estimate early<br />Manage trade-offs<br />Present alternatives<br />
  34. 34. Scope Management<br />Change Request<br />Discuss Options with Architect<br />Estimate<br />Options<br />
  35. 35. Test Management<br />
  36. 36. Test Management<br />Test Early<br />Decipher requirements<br />Prioritise testing<br />Support non-functional testing<br />Testing<br />Project<br />BA Requirement<br />
  37. 37. Tools<br />Why use a tools-based approach to managing the interface?<br />Process tools<br />Rational Tools<br />Microsoft Tools<br />Open Source Options<br />
  38. 38. Thank you<br />Questions (and hopefully) Answers<br /><br /><br /><br />