It's that time of year again when I'm sitting by a pool musing. Given some of the comments that I’ve been making in recent blogs, on the difficulties of projecting an engineering model onto the problems of understanding legacy, my musing has been on what the UCL report termed the "socio-technical network".
There is something about lounging by the pool which leads me to reflect on the classic existentialist tomb "Being and Nothingness" by Jean Paul Sartre. (Actually it was more phenomenologist than existentialist but let’s not split philosophical hairs). Probably reflects my mental state. Half dozing on the lounger, half conscious, half not.
So what has the master of existentialism got to say to us, working our way through the practical issues of Data Migration exercises?
In last weeks blog I looked at the problem of using an engineering approach to any process where there may be an issue of semantic understanding (which I guess probably equates to the concept of "meaning" for us philosophers or "Canonical Meaning" for the Lean Integration brigade). This week I’d like to take these musings a little further with the help of Sartre’s concepts of "en-soi" and "pour-soi" to show that where this may appear a trivial side show it is really a central cause for problems when we are reviewing the pile of understandings that constitute a legacy data set.
For Sartre there was a problem with how we, as conscious beings, apply meanings to objects. Objects are "en-soi" that is "things in themselves". People, uniquely, are "pour-soi" - that is "things for themselves" because it is people who posses consciousness of those en-soi objects. There is a central problem of how consciousness operates on those things out there. Do things (like a chart of accounts maybe or the entity “Customer”) posses an essential meaning that we have to dig out? In other words do en-soi objects have an "essence", to use the philosophical term that by analysis we can determine? Or do they have no meaning outside of the one imposed on them by the pour-soi observer?
For Sartre this problem of eidetic analysis (to use the philosophical term for Entity Analysis) was more interesting than the discovery of the essential nature of things. Although he felt we could get a better understanding of the essential nature of objects under study he recognised that our interaction with the phenomena (sound, light, smell, texture etc.) of things by which we acknowledge their existence was constantly changing, constantly in flux. Sartre was more interested in what this had to say about the nature of consciousness - that strange pour-soi thing that we know only by internal awareness.
So how does this help us in our day jobs? Well first off it should be a warning about the naive simplicity of assuming that understanding meaning is easy, that there is one right definition (but many wrong ones). The relationship between objects and their essential meanings is far more problematic.
It's not because you are no good at your job and should seek another trade that you can't resolve the contradictions. It's a problem that has confused some of the greatest minds in history.
Secondly - we have the technology we have. By and large, it limits itself to a single meaning, a single Canonical Model.
What we have to do is get from the messy first problem to the simpler compromise of the second view. There's no point hiding away from this as an essential part of our activity.
We are not machines. Machines are en-soi objects that create en-soi objects. People are pour-soi consciousnesses that create meanings and instantiate them in the records they leave behind in the legacy data stores we then have to re-interpret. The crude application of engineering approaches to pour-soi consciousnesses leaves us with a miss-match that we then wrongly interpret as being a mistake in process.
We then waste time using the wrong tools (e.g. trying to impose an enterprise view onto our business domain experts which is inconsistent with their divergent understandings and using our monopoly of access to the new software to get it implemented in the target) only to be surprised and frustrated when our definitions are rejected.
This may all seem unnecessary heavy going. Perhaps it is. You can use the techniques within PDM without needing to understand what they are based on, just like I use my car without dwelling on the laws of thermo dynamics. However maybe I've spent too long in the sun but I think it is worthwhile to take these down time moments to reflect a little on the underling thinking beneath PDM that makes it more than just another implementation methodology. It addresses (amongst everything else) this central problem of the complexity of the external world as against the necessary simplicity of our computer world.
Next week I will be back home, returning to the day to day world of Data Migration. I will be writing about some of the up coming conferences this autumn where I will be speaking and looking forward to meeting with some of you.
For now, though, the pool, Sartre, being and nothingness beckons.
Johny Morris
