A Bottom-up Approach to discovering Governance Issues
by Rick Jelliffe
So the approach I am suggesting is that as well as the top-down approach, there also can be a bottom-up approach where you invert the question so that we ask "Given that we have these technical artifacts (e.g. XML), what information can we extract from them and what issues can it be used as evidence for?" In this way, we come up with a list of the issues for which there can be objective evidence, and management can cherry pick the issues which are useful,
One case-history I gave was of a markup operation who installed context-based full-text indexing system. They started using it in an entirely different way to the way we had expected: they went through the list of words that had been marked up as keywords and then looked for every instance of that word where it wasn't marked up as a keyword. This allowed them much better consistency.
But taking my bottom up suggestion, it also can be used as a governance input: the technologists first report "It is possible to get evidence (a measure or metric) of the words that have not been marked up correctly" which then allows the managers to trace to or add the business requirement "All keywords should be marked up" which in turn leads us to the governance requirement "How to you prove that this business requirement that all keywords should be marked up is being met?"
Things like the Extensibility Manifesto may help formulate useful issues for governance, but it is top-down. And the trouble with top-down is that sometimes tracing from issue to evidence peters out or stalls on the way down: a fine sounding abstract requirement that is unmeasurable. Now this is, of course, the basis of many of my company's tools and my work on validation and metrics: concentrating on the possibilities that XML allows for evidence gathering, and then trying to progress this upstream to management questions and the governance issues.
Roger Costello has been making a series of "best practice" papers on Schematron over at XML-DEV recently. While these are very important to think about and to gather intelligence about, in a sense bests practices represent a kind of middle-out or context-free approach, which I think can be criticized because abstract statements of principle move away from the worlds of evidence (at the low level) and governance (at the high level). For example, at the moment there is a discussion on whether it is better to embed Schematron schemas in XSD schemas or to have separate documents: a good question. (I have posted to say "well what about XSD types inside Schematron rules too?")
But my main comment was that perhaps whether a constraint is bundled with the grammar is kept independently should perhaps follow organizational lines: database people can look after static kinds of storage requirements, and analyst people can look after the business rules -checking. It may be that dividing constraints between schema documents should be based on who is looking after them. Now this would correspond to a management requirement "A separation of concerns should be implemented to reduce the intra-organization dependencies on data and applications." And the relevant governance question would be "How do you prove that you have a separation of concerns in your data and schemas?" And the evidence would be to trace from each constraint in a schema to the driver for that requirement, and showing that a particular schema only has traces to a requirements set by a single organizational entity.
So in summary the bottom-up approach starts with technical artifact (e.g. XML) then finds out what it can evidence ("what can I measure?") , then extracts potential management requirements which could be analyzed using that evidence, which then suggests possible governance questions. The bottom-up approach never descends in airy-fairy handwaving or impossible to implement abstractions: it seems a practical approach. The result will be partial: if you start with XML as the artifact you will get "XML Governance" issue raised. And the issue of "What can I measure?" leads directly into the worlds of complex validation (e.g. Schematron) and the need to develop good metrics in general.
Here is one to consider. Even if we can trace it to a single entity, if we set up the constraints without due attention to the relationships, we still have trouble.
|Len: But the bottom up approach is based on what can be evidenced from an artifact: so you probably would expect de-identified documents to trace to different managerial and governance issues than documents with more data. I am not trying to say that XML-based inference of management and government issues will generate a complete set of issues, just an evidence-based set.|
And I agree with that. I'm not being clear.