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
6 Comments
1. Data Analysis is closer to Business Intelligence than to Business Analysis. Both DA and BI are not listed in BABOK. These are disciplines that require specialized training and thinking.
2. Some BA’s can do DA and BI work, if they arose from the technical ranks. However, more likely as BA’s they are the bridge between the Business and the DA or BI group.
Enjoyed your blog, nevertheless, Ali…it still is a conundrum worth debating.
Cheers !
Here’s to the data! Many BAs tell me that they don’t document data because they view that as the responsibility of the technical team. My question to them is always “Does the technical team meet with the business SME to elicit the data requirements?” The consistent response is “no.” So how does the technical team know what data is appropriate/relevant? What relationships between the data are needed to make business decisions? If data is documented without input from the business, the resulting solution often requires workarounds due to improperly defined data. Involve the business from the onset and avoid costly workarounds! Who better to elicit data needs from the business than the BA?
Olya Broadwell
Sr. Instructor, B2T Training
Thanks for stating this in the blog, Ali. Sometimes as BAs who have been doing this in our practices, we tend to forget some of the things at the core of what we do. Just like processes, rules, and actors, data is one of the core components we need to understand as we go about our jobs and elicit and capture the requirements.
Thanks for bringing us back and putting it into words.
As Ali mentioned, understanding the data is central to understanding the Business Process and associated business rules. The question as to levels of role responsibility is where should the BA draw the line in relation to data analysis and definition.
I typically look for the BA to work at the logical level and leave the physical level to the DBAs and Developers. The analysis by the BA focuses upon object and attribute identification, logical definition and business rule relationships. Context Diagrams, Data Flow Diagrams and ERDs are all good aides in the analysis, but I learned to be careful about putting ERDs in front of Business SMEs.
In one analysis meeting I put my ERD on the screen to demonstrate to the Business SMEs and managers in the room that the data relationship they were seeking was not possible given the lack of a unique identifier between two important objects. While I made my point and received my answer, the Managing Director present commented with an obvious derogatory tone, “That must be an IT thing.” I learned an important communication lesson during that session. While ERDs are still an important analysis tool for BAs, I employ simpler approaches during discussions with the non-technical members of the project team.
I agree with you Doug – I rarely put an ERD in front of the business. I use the ERD to help with my own analysis, to ensure I ask good questions about all of the data business rules, and to ensure that those business rules make sense and don’t conflict with each other. I find I ask more intelligent, deeper, more meaningful questions when I have that structure to back me up. And I find that my data requirements are better structured for good testing. And let me be clear – I think the BA’s role is to elicit BUSINESS data requirements (hence he/she would produce a business / logical ERD), not technical data requirements, which should be left to a good data architect. Thanks for the feedback!
I agree that BAs need to be knowledgeable about Business Data and that BAs need to perform data analysis. At a minimum, BAs must perform analysis of the messages (data) and/or business data entities that are in scope. Questions similar to the following need to be answered: what data is included in the event that triggers a business process/workflow? what business processes are impacted by a new message/new piece of data or a change to existing messages/data? what can happen to the data as it travels through the business process/workflow? what interfaces does the data travel through? It’s great when BAs have the skills to analyze the data further (ERDs, conceptual data models) because this helps to ensure requirements are accurate and complete earlier in the Software Development Life Cycle (SDLC).