After six months tomorrow is the day I finish my first, and almost last, OU module. I’ve just completed TU812, Managing systemic change: inquiry, action and interaction and I wait to see if I’ve done enough to get a pass. To be fair it’s been a baptism of fire for me: first module with the OU; first time the OU have run this course; and trying to get the measure of being a postgraduate again.
If anyone has arrived at this page having searched on “TU812” then I’d advise you go carefully. It’s a very conceptual course, and as a technologist I found it hard to get to grips with the sort of stuff that sociologists do in their sleep…but then by writing this my tutor would tell me I am being reflective. General consensus of opinion was that if you come to TU812 with a few other courses under your belt from the systems stream then you’ll be ok, but a few of us newbies will be getting together starting on Thursday on the precursor course, TU811, Thinking strategically: systems tools for managing change so we all (hopefully) survived.
A colleague asked me if I felt I had actually learned anything, and on reflection I feel that I have. Before starting the course I had this feeling about things being interconnected but couldn’t quite get it all sorted out in my head. Now I feel that it’s fine to feel this, and that there are ways of looking at the complexity in the world and starting to make sense of it all in order to change it.
The trouble is that you start using this everywhere, and it came home to me on a project I’m working on in my day job. We’re trying to put together a large software solution (yes, that sort of “system”) made up of several components. We have a couple of software suites on offer at the core, and then we need to add a few ancillary packages around the outside and hook it all together with middleware. Piece of duff, should get it done by a week on Friday.
The trouble is that the two software suites at the core have very different backgrounds. Both have been built by their respective owning companies through acquiring products and then integrating them together. One is quite overt about the heritage of the core modules, and is trying to architect a neat solution to bringing them together in a pretty uniform way (well as uniform as it can be).
The other offering has been built more covertly, and has kept not only the application functionality but a lot of the other ways of working too. The problem we’re having in trying to set the core design principles is that using this suite means there is more than one way of doing everything, quite often a lot more than one way. Furthermore, then isn’t anything that is consistent over the whole suite, so we cannot choose one way forward without compromising somewhere.
Kick in my recent systemic inquiry course …. Bang! …. Isn’t this a “wicked mess”? …. Bang! …. Don’t we have co-evolutionary entities with conflicting views?
Ok, so I can’t get the various software modules to come together around the table and become critically aware of each other’s worldviews. But I can spot that the relationships between the various modules and the business constraints that using the various methods for integration bring about. I can also work out the analog of an appreciative system for each module (how it came to be what it is and do what it does in the way it does), so can start to build a rich picture of the design tradeoffs in both technical & business terms. And I can use all of these to arrive at design alternatives with an understanding of the impact of each (I’m being ethical!)
So, Ray, I apologise for taking your well-crafted “soft” subject and making it much “harder” to use in a technology context but I’d say that is learning, wouldn’t you?