metadata intertwinglement: the next IT revolution

The plasma from Tuesday's exploding brain is still expanding. I've been putting a lot of thought recently into applying Best Practices in IT to firms that traditionally don't support a mature IT department, namely post-product startups. They are generally crying out for some degree of IT rigor to supplant a more or less 'organic' evolution of their infrastructure. Doing IT triage on a 50 - 150 person engineering company has some very specific challenges in addition to the norms.

First, the concept of Best Practices in IT is, itself, still evolving. A body of knowledge in taxonomy has been gradually building up, but the field grows more quickly than the taxonomy. Attempts to apply a Patterns-based approach might be successful, but still suffers from a technology/tool bias. Distilling the taxonomy into 'pure' functions is a sticky business, and one which can be disheartening.

Second, any Practices identified need to be scaled appropriately for the organization. Models like SEI's CMM can apply different standards of rigor based on different needs for rigor. A corresponding model for IT has been on the minds of many of the leaders in our little field, but has not matured to the point of any kind of draft being kicked around informally.

Today, I realized that we're all on the wrong track. Hopelessly. Remember the Conduit Model of IT, proposed by yours truly back in the late 90's? Everything becomes Conduit. Dialtone. The baseline. And what's happened while we weren't looking is that *every single piece of IT technology* has become conduit. It's not exciting. It's not central. It's reactive. And what is it reacting TO? The DATA.

I believe that sysadmin, to be successful, has to be DATA centric and FUNCTION centric. If you follow the data, the workflow, or both, you can conflate traditional silos like 'backups' and 'storage management' and 'remote access' into the true job at hand: treating the data as the enterprise requires, and providing the resources that the enterprise requires.

To illustrate this, let's talk about your roof. It's leaking. Or it might be leaking. Or it might need to be prevented from leaking. Hmm. What to do? Let's apply some 'rooftop management' principles.

If we talk about rooftop management the way we traditionally talk about systems management, immediately we start dividing the practice of rooftop management into 'trusses', 'power tools', etc. If we generalize from 'power tools' to 'fasteners', then we start to admit the possibility of composite glue-intrinsic materials. We can barely comprehend the idea of a sod roof, with roots growing through a chickenwire frame attached to the outside of the vapor shield. Is that 'fastening'? We completely ignore the possibility of integrated spraycrete rebar structures, incorporating load-bearing intrinsics.

What if we approached rooftop management from a functionality standpoint? We want to control environmental factors such as light, temperature, and weather input. We can explore 'roof solutions' rather than going down a predefined set of paths that preordain certain types of tools. What is going to make the most sense for our building needs?

If we say "underlayment, topcoat, maintainance schedule", then we have to take special care to ASK things like 'will there be snow load?' or 'does there need to be overhang to shade windows?' or even 'are we in a hurricane zone, and thus need tie-downs?'. If the question is asked 'what weather inputs do we need to consider?' then the functionality emerges naturally.

This is a vast shift in IT thinking. Traditional enterprise has been coming around to workflow-based thinking, finding that it is easier to get repeatable quality and process in that paradigm. IT has not even begged the question, and it's high time. What's the question? Could metadata be integrated into common office (and engineering) applications, and a data workflow be defined for enterprise data based on tagging?

Policy could be set by tags and those tags could define the retention, storage, and access policies for any document (code, visio, .doc, whatever). Tags would also carry permissions natively, including ability to inspect or alter tags, whether revisions must be kept, etc. This allows a CRM approach to native OS tools, as long as the tag-mediation plugin was working. Could be a nice repurpose of some of the nasty DRM stuff that is hitting our hard drives and removeable media at the chip controller level!

Obviously, sole reliance on this would create a stunning set of loopholes through which one could drive a suitably ginormous truck. Data/tag defaults would need to be set by data handling applications, and a document which is untagged would acquire default tags based on various things. Tagged descriptions (access, owner, etc) would be compared to native handling descriptions (atime, mtime, owner, etc) and discrepancies flagged. Thus the entire system becomes data-driven and self-policing. Certain exploits which rely on inserting files or permissions into the system, would be defeated by an inconsistency between cached tags (for key system files) and extant tags. Failure to work cryptographic signatures conceptually into the metadata model would, of course, be unthinkable, but throwing ourselves to the PKI alligators is not productive at this time. There's a place for authentication models in embedded metadata. Let's leave it at that for this instant.

This dovetails nicely into a data-driven, function-driven model of IT as a management process whose function is to achieve data/function-specific SLA's for various enterprise workflow processes (development, mgmt, admin, sales, etc). It also more or less forces a data interconnection model that will allow different functional organizations within an enterprise to access the same basic reference material: sales needs to read engineering's specs, for instance, and sometimes to comment on them directly ("annotation from Bob: I have a customer who really needs xyz, can we get it into this release instead of abc, which no one seems excited about?")

Obviously there is a LOT I'm leaving out of this overview, but you've got the bare bones of it. I think it's the next generation, the future, and the only sustainable model for evolving IT into a needs-based practice rather than an arcane cult of tool-centric 'Packers' and 'Mappers' (to use Geoff's insightful labels, cf his excellent LISA99 presentation). Collaboration, commentary, and constructive criticism invited. Ad-hominem attacks, to recycle an old tagline of mine, 'will be replied to in kind, only with more wit and verve.'

Let the games begin!