The slides for my talk at the Sydney Open Publish conference last Friday “XML Governance and Publishing” are up now at the Conference website.
The topics include some of the governance aspects of the Extensibility Manifesto, and the management aspects of XML Metrics, which I didn’t have a chance to treat in depth due to time. This talk got an ovation, which is always nice, especially because the first time I presented similar material at a seminar a few days earlier it was greeted by stony silence :-) Not in the slides is material I made actually doing metrics on the leading contender office document formats: ODF, etc. I don’t want to present those yet, because presenting it has commended some improvements needed in the metrics. I have been upgrading Topologi’s Complexity Detective tool to give some of the extra metrics.
The trouble with metrics, or at least the devil that is in the details with them, is that sometimes what is a carbuncle in one situation that adds complexity can, if used systematically, be a tool of reducing complexity. For example, in the Cyclomatic Complexity metric used in Java, some naive implementations count the statements in a switch as adding complexity, when in fact they are structures just as much as functions are. In the case of the office formats, they each adopt a particular pattern (Microsoft is quite deep, ODF uses references) which probably needs to be coped with by metrics to get a truer picture.
Very useful. Many thanks!
Some fail to recognize the cycling interference problems of interoperating networks of information providers. If development is fed by product planning who are fed by industry managers who are fed by sales being fed by proposals being fed by distant committees determine the choice of schema technologies without introspection, lock in is fast and almost irrevocable until the high costs are noticeable across the information domains. Complexity tests applied early and often act as a sniffer for trouble. While it is true as Einstein said to "make it as simple as possible but no simpler", knowing is a matter of checking repeatedly across the lifecycle.
These tests are feedback controls over a development process that can be extended over very long and deeply nested cycles, in other words, as soon as the committee issues a draft, as soon as sales makes a recommendation, and when it arrives in the development shop until it goes out as product.
Nice work, Rick, as always.
"Complexity tests applied early and often act as a sniffer for
trouble." Well put, Len.
Keeping complexity as low as possible and applying other governance tools as mentioned by Froody make a difference to market share. As a service commoditizes, the forces acting on it begin to equalize and the service is in a market lagrange point wheere switching costs approach zero. The QoS numbers for sustainability and authority begin to invert but at the lagrange point, small difference make a big difference in keeping the business. Given an SOA offering, savvy vendors protect their business by protecting the resources for their resources. This attention to QoS is a win-win for the vendor and the buyer.
Good article, Rick. I recommended it to the Intergraph Architectural Board before leaving. (OFFTOPIC: My intergraph email address is no longer valid. Use my home email or blog page to contact me).