I was considering a much more elaborate post regarding patch management as a whole, but I realized that it would probably make for a better article – considered, planned, pointed and edited – than a ‘blog post.

So let me just point out something I deal with today, that in fact consumes the vast majority of my paid hours at work: compensating for inconsistent data in shared databases.

Most major enterprises have some sort of “data architecture” or “schema architecture” or “data standards” groups which are intended to ensure data consistency and promote reusable software products. These teams are generally attached to application development departments (from my experience.) They don’t usually look past application development to the great wilderness of the ad-hoc user application.

Thanks to companies like Microsoft, the average information worker has a remarkable – even revolutionary – set of tools at hand. These tools enable the end user to craft applications to suit immediate needs without the hurdles and expense of engaging the in-house application development team. Without these ad-hoc tools, many of your end users would never be able to leverage the computing power they need to streamline mundane tasks. Formal application development is a substantial undertaking, and few businesses have built sanctioned frameworks that enable such ad-hoc computing within a managed environment.

Even when formal processes are followed, many data architecture teams are focused exclusively on “data warehousing” projects, which are not always leveraged for applications which aren’t considered part of the core warehouse mission.

To stress my point: Data architecture standards are extremely important for the efficiency of your entire IT operation. Never mind that your architecture team spends most of its time worrying about standards for packaging or pricing data! The architecture team should represent the single source of schema for any application undertaken by user or developer alike. Ensuring consistency in schemas across a business concern will ensure that paid employee time has a measure of efficiency and reusability and does not contibute to a data silo culture.

How do you ensure that employees, working alone with Excel or Access, maintain respect for enterprise schema standards? Well, it isn’t easy.

First, every employee who has broad access to computing resources should be trained on corporate computer use. This is rare! Only two of my employers, Gartner and GlaxoSmithKline, had computer training. These corporations wisely invested money in introducing new employees to the resources provided by IT and some of the expectations that went along with the offering. However, getting senior management to agree to mandate computer orientation for new hires is difficult to say the least.

Second, every self-respecting company should have an internal “employee portal” website. This provides the employee with a single entry point to all available resources on offer. My current employer (who shall remain nameless,) provides an outstanding portal – tying together service requests, nearly all Human Resources services (including online information and payroll management,) corporate news and limited collaborative forums. I’m hoping to see more collaborative development, but they’ve achieved the most in my experience.

Relevant to our discussion, the Employee Portal must also guide the employee to policies and standards. One of our tasks as information security professionals is to ensure that policy is communicated to the employee. It follows that computer standards should be treated in a similar way. The end-user is then aware of resources available from IT, which leads me to my next point.

Third, data architecture groups must maintain an online reference of standards, examples and a means to collaborate with the architecture team for small projects. This may involve something as simple as email, or preferably a collaborative forum where an end-user can review previous efforts and avoid mistakes or leverage existing “tribal” knowledge.

In short: Make data standards self-service friendly. Architecture teams will continue to engage large projects, but by making standards accessible to the end-user or small project developer – you’ll have a greater probability of compliance and a bigger bat to wield when they don’t comply.

The benefit to the business emerges with more interoperability between applications, less time “wasted” in single-use projects, and better efficiency. It will take less time, for example, to connect two datasources on a whim. Many great ideas come together without a plan, and enabling your employees with equally flexible technology has vast untapped value even now.