In the previous post in this series about Open IGC (https://dsrealtime.wordpress.com/2015/07/29/open-igc-is-here/), I described several use cases to get you thinking about how you might apply this technology to your own solutions. I have since encountered several other great use cases that I will discuss in future posts — but for now, let’s dive into one of them that has already been discussed: Messaging Systems.
A Messaging System or environment is a unique case of Source and/or Target. It’s not quite a “file”, although it can “contain a file”…nor is it the same as a Table. Queues have “data” but they also can store other things, and have lots of other qualifiers, such as persistence, message types, and read methods. There is an implied hierarchy in a messaging system, but it isn’t the same as a subdirectory with files or a schema with its collection of tables.
Governance covers many things, and queues and queuing systems certainly qualify as objects worth governing, depending on your specific needs. Queues and their accompanying objects may require Stewardship, Application and Term definitions, and can carry operational information, such as Current Queue Depths, or historical status’. Queues certainly can and should participate in lineage and impact analysis reporting, as they are often the “beginning” or the “termination” of a lineage “flow”.
All of these unique qualities justify the application of “Open IGC” to my Messaging System. I also should consider “volume” and “available skill sets”, but for now let’s assume that I have a significant number of messaging artifacts to justify the work effort, and the skills in xml and REST to get it done.
What will it look like for my users? What can I do with it once it is defined with Open IGC? (click on any of the images to see them “up close”)
Let’s see what the finished result looks like in the Information Governance Catalog (IGC). Once we register a new set of Object types (we call this “registering a new bundle”), the objects appear within each regular and expected context of IGC. I can browse the new Objects:
I can assign them to a Business Term or other relationships:
…use them in a Query:
…and have them participate in Data Lineage Reporting:
The bottom line is that I can use them as I would most any other object that is part of Information Server, including Stewardship and integration with Rules and Policies. The fact that I am able to give these objects their own structure, their own properties, and their own icons, makes their use for governance more inviting to the user community and more understandable by everyone. This helps encourage adoption and participation in the governance framework.
Once the new bundle of object types is registered, I can populate the repository with actual instances. The brief lineage picture above gives you an idea of how objects of this messaging bundle participate in lineage analysis, but we can also review their details. Here is the detail page for one of the Queue Managers, showing just a few of the properties that have been modeled with this bundle, and populated for our environment:
The Open IGC also provides a paradigm for including “Operational Metadata” in a one:many relationship that makes it convenient to include run time statistics or other details of your processes that may be important for your governance scenarios. Here you see how queue statistics might be captured and stored for later review:
This is a simple implementation. I am not representing a complex process, with inner subtasks [we’ll get there in a later post], yet have created a new set of objects that more clearly illustrate an important concept for the enterprise. Governance adoption can be simpler, and will bring aboard a new audience whose needs have been met with custom objects, icons, and relationships. Data lineage is supported with known tooling, using Extension Mappings that are already in use by other parts of the governance team.
Next post we’ll take a look at what is required to define new bundles like this and to load up new instances of metadata into the Information Server repository!
Next post in this series: