Category Archives: Systems

Flowers, Vegetables & Systems Practice

Two years ago I was about to embark on the first of two modules with the OU in Systems Practice. Whilst the two modules were in themselves interesting, the level of interaction with fellow students was quite astounding. Working on these courses as a distance learner can be a lonely existence yet the student forums for both the module work, and the coffee break chat, provided motivation and encouragement. It was very pleasing to be able to join many of those same students through a LinkedIn group and carry on those discussions when the modules were over.

One topic that is frequently revisited by the Systems Practice alumni is why the Systems Thinking approaches and practice are not being welcomed into many of the organisations that we work in.

Before I go any further, let me nail my colours to the mast on this topic: I embarked on this course of study because I felt it had a lot of benefit supporting what I do in my daily role, and it has delivered more than I expected, I am still learning and finding more to use every day. However, the systems thinking approaches are part of the tool kit, we still need governance, planning and the other components of management that introduce a level of rigour.

However our world is changing. It is becoming much more dynamic, and dare I say chaotic, as we see new organisational approaches such as: outsourcing, open innovation, and micro-organisation. I regularly see pieces exhorting us all to embrace “new” ideas such as “Design Thinking”, “Big Data” or “Social Networking at work”. All of these require news forms of management thinking in order that we survive & prosper in this new and rapidly changing environment. And yet the majority of senior figures seem to resolutely hold on to the older ways of management, eschewing any new ideas that could help.

And that is where a lot of the discussion amongst my fellow alumni has focused: just where & when will Systems Practice break through and become not only acceptable but substantive. Will, like our economy if Liam Halligan is to be believed, it be that when we are in dire straights, only then will there be an openness to any new ideas? Or is there so much inertia behind the methods employed by the large organisations & consultancies that these will continue to hold sway, not only where they do actually apply but in the areas where other approaches would be more suitable?

What has triggered these thoughts is a video at TED called Pam’s TED. How we can eat our landscapes in which Pam Warhurst describes how they changed the view of the people of Todmorden about green spaces through “propaganda gardening”.

Now, by highlighting this I’m not advocating that we go around massive business transformation by planting courgettes & sweet corn, but Pam does raise some interesting views that could be swiped (creatively of course) to apply more widely including to how we could get visibility and adoption of systems practice where it provides more value than existing methods.

So what is the systems practice equivalent of the green patch outside the railway station – something that is highly visible yet went uncared for before the “Todmorden Terrors” got to it, something that makes an impact on you as soon as you arrive at Todmorden. Watching the video I’m reminded of Captain Boycott of Yorkshire Airlines flying where he liked, at what height he liked. Pam talks about having no strategy and no permission, but just getting on with it anyway.

The Todmorden approach doesn’t hurt anyone, or take anything away from anyone and therefore is essentially benign. Yet it’s highly visible and people get a benefit. It’s also driven by unselfishness. And that’s what we have to do with getting systems practice made visible: find ways to use the approaches to provide benefits without hurting anyone. And that probably means doing the equivalent of working in the unwanted spaces at first. Here we go!

Cometh “The Internet of Things”, who will own it?

Back in the late 1980s I managed a software support team. In those days, before contemporary enlightenment bought around by the advent of plug-and-play, the constant refrain was the interchange with the hardware support team “It’s your hardware!”, “No,it’s your software”, “No, no, it’s clearly the hardware”….and so on. These days we’re used to dealing with new hardware as one single,easy entity, but back then there was a clear demarcation, made more visible by the practical jokes played by each team on the other.

Twenty five years later I work in a communications service provider (CSP), albeit one that has its own telecommunications carrier network. In my organisation there is much the same demarcation going on between the telecommunications team and the internal IT team, although that partly has to do with maintaining the security of each domain which provides the visible artefacts suporting the separation. Look at some of the other CSPs,and core telecommuncations companies, and you’ll find that this pattern is quite widespread. Even where I am aware of forward looking companies that have merged the comms & IT teams, they still keep their own identities.

The problem we are facing is that, as happened to the old hardware/software split back then, the two worlds of “communication” and “information technology” are accelerating towards each other. To be honest this shouldn’t come as a shock, but I’d suggest that both sides are trying not to pay too much attention to the consequences of this and are carrying on with the hope that it’ll all sort itself out in the wash, “the wash” being the compelling event that forces some sort of activity out of us all.

I must confess here that I had expected the emerging IP Multimedia Subsystem (IMS) architecture to be the driver for this merger of the technology areas but now it’s looking unlikely for a few years yet. What has spurred my interest in this is an interview with IBM’s Andy Piper about the MQ Telemetry Transport protocol, a lightweight transport protocol being proposed for the coming generation of Internet-connected devices.

So why do these architectures make a difference over what we have today?

Yes,it’s true that a lot of the more modern telecommunications devices that are implemented are actually computers and (speak this very quietly) databases. However I’d argue that the fact that you squirt PSTN protocols into them, and program them as you would other PSTN systems, puts them firmly into the telco domain.

The emerging IMS & telemetry systems bring a new set of challenges, for example the handling of complex data & topologies, something where IT departments have been working for a long time now.Similarly the new abstracted protocols such as Session Initiation Protocol (SIP) require a level of orchestration that we find in workflow systems; and they are supported on platforms running modified forms of traditional programming languages such as the JAIN SLEE extensions to JAVA.

And then there is the “killer app”: back in 2009 the BBC’s Rory Cellan-Jones wrote about the IBM researchers using the early MQTT developments to link a house directly to Twitter. As we use social media more as our interface to the underlying technology fabric then we need to think about user interfaces in a very different way, again the challenge being taken up already by IT departments.

No, I’m not advocating that IT departments around the globe prepare to take over the world. Rather the Systems Thinker in me is advocating that there are two skills bases (the IT and the Comms teams) that will converge over time. There are different perspectives here, but it’s not beyond the realms of systemic inquiry to bring them together.

It’ll be interesting to see who the smart Communication Service Providers are that drive that convergence sooner rather than later so that skills transfer can begin now. As Sergeant Stan Jablonski used to say in Hill Street Blues: “Let’s do it to them before they do it to us.”


“mknoona” and Critical System Heuristics

It’s been a little quiet here on the blog for a while as I have been busy with OU course TU811, Thinking strategically: systems tools for managing change which has taken up pretty much every free moment & put paid to any thoughts of flying my little airplane.

Now that all our TU811 work is submitted, the course online forum is pretty quiet except for a small quorum of us discussing the course content retrospectively. Some felt the content was rather superficial, the course presents five mainstream systems tools in parallel with a stream about thinking styles. Personally I felt that the breadth was good as it presented diversity in methods, and I like being able to choose from a canvas when I’m problem solving, and then modify & apply the method, “praxis” as introduced in the previous TU812 module.

One tool presented at the end of the module was Werner Ulrich’s Critical Systems Heuristics (CSH) which on face value looks a bit like a checklist presented as a matrix, but what it actually does is to make you think comprehensively about a situation from four different perspectives as my paraphrasing below:

  • why is it that we’re doing whatever it is we want to do
  • where is the centre of control for this, in other words if we try & do it is there a barrier stopping us
  • who actually understands what it is we’re trying to do & can they help us
  • who could be affected badly when we do what we’re trying to do

A lot of this is used in a social context but I got thinking about a couple of electronics problems from my past and how the decision style represented by CSH actually played a part even without us knowing about it…..

We’re used these days to buying a computer, taking it home & simply connecting it to a high-speed network, usually wi-fi as delivered by our broadband contract. Back in the 1980s this “Ethernet” network thing was just emerging from the Palo Alto Research Centre at Xerox, and we used “serial” wires to link terminals to computers, or even computers to computers (I was amazed on a trip to computer manufacturer CCI in California that they had all of their computers linked together using serial cables). These links were slow, and implemented using pretty simple electrical cable. When I went to work for Systime in 1986, they had a huge serial switch so from my desk I could connect to various computers, albeit one at a time from my terminal, very high-tech.

One problem with simple electrical cable, and slow speed data signals, is that it is very easily affected by external electrical noise, we still get some of that today when you are talking to someone on a telephone and their Blackberry is sat close by on the desk, you can hear the Blackberry doing it’s data transfers and it’s very annoying. In a “noisy” environment it was definitely the case that what was sent from the computer definitely wasn’t received at the other end.

Back in 1982 at a development centre in ICL, some colleagues on a different project to the one I was working on had a bad noise problem. Being a group of software developers they decided to fix the noise problem using software, they simply read the data value being sent down the wire three times and if they had two or three matches, used that. Ironically it was an apprentice from the manufacturing plant up the road who saw what they were doing, metered out the cable & showed that it wasn’t earthed correctly. Using a correct cable stopped all of the faults.

It was towards the end of the 80’s when I saw a similar problem. This time it was at an installation at a builders yard near Oxford. A serial cable had been strung over to a shed from where they processed orders for sand, grit & the like. This time the problem was almost unearthly, the signal coming down the wire kept repeating, in digital form, “mknoona….mknoona…”. And, yes in this case the cable was correctly earthed so the factor causing the problem was something external & significant. We ended up putting up a strongly shielded cable.

So what do these two problems have to do with Critical Systems Heuristics, if anything? In both cases what we wanted to do was to stop the spurious signals from coming down the wire, and it was easy to measure success: either the extracurricular rubbish stopped or it didn’t.

It was in the second step, looking at the controls, where the first case failed & the second worked well. At the development labs the team simply looked at themselves as the source of control, and of knowledge, and simply coded another fault into the system. They didn’t look at all of the sources of control (what could be done to stop the noise ingress) or knowledge (who could help with noise ingress) which is why a 17 year old apprentice showed them up. Furthermore no one thought about who would be impacted by the software change, in years to come someone would find their daft “fix” and have to puzzle it out, or worse still remove it as a common sense action and then find that things crashed around them.

In the builders yard case, it was quickly decided that the control of the external noise just couldn’t be found, and therefore the decision was taken to employ knowledge to institute a fix through shielding. I still have my suspicion that the noise was coming from power lines nearby but we could never prove it. Nothing was altered other than the cable & no-one was affected.

Back in May I wrote about making System Design Systemic and concluded that I had taken a soft technique from systems and applied to something much harder. I raise this because that is what I am doing here again. So it is an old example, but it shows that we can take systems thinking ideas & methodologies, and apply them to our harder technology world. And if it helps to make what we do more effective, and more consistent then is that a bad thing?

Can we apply Systems Thinking to Outsourcing?

A glutton for punishment, I’ve just started the second core Open University module on Systems Thinking, and the internal OU forums for the module are starting to wake up with comments on the course material. One comment has directly lead to this posting, namely a thought about the future of vendor relations in IT and whether it is possible to contract for joint social learning.

As I write this, the IT industry is certainly not alone in driving towards operating with varying amounts of outsourced support as our delivery capability gets increasingly federated. My own company has several outsource agreements, and the question asked in the student forum is quite interesting: Can we jointly learn as a collective of commercial entities, and thus jointly resolve situations?

A colleague of mine is of the view that where there is any change then that is evidence of learning. In his model, if I outsource a part of my operation, and a situation arises where we have to somehow get it resolved jointly, then the resulting change shows that we have learned something. Hmmm, yes….but is it a quality learning experience?

But how about we set out to learn jointly, and are we able to do it in a constructive manner? I made a comment about how our biggest outsource is working pretty much in this way, but then a lot of the staff in the outsource worked for us previously so they have our cultural values, and the working relationships in place with our company teams. In other words it’s pretty much business as usual, not that we have built up a way of working.

It’s also fair to say that the outsource model tends to be applied operationally. This is easy to contract, you know what to do & the expectations on you as there are SLAs to report to. The accountants & lawyers can work with this model, if either party fails to do XXX in time Y then you pay, or the lawyers start having an “interesting dialogue”.

Move towards a wider systems & learning context and it becomes harder to give the accountants and lawyers something to get their teeth into: the advantage of a systems approach is that it should be fairer and wider reaching in inquiry terms; also work items spinning off are widely understood by the whole group and therefore should be less contested. In other words in a joint activity (yes, I’ve changed the term “outsource” to “joint activity”) the work that is enabled should be beneficial to all in a context that is shared.

But that means at the beginning of an engagement you may not know what the outcome is likely to be. While that is satisfactory for public sector (within limits of reason of course), in private sector there are many stakeholders who are more familiar with contractual terms (price; SLAs; IP; share equity value) and who, as yet, don’t fully understand the systems engagement model. 

In the field of general aviation (private planes, helicopters and the various other flying machines that those braver than I feel are worth flying) one turning point was when a QC who also happened to be a PPL was elevated to a position whereby influence could be applied to aviation laws. At that time we started to see a lot more realism being applied to Air Law, never the easiest of subjects. (We also had an MP with a PPL, but he got distracted by a cheeky girl of some sort).

I suspect it might be similar if we are to see systems engagement applied to outsourcing, once we get lawyers & commercial financiers who understand what we are trying to achieve, then hopefully the way will be clearer to create the sort of iterative contracts that support systemic engagement between commercial entities. 

So yes, I think applying systems thinking to engagements with outsource agencies makes sense but we’re probably still to early to do it on any large scale. Let’s keep watching how it develops in public sector and see what lessons we can pick up and apply to private sector. Until then we’ll have to keep plugging away.

Should System Design be Systemic?

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?