Business Analysis The Key to Building the Right Software LeAnn Simonson, CBAP LeAnn Simonson Consulting, LLC

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

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

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.

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

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.

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

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.

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.

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

The why to the what to the how. 6

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

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.

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.

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.

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: ??

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

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

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

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

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.

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?

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?

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

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.

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.

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…

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.

OP + NT = EOP 4

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

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.

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

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

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

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

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

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

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

Building the Current Essential: Steps Methodolgy copyright of Advanced Strategies, Inc All rights reserved.

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

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

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

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

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

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

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

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

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

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

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

Agile software development does not preclude upfront analysis. x

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.

Plan-Driven Analysis to Change-Driven Design & Development

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

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.

Be a business partner not an outsourcable IT group. 2

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.

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)

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.

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

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

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?

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

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

Quiz & Questions

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

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?

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

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

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

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

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

Contains copyrighted material © 2010 Advanced Strategies, Inc. Business State Transition Diagram

Business Entity Relationship Diagram O Build a common business vocabulary

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?