lunes, 6 de diciembre de 2021

Java inheritance on the way to business terms glossary.

 


Now we are hearing in many places about “getting data of value” and “monetizing data”, that data should be managed, from business perspective, as an important asset. Nevertheless, when advising organizations with these objectives in mind, we find that they are a long journey from reaching them.

We find many obstacles like power-silos, unawareness of data value, and a breach between IT and business areas. These lead us to a generalized lack of knowledge on data. Organizations do not know at a good level:

·                What data they have,

·                Where are the data?

·                What does data men?

·                Who owns the data?

·                What we do on data?

·                For what purpose are data being used?

·                Can we trust data?

·                Who can see or modify the data?

·                What else can we do with our data?

Without some level of this knowledge is almost unfeasible to get any business value from data. The answer comes with an initiative that will look for become an ongoing program: data governance. After some time, data governance initiatives or programs can help organization to answer these questions through data literacy, data catalog, data quality, data lifecycle management, data integration, master data management and reference data management, among other disciplines.

Depending on organization needs, expectations and data management maturity level, data governance provides several starting points that we can map to the above disciplines. If the problem is lack of trust in data, data quality can be the beginning of data governance. If we are a regulated enterprise, data lifecycle management can put the company on the way to data governance. But these options are mostly technical, and may prevent us from connecting business areas with data governance.

From all the starting points, business terms glossary is perhaps one of the most effective artifact to involve business areas with these initiatives, usually perceived as “ethereal” in some way, by business people. Ideal option is to acquire a software tool with a repository and features for collaboration, as well as functionalities for allowing business people to actively participate in discussions, and for ensuring at some level the compliance with glossary. Nevertheless, these tools are not precisely cheap and it is hard to get the money if business people are not engaged yet in the initiative. Some organizations start with spreadsheets and documents like that, but they are tabular and cannot represent properly the complexity of the first versions of business terms glossary. Different and divergent meanings and usages ask for a more flexible tool. This article discusses if Java inheritance and polymorphism can help us in this task.

Let’s say we have a must-no, but so-frequent problem in organizations. What do all we understand by the more important term in our business? For example, the meaning of customer is the same All we do understand the same

Let me tell a sad but true story. Long time ago, we built an integral system for a private university, with the purpose of replacing a lot of tiny systems and programs, developed with ancient technologies, dispersed and sometimes with contradictory data. Our brand new system had a nice user interface, modern technology and, the most important, a unique database for the whole university, so we could say good bye to contradictions in reports. We were happy and so the users, until the dean asked a simple question:

         How many students do we have?

 

Simple, not? Easy, not? But suddenly, Students Affair sent a number, Academics one slightly different, and Finance a third one, distinct from the previous. Dean call me to his office. He was a tempered man, but that day he looked nothing comfortable.

 

         You, engineer, told me that we won’t see these discordances anymore, because we have a unique database.

         And that’s true.

         Then, what’s going on?

Reviewing the numbers, we discovered that every area had a particular definition of “student”. Hence, the reports were developed according to these definitions and, of course, numbers vary from one to another. It would be easy to impose the term most liked to the dean, but it would put some distance from the areas that disagree with the imposed term.

On the other hand, the meetings for discussing the definition will get business areas to data governance initiative. They will feel comfortable in a place where they voice and vote in all data-related decisions. Again, as data people I would to buy a data governance software, but it was hard to get money for a no inventoriable thing if they are not engaged with the initiative yet. Spreadsheets are used some times, but their tabular format it is not suitable for a structure like this:


 

We have several definitions from different areas. We draw only two for simplicity sake, but there will be as a much as interested areas we have. In the process and in the light of discussions, some areas will adjust their own definitions, given rise to several versions per area. Even when all areas arrive to a common, converged definition, we can refine definition thru several versions. Maybe, we can try it with a spreadsheet but remember that functional areas do not only define the term “student”. They also associate actions with the term “student”, and that is the value for them. Finance can associate payRegistration(), payTuition() and sendInvoice(). On their side, Academics can associate submitDocumentation(),          applyExam() and so on. It is going to be hard with spreadsheets, like using a screwdriver for pounding down a nail. Maybe, we can made it, but there are better ways. For example, Java classes inheritance.

We can model this structure with objects for every version of the term definition:

The Java code for this class will look like this:


This will be the superclass of our application and we can instantiate several objects for the same business term, as much as areas and its versions. We can write different classes for every area, and even for every version. But that is exactly what the organization was doing before and the main reason of the divergence. Every area defines terms apart from the others. We can take advantage of class inheritance, one of the object-oriented paradigm main features and available in Java. First, we need a business term for student that inherits all attributes and methods from BusinessTerm class:



 

In this case, student term can be coded this way:



Then, we can have a more specialized class for the specialized objects that will model every area and version definition. This class will inherit all attributes from StudentBT class and, accordingly, from BusinessTerm class too, as we can see in the following diagram:



The code for the new class will be like this:

 



With a code like this, we can manage the business glossary in a very flexible manner, ensuring all voices are listened and tracked. These classes can help us to carry a business terms glossary before buying an expensive software, engaging business people in the data governance initiative. Of course, we need a persistent record of this, a database, but that’s part of the following article.