1. Business Analysis The Key to Building the Right Software LeAnn Simonson, CBAP LeAnn Simonson Consulting, LLC 763 441-2570 leannsimonson@gmail.com

2. 8 things to keep in mind when you are trying to build the right software… Eight VIII 8

3. Building it right doesn’t mean you built the right thing. 8

4. Software could be… O Elegant O Error-free O Designed with high cohesion O Designed with low coupling O Impressively well-performing O … O …But still might be the wrong thing.

5. Case in Point: The Legislative Tracking App O Latest and greatest features O But, “real users” didn’t want or use

6. The Right Thing O Software should enable and facilitate O the business purpose it is supporting, or O The customer need it is meeting O If you miss this mark, nothing else matters, no matter how well the software is built.

7. The software target is in the business, not in the software. 7

8. The Right Thing = The Business Target O Spend sufficient time and effort making sure you have the true target. O The five whys O Never lose sight of this target as you develop the software.

9. Case in Point: Data in, Never comes out O Report not used O App working well; entry every day O In fact, we have some enhancement needs. O That unused report is for management. O Management: Report not needed as now pulled from another system. O Truth: Data in, never comes out. O Might have fixed the report and enhanced the app with data to nowhere if the software was the target rather than the business.

10. Something to keep in mind… O The system itself might be the wrong solution.

11. The why to the what to the how. 6

12. Soup and a Slice of Pie O Why = Nourishment O Scenario 1: Bring a spoon because we know we want to eat soup to nourish the body. O Scenario 2: Bring a fork because its something to do with dinner. Results: O Drink from the bowl as a workaround (still meet the why). O You need to eat the pie because we already chose the fork (miss the why, miss the target).

13. The Business Target = the Why O If you are asked for a how, trace back up to the business target O Determine how you can support what the business needs to achieve the reason why the software is even needed. O You might return to a different how. O The why to the what to the how.

14. Case in Point: Data Warehouse O We need a data warehouse. O OK, here it is. O Now its worse, the data isn’t real time, and now its just in one more place. O Something went wrong.

15. Case in Point: Data Warehouse O Why do you need a data warehouse? O To make our data, which is all over the place, more usable and accessible. O Why do you need your data to be more usable and accessible? O To analyze up to the minute trends and correlations across datasets so that we can respond rapidly to events. O If we could make this happen by virtually bringing the right data together, might this be a possibility? O Sure, we don’t care how, if we can analyze the data to rapidly respond.

16. Something to keep in mind… O Many “hows” for any “what” O WHAT: Get to east coast. O HOW: Plane, train or automobile. O WHAT: Manage schedule. O HOW: ??

17. Software “parts” don’t organically build to the best business “whole.” 5

18. Case in Point: Race, Ethnicity & Health Disparities O Separate systems O Separate race, ethnicity & health disparity data O = Data you can’t correlate & analyze effectively O Select the race you most identify with vs. select all that apply O Ethnicity = Hispanic (y/n) (per OMB standards) vs. Country of origin

19. Business Architecture O Build a part to a target in the business that is part of the right business whole O Aligned goals across and through enterprise (the “big why”) O The “big what” O Data: Enterprise standards and a common vocabulary O Process: Integrated and collaborative business capabilities

20. What happens if you build to a little what without a big what? O Might cement O Misalignments of goals O Redundancies O Processes with cross-purposes O Silos O Processes that are not optimal O Data that doesn’t synch O Business processes and rules that no longer work for the business

21. Hey, I’m not the business person or the customer! O Sure, we want the “best business whole.” O But, whose job is it any way to build the best business whole? O Deliver value-added software engineering: O Opportunity to shine the light up (the how up to the what up to the why). O Radiate to all the what touches. O Radiate to all the why touches.

22. Questions Radiating from Why O Now that we’ve defined the purpose or goals of this effort, what higher level business goals or strategic directions is this effort in alignment with? O I.e., why do we want to achieve the goals of this project? O Can you think of any higher level strategic directions this effort might be at odds with? O Are there other efforts or sister project that are part of achieving similar or higher goals?

23. Questions Radiating from What O Now that we’ve defined the scope of this effort, are there entities, processes, or systems with which this effort must integrate? O What are the entities, processes or systems with whom we exchange information or materials from within our scope?

24. Agile software development does not mean you shouldn’t be mindful of architecture. x

25. Radiate to all the how touches O Avoid an accidental architecture O Building the little how right doesn’t mean the big how is built right O Anchor yourself to build the little right thing that fits in the big right thing O Anchor yourself to build that right thing right that fits in the big right thing built right O …then, be Agile.

26. What does architecture have to do with business analysis? O The technical architecture should support the business architecture. O The big how supports the big what which supports the big why. O If the business desires to break down silos, develop synergies and share information, the technical architecture should not create barriers to doing so. O Forrester Research: Our children will laugh at us for separating business from technical architecture.

27. A Recap: Anchor to the Right Thing O Pull piece of domain O Define why and radiate to all the why touches O Define what and radiate to all the why touches O Move as-is to to-be O Anchored in the right thing…

28. Anchor to Build it Right O Pull the corresponding technical architecture that supports this business component O Refactor architecture as needed given understanding of the right thing and all it touches O …anchored to build it right. O Now, be free to be Agile.

29. OP + NT = EOP 4

30. To-Be or Not To Be O No question, need to-be before introducing new technology. O Old processes + New technologies = Expensive old processes O Risk: May freeze in: O Workarounds O Inefficiencies O Redundancies O Processes that are not optimal

31. Drink the Soup O Let’s purchase mugs for our soup because our customers currently drink the soup. O Or, let’s purchase some spoons because customers wish to eat, not drink the soup.

32. Case in Point: Government Application O As-is government application process O Data flow analysis discoveries O The to-be O Sequential workflow O Concurrent workflow

33. The Right Thing Targets the To-Be State O Build to the to-be state O It can be painful (and expensive) to move from the as-is to the to-be while building the software O Did the requirements really change or did we not allow for a shift to the to-be before we started to build? O You can be agile and iterate against the to- be state

34. Software can enable & “improve” the wrong thing. 3

35. Case in Point: The Art Gallery Contains copyrighted material © 2010 Advanced Strategies, Inc. www.AdvancedStrategiesInc.com

36. Current Physiological Model Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

37. Building Current Logical Model: Deletions and Changes Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

38. Current Logical Model Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

39. Building the Current Essential: Steps 1 - 7 Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

40. Building the Current Essential Model: Midpoint (After step 7) Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

41. Building the Current Essential Model: Steps 8-14 Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

42. Current Essential Model Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

43. Building the New Essential: Items to Delete Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

44. New Essential Model Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

45. Building the New Logical: Additions Methodology copyright of Advanced Strategies, Inc. 2009. All rights reserved.

46. New Logical DFD Methodology copyright of Advanced Strategies, Inc. 2009. All rights reserved.

47. Building the New Physiological Model: Additions Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

48. New Physiological Model Methodolgy copyright of Advanced Strategies, Inc. 2009. All rights reserved.

49. Without analysis… O We might have optimized the estimates when they should have gone away.

50. We don’t want any to-be, we want an optimized to-be O Takes analysis skill O Takes asking the right questions O Takes using the right techniques O Takes communication with the business O The business may or may not have this skill O The business analyst may or may not have this skill O The developer may or may not have this skill O Remember: Value added software engineering

51. Agile software development does not preclude upfront analysis. x

52. Option: Plan Driven & Then Change Driven O Get to the to-be and then be agile. O Plan-driven analysis phase followed by a change-driven development phase.

53. Plan-Driven Analysis to Change-Driven Design & Development

54. The Backlog O Analysis outside a software development project. O “Work the backlog.” O What are the pros and cons?

55. Something to keep in mind… O …before introducing new or improved technology, no matter how cool, make sure you are in the to-be space.

56. Be a business partner not an outsourcable IT group. 2

57. Hang your own rope. O Hey, I’m not the business person or the customer! O When you know what you want… O Let us know and we’ll code it. O It’s the business’s business to determine what they need.

58. Value-Added Software Engineering O Bring a skilled business analyst into your software development team O Be a skilled business analyst O Wear multiple hats O Work effectively with a skilled business analyst on the business side (or in between the business and IT)

59. Analysis is Inevitable O …whatever the case, analysis is inevitable. O Don’t O Just do analysis after the fact to figure out what went wrong. O Make your world only about the how. O Do O Be a business partner. O Understand the why to the what to the how and all that the problem radiates to in the domain.

60. Software should propel the business forward, not hold it back. 1

61. Case in Point: Hard Coded Form O Desktop application built to match an application form. O Form changed. O “We can’t add those questions for a few months.”

62. Analysis Paralysis: Can you do too much? O Yes and no, it depends. O What level of risk brought about by unfinished analysis is acceptable? O Can you study a problem so long that the problem and the world changes in the meantime?

63. Case in Point: Multiple Task Predecessors O The missing single cardinality fact O Far-reaching fallout

64. Can’t technology discover new ways to do business? O The how can inform the what and the why, but be careful O Propel the business forward, don’t hold it back O Business innovation can be found in technology O Technology can constrain or limit business innovation

65. Quiz & Questions

66. quiz O Put these in order of what should drive what… WHY WHAT HOW

67. questions O What state should a business domain be in before introducing new or improved technology? O What state is a business domain typically in when new software or enhanced software is requested or desired? O Why not say, when you are ready, let us know?

68. How does analysis fit in? O When developing software, where does analysis fit?

69. Disciplines Involved: Gated vs. Iterative Approaches O Definition O Analysis O Design O Development O Testing

70. What is analysis vs. design? Contains copyrighted material © 2010 Advanced Strategies, Inc. www.AdvancedStrategiesInc.com

71. Analysis Techniques O Business data flow diagram O Business state transition diagram O Business entity relationship diagram

72. Business Data Flow Diagrams O Documenting facts O Reengineering O Decomposition O Use cases O Information identification to build into data model

73. Contains copyrighted material © 2010 Advanced Strategies, Inc. www.AdvancedStrategiesInc.com Business State Transition Diagram

74. Business Entity Relationship Diagram O Build a common business vocabulary

75. Exercise & Demo: Data, Process & Event O Sally sells seashells by the seashore. O What information might she keep about which objects and which transactions? O What processes might she use to sell her seashells? O What are the states a seashell might be in and which events make the seashell change states?