About
I began working in corporate I.T. in the mid 1990’s, having converted from Civil Engineering via an MSc in Information Systems. The MSc course was focused on information systems design based on the Structured Systems Analysis & Design Methodology (SSADM), and as such was primarily concerned with structured methods founded on the core discipline of logical data modelling, or logical definition.
In my first role, as an analyst/developer at a large multi-retailer, I was surprised at the lack of appetite for structured methods. And over the following few years I was forced to accept, reluctantly, that a much more ‘freestyle’ approach to business systems delivery was the de facto industry standard.
The glue which holds everything together…
On my first project in Investment Banking I applied my knowledge of logical definition to unravel the complexities of a group of financial sector models – i.e. sets of valuations ratios & measures – in a flagship Equities Research application. It was my first experience of how genuine collaboration and greater productivity can be achieved with structured documentation, even between people who rarely, if ever, communicate with one another.
In the words of one of my colleagues, that relatively simple piece of logical data modelling meant that the project managers, business analysts, data analysts, developers, testers etc. working on the delivery were “finally all singing from the same hymn sheet”. The experience exemplified how logical definition is ‘the glue which holds everything together’ in business systems delivery – i.e. which allows the existing to be fully understood, and the proposed to be stated unambiguously, in the same objective and meaningful context.
Subjective interpretation…
However, in subsequent roles in both private and public sectors - including Retail Banking, Insurance, Energy, Telecommunications, Digital Media, Transport, Professional Education, Software Provision, Corporate Identity, Welfare, Housing and Land Management – it became apparent that logical definition was too abstracted from ‘business as usual’, or as another colleague put it, “too subtle a concept” to be regarded as very valuable. After all, most of us harbour a subjective view of our business and, understandably, that includes a subjective interpretation of the data which the activities we perform depend on.
Logical process…
With regard to business systems it occurred to me that the discipline of logical definition did not fit into the prevalent and, arguably, too simplistic process-oriented view of the organisation. Typically, an organisational unit, or team, is set up to manage & execute a process; where a process comprises one or more activities. So whilst activity/process ownership is deemed essential, data ownership is largely overlooked.
Therefore, the need to define data comprehensively – i.e. in an objective context which is meaningful to all who depend on it - is not fully appreciated. This lead me to think about how to create a more ‘tangible’ connection between logical data and activities – i.e. to create a useful representation of logical process; the result of which was the first version of the Change Management Model.
Collaboration should not have to come at the expense of individualism…
It also struck me that although subjective interpretation serves the individual a lot better than the organisation, it cannot be dismissed as inappropriate. This is because any organisation is made up of individuals, and it is individualism which makes an organisation competitive. Put simply, business is all about people.
It followed that, contrary to more conventional wisdom, collaboration does not have to come at the expense of individualism. So whilst the primary purpose of structured documentation is to engender collaboration, it can also be sophisticated enough to provide genuine visibility across the enterprise to different business parties, each from their own perspective.
The key was to include business parties in the Change Management Model, and provide the ability to translate subjective terms - e.g. entity & attribute names, activity descriptions - from one business area to another; as well as facilitate the concepts of activity & data ownership required to manage change collaboratively.
The inadequacy of the classical organisational setup…
In tandem with all of this the issue of data quality had been ‘snowballing’, especially where there was a need to integrate disparate data, for the purposes of both mergers & acquisitions and, more commonly, Business Intelligence applications.
This additional factor, coupled with the challenge of business systems delivery per se, highlighted the inadequacy of the classical organisational setup: where neither the business, nor I.T., feel that managing data (which relies on logical definition) is their responsibility. So that too often 'the ball gets dropped' into the ‘no man’s land’ between the two. It seemed to me that when it comes to managing data, and therefore managing change in business systems, the organisation in its classical format really isn’t very well organised.
We are not yet living in the Information Age...
Further, in an era of overstatement driven by increasing market competition – e.g. technicians are called engineers; haulage is called logistics - it never surprises me to hear the claim that we are living in the Information Age, just because we now have easy access to vast quantities of data. But I don’t believe it’s that simple. By definition, information is data which is usefully interpretable – i.e. informative. In my opinion, whilst we are certainly living in the Data Age, we are not yet living in the Information Age, nor will we be until we have learned to manage data comprehensively. And in terms of corporate I.T. that is likely to require a fundamental change of approach.