You may think that the task of teasing out the exact nature of the data and processes within a company is a boring job. Not a bit of it! It is half way between archaeology and forensic science, and I have spent some of the happiest years of my life doing it, mainly as a Data Architect. I’ve done small businesses all the way up to government departments and multi-nationals.
Is the job necessary? I disagree with Yourdon when he says that the detailed understanding of the current systems in place within an organization is unnecessary. Having been reared on SSADM, and used various other methodologies, I’ve experienced cases where a detailed understanding of the current systems has saved an IT initiative from oblivion. Often, the model that you bring into life is the first time that the senior management of an organization has possessed a ‘helicopter –height’ panorama of the flow and transformation of data through the organization. Often, if you take care over the presentation of the model, and communicate it well, it sparks all sorts of ideas to improve the way that the organization works; ideas that often don’t require technology to implement.
The first thing about establishing what really goes on in a company is that
Why bother with the long-drawn-out business of getting the data and process architecture of an enterprise right? Often, the data architects are seen as pedantic, doddery old veterans put safely out to grass where they can do no harm. When companies look for cuts in IT expenditure, the Data Architect is usually seen as an easy low-flying turkey to pick off. Nothing stops working when they are given the mantelpiece clock. Likewise, nothing bad happens for a while after you leap off the top of a tall cliff. Data Architects are important. The reasons why include
Maintaining a data model is surely the most important function an IT department can perform. In any place I’ve worked that has managed the job of maintaining such a thing, life for everyone has seemed, somehow magically, more simple and the reason for this hasn’t always been obvious. In fact, whenever I’ve poured through reports of why IT projects have failed, it has always struck me that nobody has mentioned ‘lack of an enterprise-wide data model’, as a good reason for failure. Maybe the task and its end-results just seem so esoteric that it is difficult to see the connection between that and all those little C#/LINQ projects all over the place. Maybe, as well, people have been asking the wrong question. It should be ‘Why do IT projects succeed?’. I’m sure ‘Having a good enterprise-wide view of your data systems’ must be up there.
(p.s. Two years ago, I expanded on this theme, in a rather more humorous vein, in The Data Dialog over on Simple Talk)