I find myself running into a lot of business analysis professionals who say “I don’t do data analysis. That’s the job of the data architect”. My response…”What?!” In a nutshell, a good business analysis professional understands the business and helps the business solve its problem by making sure the business processes and rules are correctly implemented in a solution.
Let’s decompose this last statement.
- What is a process? A process takes inputs and adds value to them via some identified activities to generate outputs.
- What are business rules? They are the constraints a business implements in order to be successful.
- What is a solution? In an IT environment this usually means the solution involves an information system and the users and workflow involved in using the system.
- What is an information system? It pulls and pushes Data (the term Information System contains the word information, information is data, hint, hint). A good information system provides timely, correct data about the business so that the business can make decisions that will drive the business’ success.
What is at the core of all of this? Data. Without correct, timely data, a business will not have the ability to make good business decisions. Period…end of story.
In my experience, a deep, clear knowledge of the information that a business uses and the relationships between that information is the best way to really understand the business. Processes can and do change, but data is relatively stable. If you understand the data a business uses to run itself, you can really get a good understanding of that business and actually help the business better understand what it does.
So what can you do as a BA professional to get a good understanding of the data a business uses? There are several approaches but I typically approach it following the four steps below.
- In project scoping, I make sure I understand all of the project’s interactions with the ‘outside world’. This means identifying all interfaces we think are going be necessary for the solution to work. To help me and the project executives understand these interactions, I typically build a context (dataflow) diagram. This diagram is a great high-level picture of the complexity of the data interactions on a project. It gives me the original sources of the information the solution will need to run effectively as well as the final destination of the data the solution will produce. These sources and destinations will have representative stakeholders from whom I will need to elicit more details.
- Also in project scoping, I identify the high level business processes that the project will be affecting or creating. This gives me a good idea of how many processes will be effected and how complicated they appear to be. For those processes that seem complex, I break them down into the activities (or low level processes) that make them up so that I have a better idea of how to estimate effort.
- Having the processes and context diagram from steps 1 and 2, I now have a great picture of the processes and data I’ll need to get more detail on and the stakeholders from whom I need to elicit the details.
- As I begin analyzing the processes and data flows from steps 1 and 2, I start to build my data model. I use the time-honored technique of using an Entity Relationship Diagram (ERD) to see the data entities with their detailed data and relationships. The data relationships are hugely important as they are the data business rules that drive your business. Asking good questions about the data will bring out business rules that might be missed if you just concentrate on the process workflow. As more questions are raised and answered, the data model becomes robust and complete.
What is the result? You end up with a full, deep, clear understanding of the data on which the business runs. Now the data architect has the information needed to build an efficient, effective database that contains the data and relationships to match the business needs. The business areas in which you are working end up with a better understanding of what they do. You move beyond the BA that is just an order-taker and become a valuable, crucial part of the project and the organization as a whole.
I challenge and encourage you to become a business analyst that DOES do data!
To the data,
Ali Ibarguen, B2T Training Sr. Instructor
- #AskAnAnalyst Podcast Episode 27: Remote Agile Team Success - March 23, 2017
- #AskAnAnalyst Podcast Episode 26: Are BAs Becoming Obsolete? - February 28, 2017
- #AskAnAnalyst Podcast Episode 25: State of Agile - February 7, 2017
- #AskAnAnalyst Podcast Episode 24: An Agile Mindset - January 27, 2017
- A Monthly Guide to Becoming a Better Business Analysis Professional - January 11, 2017
- #AskAnAnalyst Podcast Episode 22: Business Analysis in 2017 - January 10, 2017
- #AskAnAnalyst Podcast Episode 21: Business Analysis in 2016 - December 8, 2016
- #AskAnAnalyst Podcast Episode 20: Effectively Give and Receive Feedback - November 15, 2016
- #AskAnAnalyst Podcast Episode 19: Live from #BBCCon - November 3, 2016
- #AskAnAnalyst Podcast Episode 18: More Business Analysis Basics - October 4, 2016