CHAPTER 17
Governance and the New Normal

Soon after your first few successful projects you will need to begin to consider how to pivot to this being the new way to do things. You may find yourself swamped with internal demands and in need of some stabilizers. This section is about how to start the transition to the new normal.

The new approach becomes “hot”

We’ve seen several variations on this. Sometimes, as with the Standard & Poor’s case study, executive management edicts that all other divisions are to adopt the new Data-Centric approach. This can totally overwhelm the small group that was chartered with supporting their own division.

Sometimes, as with an Investment Bank, we’ve been working with, word gets out that this new approach delivers impressive results, rapidly. New initiatives are launched to replicate the success in other divisions.

In either case, whether by edict or by appreciation, this is what is predictable: there will be projects launched without the requisite thoughtfulness and planning, and these projects will create the equivalent to Gartner’s hype cycle. Some of the projects will be launched with the aim of reproducing the results of the first few projects will do so with limited experience and produce disappointing results.

The executive’s role in piloting the change

If you find yourself in the position of the executive who is associated with the change, and therefore for propagating it through the enterprise, you are faced with some tricky positioning. You may be tempted to single thread new projects through your organization, which now has a track record of implementation. But this will be frustrating for two reasons: you will not have the capacity, and others will literally want to do this themselves.

What we have seen to be more effective is to build an internal consortium. This can be modeled on industry consortia. The difference between a consortium and a typical enterprise project, or even typical enterprise governance, is the volunteer nature and the lack of command and control structure. In this case, the consortia can be built around the notion of sharing. This will be sharing and extending models (ontologies) as a way to promote integration; it will also be about sharing actual data. By federating queries and using some shared ontologies, we can finally get past the insane practice where every application has many redundant (but differently structured and named) representations of the same corporate data (e.g., products, customers, orders, trades, vendors, employees, or departments)

Finally, the consortia can come together to share best practices. This is a new undertaking for most enterprises, so there will be many opportunities for learning and reporting on lessons learned.

A kinder/ gentler voluntary governance structure

In many firms, “Governance” has a bad name. It is often seen as a necessary evil, something imposed from on high that you must conform to. It is often blamed for delay and unnecessary bureaucracy. And if you were to suggest that you are implementing “governance” on your own, you will likely get visited by someone from corporate who will inform you, “We can take it from here.”

As a result, you may not want to call what you are doing “governance,” even though it is. Once you get a few projects in the Data-Centric mold, and you have a consortium in place, people are depending on the stability and availability of the core model. Therefore, you have to have some procedures in place that look a heck of a lot like governance. What these processes will share with traditional governance is a desire to manage change.

The art of progress is to preserve order amid change and to preserve change amid order.

Alfred North Whitehead

One of the differences is that in a traditional environment, change is hard. If any change manages to make its way through the budgetary and other hurdles, it must be reviewed to make sure it doesn’t break anything. In the Data-Centric world, we are trying to encourage change, and certainly, the technology makes a certain level of change much more feasible.

However, as you can imagine, the combination of higher rates of change plus more integration and dependency does offer up some challenges for governance. The next couple of sections suggest a few techniques that can make things go a bit better.

Good, better, best

One of the things that happen once this approach becomes dubbed the “new normal” is everyone hops on board and attempts to emulate as best they can, but they really aren’t very good at it. This has happened with most of the improvements in IT over the last decade.

The original data warehouse wars were between the Kimball approach and the Inmon approach. Each offered insightful design and guidance on things, such as “conformed dimensions” (ways that data warehouses could share “rollups” for things like geography or product families). I think the lead methodologists for the Data Warehouse movement, Bill Inmon and Ralph Kimball,62 would be horrified to see what we see in data warehouses now. We have several clients who have data warehouses with thousands of tables. Not much conformance going on there.

The agile movement, described earlier in this book, has many virtues. However, in the wrong hands (and about half of the hands are wrong) it has led to runaway “cowboy coding” (i.e., letting programmers do whatever they want with little direction or accountability).

The Data-Centric approach will no doubt suffer some of these same problems. We already see it. The best we can do is offer some guidance that will allow some visibility and a nudge towards doing it right.

The next couple of sections are a few ideas to steer well-meaning, but potentially rogue, groups into the light.

TBox, CBox, ABox

In Semantic Circles, the part of the ontology concerned with defining classes and properties (the closest equivalent to schema in a traditional system) is called the “TBox” (Terminological Box), the place where new terms are defined.

The “ABox” (Assertional Box) is the term for where the specific factual assertions are made. This is more akin to the instance data in a traditional system. It is the triplication of data.

We have introduced a third term and it seems to be quite popular with our business sponsors: the “CBox” (Categorical Box). This is where taxonomies and enumerated lists are defined and managed.

These are slightly awkward terms, but they turn out to be quite useful in governance discussions.

In a traditional system, there is quite a pronounced difference between schema and data. They are expressed in different syntax (DDL (Data Definition Language) and DML (Data Management Language)) and are stored in different places (the catalog, directory version, or the data tables themselves).

In semantic systems, all three of the “Boxes” are expressed as RDF Triples. They can be intermingled in the same repository, or they can be stored separately. However, the three “boxes” represent fundamentally different kinds of things, and it is helpful to have reference labels to distinguish them. This is especially the case when it comes to governance.

The TBox, while numerically simple (that is, we recommend trying to keep the number of concepts down to several hundred for the core enterprise model, and even less than that for each of the subdomains), is quite complex in its actual structure of formal definitions, and the implications for reasoning and inference can be subtle. For this reason, we recommend the TBoxes be governed primarily by trained ontologists and under the guidance of the business leaders who sponsored the terms in the first place. There should be a TBox governance committee for the shared ontology as well as one for each domain ontology.

The CBox is often numerically much larger, with potentially hundreds of categories that have enumerated types, some of which contain thousands of specific categories (the taxons in the taxonomies). After some initial setup and guidance, the CBox can and should be managed primarily by the business sponsors. They have considerable expertise in these pursuits and have been managing reference data and taxonomies for decades. There are tools such as SmartLogic, Collibra, TopQuadrant’s EVN, and Pool Party that make organizing end user management and governance far easier. These tools also have the added advantage of tying in nicely with the TBox ontology. We recommend the CBox be primarily governed by representatives of the business community who have a stake in their use.

In most cases, there will be some CBoxes that are widely shared and should therefore be governed by a central group; a larger number that are local to a domain can therefore be governed by a local group.

The ABox is typically governed by IT, and much of this is delegated either to the existing applications, or in the future to the constraint and identity management layers of the Data-Centric architecture. There must be a way to continually refresh the ABox assertions, primarily from the databases and datasets that IT manages. They will primarily be concerned with issues, such as consistent URI minting and detecting whether the same referent is being referred to using different IDs in different systems and how to resolve that in the ABox data. ABox governance is mostly about integrity management, versioning, and recency. The ABox governance leaders will also sit on the TBox governance committee, but mostly to get advance warning and weigh in on changes to the TBox that might alter ABox processes.

Share the learning

Transformation is a learning process. The firm has to learn a new set of habits and behaviors. The effectiveness of the transition will turn on how well the firm shares what it is learning as it is learning it. There are multiple strategies for sharing the learning that seem to work well in this environment. What doesn’t work as well is traditional governance. Traditional governance assumes that the firm knows the right way to do something and must police it. The firm will be learning as it transitions through the transformation, so better strategies are those that assume and encourage co-learning.

Setting up a community of practice with regular conference calls is one good way to share both the learning and status at the same time. You might be surprised how many people in your organization are already thinking this way and are just looking for some encouragement and a venue. We gave a workshop at a large German firm. They sent out a series of emails to see if anyone was interested in the new “semantic thing” and were surprised to find almost a dozen projects were already in progress (although with little coordination).

Data-centric maturity

This is an initial outline for a maturity model. I have participated on other collaborations to build maturity models, and I know it takes a considerable amount of coordination, leadership, and commitment. I would be happy to participate in such an endeavor if a firm or consortium were interested in providing the structure and leadership.

Meanwhile, the following should provide an outline of the areas I believe should be covered by such a model. We don’t yet have a fully worked maturity model but would be happy to work with anyone who would like to help develop one.

The following general categories seem to cover most of that which we would expect to be important in tracking the progression through a Data-Centric transformation:

• Organization and Policy—is the organization set up in a way to foster the transformation?
• Artifacts—does the organization have the things it needs for success, including an enterprise ontology, a graph-based architecture, training materials, and skilled workers?
• Progress—does the organization have a road map, is there a complete inventory of the current data stores, and has it been analyzed in a way that would promote eventual mapping?
• Results—are pilot projects delivering predicted improvements? Is the overall effort having an impact on the economics of information systems and the business as a whole?

Within each of these, we expect the main subdivisions to be:

• Organization and Policy

  -  Funding

  -  Executive support

  -  Policies

  -  Organizational structure

• Artifacts

  -  Enterprise ontology

  -  Training materials

  -  Governance manual

  -  Model-driven architecture

• Progress

  -  Inventory of existing data stores

  -  Datascape understood

  -  Datascape mapped

  -  Road map

  -  Staff trained

• Results

  -  Pilot projects hitting target economics

  -  Cost of new applications

  -  Cost of change

  -  Cost of integration

  -  Ease of understanding

  -  % of available integrated data

The following is how we expect most companies will work through their transformation. Most firms will start with virtually nothing. They will be in the application-centric quagmire (new projects are hideously expensive, change is prohibitive, and integration consumes most of the budget).

The first thing will often be an enterprise ontology with some executive support and perhaps followed by a pilot project.

As the idea begins to take hold, many firms will start setting up formal governance structures.

Then it will be time to start investing in infrastructure, both computational as well as organizational.

After a few ad hoc successes and as the firm begins to get on board, it will be time to take stock of the whole landscape.

Finally, as more and more of the firm converts, the results should become the main thing.

Not every firm will progress through these stages in this order, but this should be at least one reasonable path through the transformation.

Chapter Summary

After some initial project successes, you may be lulled into thinking that this is the new normal, but our observation is that firms that have created this approach as the new normal, in addition to executing successful projects, need to set up governance processes to keep the momentum going (as well as to keep future projects between the guardrails).

The key tasks to keeping the momentum going are to set up an appropriate governance program, mechanisms for sharing and propagating lessons learned, and then a measurement program.

The key takeaway for the governance process is to separate governance by type (TBox, CBox, and ABox) as well as scope (Enterprise and Domain).

The key takeaway for sharing is to set up websites, portals, wikis, and forums that allow new groups to benefit not only from the learning of those who have gone before, but also to leverage and reuse the TBoxes, CBoxes, and ABoxes that exist.

The key takeaway of the measurement program is to use key metrics to assess and continually drive toward broader and deeper maturity of the practice.