I love Logical Data Models. I strongly believe that if you want to understand how to maximise the use of the data available in your company, that you need to outline your business rules. In my mind, the best way to do so is to develop your Logical Data Model (LDM).

What is an LDM anyway?

Techopedia defines a logical data model as follows:

A logical data model (LDM) provides a detailed overview of the entire set of data created and maintained by an organization. It is a diagrammatic presentation of the organization’s data and its representation is independent from the underlying database technology.

The key points to absorb from this definition are that an LDM:

1. Represents your company’s data
2. Shows data that is generated as part of your company’s business processes
3. Is a visual representation of your company’s data
4. Is independent of the database that the data is captured.

The realities of the LDM

Often, the reality that you may face is that your company does not have an LDM. There may be a general understanding of the data generated and the relationships, but time has never been taken to understand the “big picture”.

An important reality of the LDM is that it does not always represent the final way in which the data is actually stored in the company. Data may actually be stored across multiple systems, or when you review the data stored in the database, it does not look like the beautiful illustration that was shown to describe what happens in the business. That’s okay – it does not have to. Often the final database is designed for optimal performance. Entities used to explain concepts may physically reside in the same table.

Consider your company – data is generated via various processes and systems that support the business. Data may not neatly reside in one database. For this reason, I believe LDMs become even more important to your company. Why? Because beyond illustrating the data that resides in your company, it shows your company’s business rules.

Business Rules? What Business Rules?

A business rule is a basic definition or constraint about how a business operates. As such, the answer to the rule is either ‘True’ or ‘False’. An example of a constraint is, ”My company can only sell to persons over the age of 18”. An example of an operation is, “I can have one valid contact at a time with a company”.

Business rules allow you to state what your business does in simple statements. The focus is on the major entities that are key to your business, and the relationships that exist amongst these entities. The entities are key business concepts that are fundamental to your company, a common example is your CUSTOMER.

LDM example

To illustrate how your business can be represented by an LDM, here is a description of a business and how it can be represented.

My company has two areas of focus, carpentry and plumbing. I only provide my services to individuals (versus companies), and I only hire persons who are specialists in one service or the other.

Based on this statement, what are my business rules?

1. There are two services offered, carpentry and plumbing
2. Services are only provided to individuals
3. An employee is a specialist in one service
4. An employee can only serve individuals who require the service for which they are a specialist.

Figure 1 is a simple illustration of these rules. Not all the data elements that would be used by a company to define that business concept (entity) but sufficient to confirm the relationships.

Figure 1: Simple LDM to illustrate business rules (Source: L Ramcharan-Briscoe)

How can my business rules change?

1. I can offer an additional service, Electrical Work
2. I can offer services to companies
3. I can hire employees are specialists in at least one service

Figure 2 illustrates the updated data model would look like.

Figure 2: Updated LDM to illustrate the updated business rules (Source: L Ramcharan-Briscoe)

(Please note: The importance of the illustration is not to give a crash course in data modelling but to provide a visual on how changes to your business rules impact the additional data that becomes important to your business.)

 Reverse Engineering

Often, where a company finds itself having to reverse engineer its LDM. This happens because the business rules are a part of the organic knowledge, and no formal documentation has been put in place to collect that knowledge. If there happened to be documentation, as a result of a project, often no process has been put in place to keep the documentation current.

This may seem a little abstract, but let’s consider reporting. When data needs to be gathered for reporting purposes, typically there is a huge effort to collate that data into one place. Ideally, a central database is the starting point. When an LDM does not exist, a person or team is tasked with the job of “putting the pieces of the puzzle together” to ensure that what is stored actually reflects the business.

Parting thoughts

Creating an LDM can be time consuming. The more processes your company has in place, the higher the probability that you have many relationships and entities to consider. Take the time to create your logical data model. Validate it with both business and technology. If used correctly, it allows changes to how your gather your data to become significantly easier, and any change in business process that affects your business rules can then be more easily translated into how you collect your data. Data is Queen! And gathering it effectively keeps you in charge of your queendom!

Image credit:  geralt (Pixabay)

Although this is changing, one of the greatest challenges that you face as a data management professional (or as the person responsible for making sense of the data for your company) is convincing your company about the importance of data. As a result, putting the necessary infrastructure in place for data to be effectively and efficiently captured, and used, can be difficult. Many do not understand that when done right, quality data can actually directly improve the company’s bottom line. This is where it is important for you to show “quick wins”. 

It is a journey

When it comes to data, the reality is that companies, with a focus on building their business (rightly so –the core business pays for everything else) often do not place attention to how data is captured, stored and used in the business as a continuous chain, thus appreciating the interdependencies. There are some assumptions naturally made. For example, that the customer service representative who is capturing their customers’ email addresses will always pay close attention to entering the email addresses correctly in the company’s customer management system during that telephone call. Or from another perspective, that the customer, who is actually the contact person for a key client, will always stay with that company or in that position during the lifetime of their relationship with their client.

Why highlight something as simple as an email address? When you need to send an important update to your entire customer base, and you rely on email addresses, having the right email address becomes critical to your success. Often, the customer service representative does not see that correctly collecting customer details, in this case, an email address, affects the company’s ability to build a business relationship with that customer.

When you consider data, and how it is captured, it is a journey to map it out for your company. This becomes more involved as your company grows, and no attention has been paid to managing data. Hence, when you do stop and take the time to explore your data, it can look as if you are trying to summit a mountain like Mt. Everest – complicated and riddled with numerous challenges – and as such, it makes it seem like it is impossible to complete.

How is it managed?

Let’s consider what that journey ends up looking like when you want to get an end result for your company. The larger your company, the more likely that conquering your mountain morphs from being a simple project to a complex program that is comprised of many projects that have interdependencies. This unfortunately means that you can be looking at 5 years before your company sees all of the benefits. But it does not have to be so: that is why “quick wins” are so important.

In my last article, the concept of a “green field” project was raised. Although the challenges faced in your journey to improve the management of data in all organisations remain the same, the individual activities and initiatives required for your company to implement the project can be quite unique. For these kinds of “green field” projects, it is important to have “quick wins”

 The importance of “quick wins”

In identifying the requirements for your data project or program, there may be some “low hanging fruit” that you can harvest. Having conceptualised your project or program, based on properly captured and well-considered requirements (at least as best as is collectively understood at that point), you can develop a proper plan that outlines how to move forward. In developing your plan, you may discover that there are some activities that you can quickly implement, even though the project itself may take 5 years to be completely implemented.

If we develop our email address example, you might decide that you can quickly implement a campaign that encourages the customer service representative to validate the email address that they have on file when a customer calls in. You might consider implementing a simple update to the application used to capture the email address that validates the format of the email address being entered by the customer service representative. These activities may take a couple of months to develop and execute, but you may see immediate results by the reduced number of rejected emails, for example. There are metrics that you can identify and use to measure success.

You have a “quick win” so momentum is not lost. The company, in the case of the improved email addresses, sees an immediate result that has a positive impact on business productivity. The “quick win” also promotes the company’s understanding of what your innovative data project is trying to achieve, and so you have an opportunity to increase the excitement for, and the desire to, support the project. This can even result in your requirements for the project/program becoming more robust.

Business pains and quick wins

With “quick wins”, a couple of the key criteria you should be looking at in identifying them are:

• Do they eliminate a business pain?
• Can they be resolved in under a year?

My simplistic definition of a business pain is that it is an issue within your company that tends to get a lot of attention. If one of these is linked to a fundamental flaw with the capture and use of data, and you are able to quickly resolve it by improving data, you can well appreciate the momentum that would be gained for your project if you were the one who solved it!

Parting thoughts

When you are working towards improving the data in your company, it takes time. The larger the company, the more time it may take, based on the considerations that were first put in place to capture data. However, it is still your unique journey. Surprisingly, data does not excite everyone in the same way, but you can gain their appreciation by quickly showing the benefits through “quick wins” with a focus on solving business pains that keep the senior management team up at night!

Image credit:  Pixabay (Pexels) 

There is a song that goes, “Do you know where you’re going to, do you like the things that life is showing you, where are you going to? Do you know?” For your project, your requirements tell you where you are going to.

Learning #2: Spend time on your requirements

The dictionary defines “requirement” as “a thing that is wanted or needed”. You will find that most development methodologies emphasize the importance of spending time on the requirements – the actual needs of your project, whether building software using the Software Development Life Cycle, as shown in Figure 1, or developing the Business Requirement Document for your project.

You will find variations of the model in Figure 1, but this is the one I “grew up with”, that emphasises requirements as the first step. I was even shown a pyramid version of this model with the same steps, but going from large to small, from Requirements to Testing, to emphasize that the more time that you spend on your requirements, the less time you spend on the other phases. Depending on the unknowns and the complexity of your system landscape, it may not be considerably less time spent, but it certainly becomes an easier process.

Figure 1: Software Life Cycle (Source: L Ramcharan-Briscoe)

Time effectively spent on developing the requirements allows for a certain level of agility in making changes. There was a project that I worked on where our requirements would have cost 4 times the amount that the business had budgeted for it. Creating budgets before understanding our requirements is another discussion, but that often can be the reality of a project. The good part of the story is that we had spent so much time outlining the requirements, that it was very easy to identify the areas that we could eliminate.

In my last article, I mentioned the importance of knowing who my stakeholders are, and this is one of the many areas in your project where knowing who they are becomes important. For this project, approving changes to the requirements was very simple because our requirements were clearly defined and we knew which stakeholders would be affected by the changes made. We had already spent about 4 months on the project and we were able to approve the changes in less than 2 weeks.

Figure 2: Project Phases (Source: L Ramcharan-Briscoe)

Figure 2 shows the project development methodology as defined by the Project Management Institute (PMI) when considering a project. These project phases are high-level and can even be replicated within the stages of your project. The PMI, for the initiate process, defines the most important activities as “…identifying and defining business requirements, outcomes, and success criteria; defining business justification…”. These should be your starting activities to lead to a successful implementation.

Building Requirements for Green-Field Projects

A green-field project is one in which you will be charting a course that has never been traveled before by your business, or by any other business for that matter – if you consider an innovation (a brand-new idea). There are no completed projects that exist, where you can benefit from the approach used or the lessons learned.

For this type of project, it is even more important that you spend the time building your requirements. You have to capture all that you understand at that point in time and provide as much of an outline as possible. You need to list your assumptions, risks, plus what is in and out of scope for the project.

What you will find for a green-field project is that there are assumptions that you will make that may be found to be invalid or not applicable as you learn more about what you are trying to innovate. But in properly outlining what you do understand and potentially debunking them, what you have captured become starting points in outlining what the requirements actually need to be, and what changes need to be made.

Parting thoughts

When you know where you are, if the winds of change come your way, it makes it easier to understand the impact the winds could have, and how you may need to re-chart your course. This does not always make it easy, but it certainly supports a more systematic approach to solving your problems and moving forward with your project. Requirements, either fully developed or that allow you to frame a good foundation, definitely help you know where you are going to, and eventually can be used to determine whether you have reached your final destination.

Image credit:  Eluj (Pixabay)

As an individual who studied and worked in Software Engineering, I have always been enamored with the concept that technology is for the end users – to make their lives easier – to allow them to focus on creativity instead of repetitive, time consuming activities. When I see a tool that might be likened to a “4-car garage” being used to house a tricycle, I am less than impressed.

A couple of years ago, I was interviewed about my experience in data warehousing, and it was a poignant reminder for me of how much I enjoy data and what it can do to help a business. I was inspired to share what I have learnt from my data journey thus far and started doing so via LinkedIn. Now I have been given the opportunity to share my learnings with you via ICT Pulse. Join my adventure!

Before you can begin your data journey, you need to understand who should drive that journey and who the participants need to be for it to be a success.

Learning #1: Business should always drive technology

I recall one of my projects where we were adjusting the point in the process where a product could be sold. Reports needed to be generated to assess the effectiveness of the change. The architecture that supported the existing reports, was a mismatch of systems. Data came from various systems that were not fully integrated. This also meant that developers had to manually support the process. As such, making updates to that platform to incorporate the business’s needs was quite expensive. Making the changes necessary to generate the reports in that environment was literally throwing money away that the business did not have to invest, plus based on the benefits, not worth the investment. There needed to be a larger investment in the architecture instead of another “patch” to the existing infrastructure. Further, there were other ways that the business could get the results that they needed, perhaps not as fancy, but it would be sufficient to manage the product.

Be sure to understand the end user’s actual environment before building and/or making technology recommendations for the potential solution.

Technology is to enhance business. I love technology but business should always be the driver when it comes to the adoption of technology and the appropriate application of said technology. Ensure that the recommendation truly matches what is required to avoid distraction and users feeling overwhelmed.

And who is your end user?

The end-user is the final consumer of your product or service. You need to identify the people who will use this end result – including the persons who will provide the support for it.

For example, I recently signed up for a new application that allows easy access to my child’s school records. When I went into the school office to inquire about an irregularity with the records, the local school office administrator was not exposed to the application. No training was provided to administration, nor were they shown the application as part of the application rollout. Therefore, the administrator had no context to support me with my problem. This was not an upgrade to an existing application that parents and administrators were already familiar with. Shouldn’t it be obvious that parents would ask the school office if they encountered any issues?

Even in considering your end-user, you should consider your stakeholders – who are the people who are impacted by your application either directly or indirectly. Hence, as part of the stakeholder analysis for the school records application, local school office administrators should be identified as a group of persons who would be directly impacted when the application is fully implemented. Why? Because a parent will always have the expectation that the school knows everything that affects their children.

If in analysing the stakeholders, you realise that there are people who do not directly influence how you design your service or product, make sure that you have determined whether or not they do need to see, or otherwise interact with, the end result. For the local school office administrators, they should have been identified as a group that had to see the application, understand the limitations of its use and at minimum be able to provide some level of guidance to inquiring parents or guardians. Instead, a parent can be left slightly frustrated and the administrators feeling insecure.

Parting thoughts

As much as I love technology and new ground seems to be made almost daily, if a business cannot operate optimally at its core competency and make the money that it needs to turn a profit, or at the very least be sustainable, then they cannot be expected to make a heavy investment in technology. The technology has to be appropriate to the expected benefits, and therefore, return on investment. Let’s not try something new because there is a new toy on the market. The needs of the business should drive technology. Let the innovators keep developing the new technologies, but recognise that there is not a one size fits solution to anything.

Also, keep in mind the persons who are impacted by your product or service. When it comes to data, it is always your business but remember who else is involved. Finance? Accounting? Marketing? Take the time to analyse and understand the impacts. But remember, you don’t need that 4-car garage if you are starting with a tricycle. Don’t rush, get it right.

Image credits:  PublicDomainImages (Pixabay);  Pixabay (Pexels)