By Laura Brandenburg, CBAP Lesson Objective: After completing this lesson, you will understand the role of data modeling in the business analysis lifecycle and why it is important for business stakeholders to be involved in data-related decisions. DATA MODELING DEFINED Imagine yourself going up to the checkout counter of your local convenience store. You have 5 items in your cart that you put, one-by-one, onto the conveyor belt. The clerk scans each item into the checkout system. The checkout system tallies your total amount due. You pay for your items and are given a printed receipt. Behind this every day process is an incredible amount of data. First, each item you purchase has a record in the checkout system that identifies its price. The price is most likely linked to a unique identifier for the product and was provided by a product management system. Second, your collection of purchases gets tallied together as an order, which includes a set of items and a total amount due. Third, once you pay for your item, the system might store transaction information such as the payment method and, in the case of a credit card payment, a transaction ID provided by a merchant account to validate that the necessary funds are available. Come to think of it, your credit card also has a record that is stored in a variety of different systems, with associated information such as your card holder name and available credit information. http://www.mybusinessanalysiscareer.com Page 1 of 15
Once the transaction is complete, the checkout system may send a message to the inventory management system so that the store s purchasing agent can keep tabs on when to order more of items that will soon be out of stock. And we haven t even dealt with coupons, refunds, sale prices, multiple instances of the same item, sales commissions, customer loyalty cards that identify you with your purchase, or information known about the clerk processing your order. Information, or data, lies behind every business process and every software system. When as business analysts we specify requirements for new systems, we will nearly always touch the data. When we model, clarify, update, and improve business processes, we need to understand the data that business users receive, input, and report out on. Data modeling is a set of techniques and models that are used to define and analyze data requirements, to ensure the data managed by information systems supports the business processes executed by stakeholders and functional requirements executed by software applications. You do not have to be a technical person to understand data or to complete basic data modeling tasks. You do not need to be able to write SQL queries, model physical databases, or create data storage systems. You do have to be logical, analytical, and able to understand the role data plays in a process to be able to model data effectively all traits of a good business analyst. http://www.mybusinessanalysiscareer.com Page 2 of 15
DATA MODELING FOR BUSINESS ANALYSTS In this course, we are focused on conceptual and logical data modeling, the kind of modeling and analysis that will help you clarify requirements by gaining alignment on key terms and concepts, how those concepts relate to one another, and what kinds of details the business needs to manage about each concept. We will go as deep as understanding the fields in a data storage system and how to define them. For example, you will learn: How to communicate that an item can have one and only one price (if that s the case for your information system) and that the price needs to be specified in a numeric or currency format. How to specify the source of the pricing information, whether it s internal to the organization or comes from an external information source. How to specify translation rules, such as that although the pricing information comes from an external source in UK pounds, it needs to be translated to US dollars and that the currency translation process needs to meet specific requirements. You will not learn how to create the translation tables, build the logic to transform the data, or load the data into the database. Those are database developer responsibilities, not business analysis responsibilities. You will learn how to give the database developer a well-organized collection of information that makes their job easy (relatively speaking), makes them glad that you are their business analyst, and ensures the business stakeholders are making appropriate decisions about how to organize the data. This is the kind of analysis that helps you become known as someone who can resolve tricky project challenges (or avoid them in the first place), and do what it http://www.mybusinessanalysiscareer.com Page 3 of 15
takes to get business and technical stakeholders on the same page about requirements. Like with any analysis technique, one of the first things you want to do is define your objective. Let s turn our attention to the reasons you may want to model data and how data modeling techniques fit into different project scenarios. BUSINESS REASONS TO MODEL DATA As you can see with our example scenario of a customer checking out at a convenience store, data modeling is not purely a matter of technical design. Many business decisions are made when it comes to deciding to how to put together databases, and that means that business stakeholders should be involved in the decision-making process. Typically it s you the business analyst who helps the business stakeholders make those decisions. Here are a few scenarios where lack of business involvement in the data decisions could have led to missed requirements cropping up late in the project lifecycle: Late in testing, we learn that there isn t just one price, but there is a manufacturer s suggested retail price and the store s current price. A new field needs to be created, a new user interface screen with business logic needs to be created to update this field, and several software functions need to be updated to use the new field instead of the original single price field. After finalizing the database design, we learn that the database developer s decision to assign each item a unique identifier within the local store management system conflicts with industry standards which base everything around a centrally managed identifier. The design needs to be updated to accommodate this new identifier and use it as a primary key for several tables. http://www.mybusinessanalysiscareer.com Page 4 of 15
During user acceptance testing, we learn that each order must be associated with a customer service clerk so that we can report on productivity metrics. Although a relatively simple change, updating the database and check-out functionality delays the implementation of the project. Of course, there are many ways to discover these requirements. A mature business analyst combines business process modeling, functional requirements modeling, and data modeling to look at a set of requirements from all possible angles and ensure no stone goes unturned. Data modeling techniques are one aspect of business analysis that will help you ensure your requirements are clear and complete, and that business stakeholders are making the important decisions about how information technology systems are designed to meet their needs. Specifically, data modeling techniques will help you ensure the database structure of information systems will support business information needs, and that data gets transferred between two or more systems in a way that will make sense to business users. A QUICK LOOK AT THE DATA MODELING TECHNIQUES Now that we understand what data modeling is at a high level and why it s important for business analysts to get involved in data modeling, let s take a quick look at the different data modeling techniques commonly used by business analysts, all of which are covered in more detail in subsequent course lessons. Glossary First, there is a Glossary. A glossary is a deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all http://www.mybusinessanalysiscareer.com Page 5 of 15
stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization. In its essence, a glossary is a list of terms, with accompanying definitions, and is not unlike a dictionary. However, a glossary is more specific than a dictionary because it only covers terms that have a unique meaning and use in the context of your project, team, or organization. A glossary gives you the secret code to communicating with a specific group of people. On the surface, a glossary may not seem like a data modeling technique. However, if you don t start with a common language, you are likely to experience many challenges when you start modeling data, as you won t know how to communicate clearly about your business concepts. Your glossary is your touchstone for the terminology that is used in all the rest of the data modeling techniques. Entity Relationship Diagram (ERD) Next, let s discuss an Entity Relationship Diagram (or ERD). An Entity Relationship Diagram (ERD) is a data model describing how entities (or concepts or things) relate to one another. When created by business analysts, ERDs can be used to understand the business domain, clarify business terminology, and connect business concepts to database structures. Essentially, a conceptual or logical ERD will visually show how the terms in your glossary relate to one another. They are especially helpful in clarifying information models for relational databases and helping business users understand database structures at a high level and without details. In the lesson on ERDs, we ll cover the different levels of modeling and the different aspects of an entity relationship diagram. You ll also receive a quick crash course on relational databases, just in case this is an unfamiliar concept. http://www.mybusinessanalysiscareer.com Page 6 of 15
Data Dictionary or Data Definition Matrix A Data Dictionary provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values. While a conceptual or logical Entity Relationship Diagram will focus on the highlevel business concepts, a Data Dictionary will provide more detail about each attribute of a business concept. Essentially, a data matrix provides a tool that enables you to communicate business stakeholder requirements in such a way that your technical team can more easily design a database or data structure to meet those requirements. If you ve been wondering what to do with long lists of fields inside use cases or other requirements documents, you ll be happy to learn that they have an ideal home in a data dictionary. In the lesson on data dictionaries, we ve included a crash course on data normalization as well, which is essentially the process for standardizing the data that is input into an information system, and manually or technically manipulating data so that it conforms to data standards. Data Mapping Specifications Finally, we get to Data Mapping Specifications, which are a special type of data dictionary or requirements analysis tool showing how data from one information system maps to data from another information system. Data mapping specifications are useful when migrating from one system to another. When mapping data, it s often important to step back and take a high-level view of how the data flows or how systems talk to one another. In the lesson on data mapping specifications, you ll receive a crash course on creating system context diagrams which is a simple analysis technique for clarifying system boundaries and how data flows between information systems. http://www.mybusinessanalysiscareer.com Page 7 of 15
PROJECT SCENARIOS FOR DATA MODELING Now that we ve discussed why data modeling is important from a business perspective and taken a high-level look at the techniques business analysts use to model data, let s look at how data modeling fits into a few different types of project scenarios and business analysis lifecycles. (As an aside, we cover the business analysis process here at a very high level and focus on the aspects of doing business analysis that relate to the data modeling techniques covered in this course. For a deeper look at the end-to-end business analysis process, check out our BA Essentials Master Class.) System Migration Projects System migration projects involve migrating functionality supported by one system to a new system. In today s technology climate, often organizations are migrating legacy technology systems, such as those that are proprietary and custom to a single business, to commercial off-the-shelf systems that are supported by third-party vendors. For example, an organization could replace their homegrown lead and customer management system with Salesforce.com or SAP. Another scenario is when an organization is moving from one third-party system to another. For example, at the time I am writing this course, I m evaluating changing shopping cart systems. During systems migrations, there are many steps in the business analysis process. You start by analyzing the scope of the project and creating a business case for changing systems. The scope may include a list of key business processes and high-level features the system needs to support. At this point in the project, you might create a high-level conceptual data model (such as a glossary of key terms and an entity relationship diagram http://www.mybusinessanalysiscareer.com Page 8 of 15
to show the relationships between critical business concepts), as you want to make sure any tool you evaluate can manage the right types of information and the right relationships. Then you may evaluate multiple vendors or third-party tools, perhaps using a Request for Proposal process to receive comparable bids. Once you select a vendor, you begin working on requirements specific to transitioning your current system to the new system. Business processes get more specific. Functional requirements analysis looks at any specific customizations or configurations that are needed for your organization. From a data modeling perspective, you ll most likely complete a data mapping specification that details how data from your original system will get loaded into the new system. Of course, the actual loading of the data is a technical process, but there are important business decisions to be made, such as: Do we bring over all data or recent data? For any two fields, do they actually mean the same thing? Or, is there logic in either system that will impact how we want the data brought over, based on our understanding of the business process and functional system flow. Do all fields have a home in the target database? And vice versa? And so on and so on. Also, simply letting the technical person know how the key concepts link together will help them be much more efficient and accurate in their conversion process, especially if they are unfamiliar with your business or business domain. This might sound like a lot to consider. That s because it is. Rest assured that by the time you get through the lesson on data mapping specifications, you ll have a structured process to go through that will help you discover and resolve any potential issues. http://www.mybusinessanalysiscareer.com Page 9 of 15
System Integration Projects Another type of project where data modeling is of critical importance is a systems integration project. Unlike a system migration project, where one system is being replaced by a new system, a system integration project results in two systems working together to support a business process. For example, the Bridging the Gap shopping cart system that you used to purchase this course integrates with both PayPal and a third-party credit card processing system for accepting payments. It also integrates with our virtual course delivery system to ensure that new course participants are automatically set up with access to their course content. Behind each of these integrations is you guessed it data. On a project like this, your business analysis process might flow as follows: You might start by creating a system context diagram to clarify how the different systems pass data back and forth. Then you might evaluate your current business processes and any manual steps that result from a lack of system integration. For each system that is part of the overall solution, you might create a data dictionary to specify the type of information contained in each data source. Then, as you look at each specific business process and how the systems integrate together, you might complete a data mapping specification to evaluate how data is passed from one system to the other. System integrations and migrations are two more complex types of projects in which data modeling techniques are absolutely essential. However, even on what might be considered to be a simpler project, you can benefit from using selected data modeling techniques. Let s look at an example for a new or updated software feature. http://www.mybusinessanalysiscareer.com Page 10 of 15
New or Updated Software Feature Relies on Data A very common business analysis scenario is to spec out a new software feature, whether for a customer-facing project or for an internally used system. Let s pick a very simple example this time, one that specifically does not involve integration with other systems. (Although system integrations are so common that when writing this lesson, I had to sit for a few minutes to think hard about a realistic but simple example.) I did find one, however, so let s talk through it. When I go to my local chiropractor, I check in using a software system. I provide a unique identifier and then proceed to list any areas of pain that I d like the chiropractor to address during my appointment. The system shows me a picture of the human body, divided into different zones. I select the part that is bothering me and answer a series of questions about the pain, such as how frequently it occurs, how severe it is, and what treatments make it better or worse. For the sake of an example, let s say that I am the business analyst working for the product development team that builds and updates the chiropractic check-in system. Our chiropractors have been letting us know that patients would really like to be able to select multiple zones at once, especially when zones are near each other or overlapping. As a product development team, we decide to allow patients to multi-select specific sets of contacting zones, but not select multiple zones all over the body. It doesn t seem to make sense to provide information about your neck pain and foot pain together, for example. But it does make sense to select the three different parts of your lower back, or your hip, and tailbone. http://www.mybusinessanalysiscareer.com Page 11 of 15
When specifying how the new multi-select feature would work, we d need to make some very specific data-related decisions. The zones are already defined in our existing data model, but now we d need to identify what zones could be selected together and how the other information is collected when multiple zones are selected together. On a project like this, your business analysis process might flow as follows: First you create a high-level conceptual data model captured as an entity relationship diagram to show how the new concept of a multi-select zone relates to our existing concepts. Then, you add a new term to your glossary for multi-select zones. And finally, you evaluate your data dictionary and indicate the allowable values for when multiple zones are selected at once. Business Intelligence / Data Warehousing Now that we ve seen how data modeling applies even on smaller projects, let s turn our attention to the mega of data projects, the data warehousing or business intelligence project. These projects are specialized versions of system integration projects. Most often, a business intelligence project involves creating a centralized data store of all information a business manages for the purposes of enabling intelligence-driving reporting or better business decisions. Organizations use one of many third-party tools to create the data warehouse, manage the relationships between all the data, and enable business users or technical report writers to create and automate a wide variety of reports. http://www.mybusinessanalysiscareer.com Page 12 of 15
The data modeling aspect of your business analysis process might flow as follows: You might start with an entity relationship diagram that describes the highlevel business concepts that are critical to your business intelligence effort. Then you would likely create a data dictionary for each data source to be added to the data warehouse. You most likely would need to individually map each data source to the data dictionary for the new data store that is part of your business intelligence system using a form of our data mapping specification. Along the way, you are likely to experience conflicts in business terminology that can be captured and resolved using a glossary. In addition to understanding the data modeling techniques covered in this course, you ll need to be an expert (or quickly be able to become an expert) on the business intelligence tool the organization has selected. You also need to understand more about data warehousing, physical database models, and best practice approaches to these types of projects. WRAP UP AND NEXT STEPS We ve talked about what data modeling is, discussed why we do it as business analysts, reviewed the data modeling techniques we ll be covering in this course, and looked at how those techniques fit into different project scenarios. Remember, this is the how to get started lesson. It s the 30,000 foot view of data modeling so we can all get on the same page as to what s covered in this course. In the next set of lessons, you ll be learning how to use each of the techniques to clarify your business and data requirements. Along with each of those lessons, you ll receive work samples and templates so you can see what data models look like. http://www.mybusinessanalysiscareer.com Page 13 of 15
Before we do that deep dive, please take a few minutes and consider the types of projects you are working on today and the challenges you deal with that could be improved by data modeling. Common examples include: Difficulty communicating clearly between different business stakeholder groups or, especially, between business and technology stakeholders. Misunderstandings about functional requirements that get discovered late in the project lifecycle. Migration or integration issues that go back to understanding how the business creates, updates, and maintains the data. Data modeling techniques might help you solve these real world problems and add even more value to your projects. We re going to be getting down and dirty. I ll be doing my best to keep things light, engaging, and share realistic examples, but there are some parts of data modeling that simply require you to be your best detailed self. Keeping the end result in mind will help you stay focused and see the value in the details you ll be learning If you are going for the Certificate of Completion, take a few minutes to log a few of your ideas in your workbook. Specifically, consider how at least 2 of the data modeling techniques identified in this lesson might help you address specific project challenges. This isn t just busy work, you ll be taking these ideas and building them out into real-world examples to cement your learning as you work your way through the rest of the course. Even if you are not yet a practicing business analyst, you ll receive immense benefits from tackling a work-related domain. However, if you are not currently working or volunteering, consider a personal domain where you experience any type of communication challenge. http://www.mybusinessanalysiscareer.com Page 14 of 15
Although there is no grading as part of this course, give yourself a bonus point for talking to a stakeholder about data modeling techniques. For example, you might ask a business stakeholder about what aspects of the data in their current systems frustrate them or you might ask a technical stakeholder what datarelated information they would benefit from receiving as part of the requirements effort. Until next time, this is Laura Brandenburg at My Business Analysis Career. Copyright 2015 My Business Analysis Career All Rights Reserved. http://www.mybusinessanalysiscareer.com Page 15 of 15