Mark Flaherty (MF): I am going to show a little bit of a picture here, because what we said is that we have got the same business terms that are being used. We have got the same structures that are being used or different structures, etc., but how do we map all these things together? And from a conceptual standpoint, the first thing that we might want to look at is, what are the business terms that are being used and what’s the context of those business terms?
What’s the business term? How is it being used? What's its definition? How is that mapped with a data element concept, and how does that data element concept get materialized in different data elements that are associated with conceptual domains like states and associated value domains like the specific two-character representation used by the postal service to represent states?
So we look and drill down and do our analysis into what we already have. We can get some mapping or some visualization of the underlying structures, so that we can see where the relationships are between uses of business terms, where the uses of those business terms are consistent and where they are not and then what types of structures are being used within our application and their corresponding data sets associated with the uses of those particular business terms in those particular context.
#1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index |
|
Read More |
We can look at this in a little more detail by building up our representative model. We can then map it to the existing infrastructure, what we already know about how the applications rely on their data. So in this slide, we are looking at a specific mapping of a business. It might be a social security number, and here we see that there are two uses that actually are representative of the same underlying definition. It's the definition of the social security number, but it's being used in two different data elements with two different structures.
But we know given our visual representation that those two things actually refer to the same underlying concepts, the same data element concepts, and that you just got two different data element representations. But what that says is that if we have got data policies, or if we have got business rules that refer to that concept, or in fact, to that business term within that particular use and that particular definition, then all of a sudden, we are able to get some visibility across our application infrastructure to see where the actual data structures exist that are impacted by any changes to business rules or any modifications of the structures etc.
In order to do this analysis, we need to have a process. At least from a high level, we have a got a representative process that is 5 steps. We do an analysis of what we have got. We synthesize some results or some view of what we have seen as a result for our analysis. We can then map that back to what we already know about the current state of the application infrastructure. We can publish that back out and that provides us with a model of the environment, and we can call this information rationalization. It is our process.
In fact, when we think about this, our complexities are really all our issues associated with variability or variance. But the variance isn’t from the data itself. It actually comes from the model because if we started out by looking at building our environment from the bottom up and looking at our data element concepts and then looking at what applications are using them, or what business processes rely on them. We might be a little more proactive in sharing the same representation.
|
Read why choosing InetSoft's cloud-flexible BI provides advantages over other BI options. |