Blog: Dan E. Linstedt

« System of Registries and your Master Data | Main | Step closer to nanotech hardware »

System of Registry (SoR) what does it mean?

In the interest of SOA, and on my search for governance lately, I've been looking at System Of Registry (SoR) and what it means. If you've got an SOA project, or would like to build one, or maybe you're looking at Master Data Management (MDM) or metadata stewardship, or data stewardship then you might be interested in understanding basic registries and systems of registries.

In the SOA/EII world there has been a lot of buzz about SoR and what it can provide, some vendors offer software to answer this call, and state that their SoR software helps you build a complete solution when it's integrated with other efforts. What does this mean? How can an SoR help you? Why would you want one?

SoR (System of Registry) can be likened to a Taxonomy or classification of information. There is a good reference definition for UDDI and Web Services SoR here. For example, given a Ferrari, or a Mustang, or a Chevy Malibu, these are all in a class called "cars." If you were to construct a location (search) service, you might setup a class for searching cars, trucks, motorcycles, and so on. Each of these classes is it's own SoR, and when combined under one label: Search for Motorized Vehicles, you've got the start of a master taxonomy (master classification).

By adding specific makes and models, and production years you can break each class into respective and locatable physical items. This helps complete the taxonomy (aka: System of Registry). It's very much like the Windows "Registry" that keeps all of your programs running and organized in such a manner that Microsoft Windows can reference them.

What does a SoR do for EII and SOA, and ETL, and EAI or any integration platform for that matter?
The SoR is responsible for housing (at a minimum) the following elements:
* Name
* Class
* Business Description
* Date/Time of registration
* Active / Inactive
* Accessibility (Security/control/allowed access)
* Encrypted
* Keyed
* Defined Inputs
* Defined Outputs
* Availability (when is it available)
* Last time it was updated
* Version

These are just a few of the basic components embedded in an SoR (specifically for SERVICES). Integration Services should provide these basic components no matter what; it's all metadata, but important metadata. Some of these elements are "protected" metadata and can only be accessed by authorized parties. Of course there's always the HISTORY of the SoR - when it was accessed, who accessed it, what the inputs and outputs were.

So how can an SoR help you? Why would you want one?
An SoR can help you organize, classify, and manage the metadata across your organization. By the way, the ultimate working Requirements Document is in fact - a System of Registry!! Interesting how that works out, it just so happens that in order to meet governance and compliance - an SoR of business requirements can be of tremendous help, see my upcoming series on Governance in the Enterprise for more information. The SoR helps manage a multitude of access points and data elements from within an easy to use classification system. It saves on the bottom line of implementation costs, rework costs, management and risk reduction, along with a few others.

So what about an SoR for SOA/Web-Services?
Well, SOA is architecture - an abstraction, not a product. There are products within the SOA definition, but a product is NOT an SOA. See my article here for more info. SoR for Web-Services will track the above list and more. It is vital (if not critical) to combine the SoR implementation with compliance and governance initiatives, this will provide longevity to the SoR and keep it from "going out of date" or falling out of interest with the executive staff of the organization.

As web-services are vast and numerous, and the grain can vary from service to service, it is wise to develop a classification (taxonomy) to manage, organize and maintain the web-services, the SoR can help with that. A central SoR should be:
* Web Enabled (management, updates, and additions)
* Flexible (based on security for management)
* Autonomic in Discovery of undocumented web-services across the enterprise
* Visible and understandable all the way to the board of directors (they may choose to look at only the classifications)
* GUI Driven with Icons, and definitions - single click drill down
* BONUS: Visualization of the classification, number of elements registered, and number of elements "active" with frequency graphs.

Whether you're starting an SOA "project", building an MDM strategy, creating compliance and governance initiatives or integrating your Enterprise Warehouse with your active data warehousing strategies, it is considered a best practice to build an SoR along the way. My company specializes in bringing best-practices surrounding these types of efforts, and can help you kick start your projects. Avoid the pitfalls, and don't re-invent the wheels.

What are your thoughts about SoR? Do you have any comments about specific software in this area? What do you like / dislike about the software?

See you next time,
Dan L

Share: