Category Archives: Design

Death to Venn Diagrams!

This post has been mulling around in my mind for a while now, but a question asked by a fellow OU Systems Thinking in Practice (STiP) alumni, précised as “Are there other Systems Thinking methods are out there that we could look at?”, has encouraged me to finally put finger to keyboard.

My question in return is “What counts as a Systems Thinking approach, method or tool?”

In fact it raises the whole subject of categorisation which may have been covered on the Open University course B823: Knowledge Management, but sadly it’s no longer running and so I can’t study it having instead to scratch around this area trying to find little nuggets that might help my understanding.

Categorising things can work well when the world is pretty static but, well, that isn’t really the case these days. But it’s not just the change of things, its the change of about their properties and value to us.

Our previous IT Director used to bemoan the fact that there wasn’t a “killer app” for the Blackberry that he felt was needed to drive adoption, yet it was the device itself that had become compelling, the “killer app” if you like. I’d suggest  suspect that in his mind he was looking to classify his Blackberry under some sort of category that he had such as “It does one thing better than anything else” but hadn’t recognised that it was a category that was no longer valid.

Continue reading

What does “Always On” really mean to us?

A couple of years ago I gave up my Windows Mobile based Smartphone for the greater good, and in return joined the Blackberry “crew”. For weeks I was lost, the WM device may not have had all the bells & whistles of the Blackberry but what it did do, it did properly. I used it for getting my email on the move and the email functionality had none of the quirks that afflict the Blackberry, even today.

I now have one of the better Blackberry devices, have loaded a few more applications, and it’s now usable-ish but typing on that little keyboard is a pain. It’s great for senior managers sending one word emails, but if you’ve been asked a detailed question then sitting at Leeds railway station on a frosty morning trying to type a detailed response takes some doing.

It’s my choice to use the Blackberry, a colleague insists on using his massive laptop with a 3G connection but hoisting that lot around defeats the object of mobile devices. I have a netbook that I use when out and about and that works well plus I don’t have to annoy fellow travellers with my wheeled briefcase that gets in the way in crowds and won’t go through the ticket barriers.

Now I’ve been given one of Mr Job’s new tablet devices to use, we’re testing security software to see if we could use them as corporate email units.

Where I work I wrote a tongue in cheek blog entry about versions of software. In it I commented that early versions are rushed out and don’t do everything; later versions are better but push the limits on the technology; and the final versions (if they’re worthwhile) get swallowed up by the big companies.

The iPad feels very much like V1.0 software: there are lots of applications but, like the Blackberry, they don’t do everything. This got me thinking about where we are going in future, something dangerous for a strategist to do, eh?

If I look at the telecommunications space with the emerging standards around IP based services, the whole telephone concept is going to change. The multiple telephone numbers that you have today will, I believe, disappear. Instead you will have a SIP contact point that is always there, and you will connect to it with whatever device you have to hand. Of course the device will dictate what you can & can’t do when you connect, but then translation services will help. Find a voice message left for you but you’ve only got text access so your phone service will translate the voice to test and show you the transcript.

This isn’t a particularly wild prediction, much of this is around today, it just needs stringing together and making commercially viable. But the main barrier to adoption is our acceptance of this style of communication, it doesn’t fit with our current views of how our world operates.

Back to the iPad, and the same will apply. We talk about “Cloud Computing” but in essence it will be the same model as our telephony. I like Zoho, an online office suite which is now getting mature. Want to word process, point your browser at Zoho and fire up Writer. That’s how we’re going to work in future: you’ll use one service in place of your PC today, and simply access it from whatever device you have at that moment. Again the barrier to adoption is simply the mindset we have today.

My current frustration with the iPad is the fact that it doesn’t give me full PC capabilities, but it’s not meant to, it’s my thinking that is wrong. If I adjust to think of it, and the Blackberry, as connectivity devices of varying capability then it starts to make sense.

So back to the question asked in the title. Always on is the service we’re going to use, and the fact that contacting someone, or using compute services will become a 24×7 offering that we will choose to dip into at our choosing. At the moment we’re in version 1.0 which is why I get one word email answers, but that will change come the next version. Promise!

Why did you do that?

One part of my day to day life is that I research into areas and try to make sense of them, often against the clock. I’m either good at it, or the fool, because I’m frequently asked to do it.

To be honest “making sense of them” actually means deciding if what I’m looking at is suitable & beneficial, be it a technology or solution that my organisation could derive value from, or on the OU module I’m currently taking it’s more about how I can usefully use what I am learning about.

The thing about trying to make sense of something of interest is that its not just understanding it and how useful it could be, its about being able to articulate that to others, and it’s only when you try to communicate your understanding that you actually realise how little you actually do understand.

It’s interesting when presenting to others to see the various prejudices that are carried along with peoples thinking, which is generally made visible in the challenges that come back. Geoffrey Vickers came up with the idea of the Appreciative System which really applied to understanding why people think the way they do, which in turn means looking at their past and what events and values have shaped that view (their “Appreciative Setting”). So run back in history & see the key events and learning that someone, or a group, has been through and you can start to understand why they are thinking like they are and thus why you’re getting the specific challenges.

I’d suggest the same methodology would be well applied to some artifcacts as well. When I analyse a solution or technology, I often find things that at first glance leave me asking “Why on earth is it like that?”. A good example here is a project I’m working on around a major ERP deployment. One option we have is very mature with a large market presence running into hundreds of thousands of sites worldwide. Look underneath the covers at the way it works in some places, especially the integration between modules, and you find a regular muddle that makes little or no sense at first glance, indeed it almost suggests a lack of architectural governance. And speaking of the architecture, it also looks very strange in these days of objects and service oriented architecture.

Of course, at that point trying to present this to colleagues I got the same responses from them, and these unanswered challenges leave a feeling that doesn’t help with trying to present a benefits case. You end up with a senior exec saying “How can it be good for my business when everybody around you has these questions (that I don’t actually understand) that you can’t answer?”

Now try to use something like an appreciative system and run back through history – the integrations didn’t all come about at once, they appeared over time and in some cases represent the state of the art at that moment. Secondly they were probably developed in phases, so some represent must-haves that had to delivered in a first wave as quickly as could be done, later phases probably had the benefit of more time. And when you have a global base of that size, the cost & risk of rewriting older technology code to a newer technology just doesn’t make sense. These are conjecture on my part initially, but I can now ask questions to confirm or disaffirm my thinking.

I had a similar experience looking recently at the C++ language, based on some technical developments being done at Microsoft that could impact our development team. As a BCPL man myself, C++ looks way OTT: types on variables? objects? the referential model? Yuk! But then I found a paper written by Bjarne Stroustrup about the background and the design decisions made when evolving C++ and a lot became much clearer, as did positioning why you would want to use C++ in soem case and not in others.

In both cases, knowing why something has been delivered the way it has helps me to put it into context. No longer am I looking at face value and making decisions on that alone, but by tracking the past decisions I get an understanding of what underlies how what I’m looking at came to be, and that way I can make more sense of it.

The problem then comes in making compromises, as a strategist I want to reduce complexity and go for purity wherever possible. Yet in understanding as much of “Why?” as I can, I then understand where and why I need to make compromises on that. Fundumentally I move the messy problem from the technical domain over towards the business domain which can only be a good thing

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?

Roadmaps challenged

In my previous post I asked some questions about the validity of producing detailed strategic road maps for organisations at the end of the supply chain. I ended by saying that when I found the answers I would share them.

After publishing the post I picked up The Design of Design by Frederick P Brooks and started reading it from where I had previously left off (like a lot of people I have several books on the go at the same time). Brooks is famous amongst computer science students for writing a book of essays on software engineering, The Mythical Man Month which, in my day at least, formed the core of any course on the subject. His later book covers the essence of Design, not just in software but in the wider world and some of his essays can be taken to be a touch contentious and thought provoking. Either way both books make for excellent reading & I cannot recommend them enough for anyone dealing in architecture or software production as they contain many useful lessons applicable to either field

The essence of my previous post centred around the fact that as strategists we’re expected to produce road maps giving detailed guidance to the next steps to be taken to deliver our strategic intent. I don’t disagree with the intention at all, but when the future hangs on a number of different factors over which you have no control then providing instructions on whether to code the next project in C# or Java, and which method classes to use can be a bit difficult. My questions centred around being able to deliver strategic direction almost on demand to reflect the current view of the future, and then having effective & continual communication so everyone knew what to do and why.

Enter Mr Brooks. In an essay entitled The Divorce of Design he writes about how designers need to understand their products from a user viewpoint, and how cross training users in design techniques; and conversely training designers in the user domain provides a shared language that enables richer and faster communication with reduced ambiguity.  I’d suggest that the same lesson can be applied between strategists and the designers, and developers, downstream in the overall delivery process. By sharing knowledge of each others domains, then it is possible to enable the quicker communication medium that supports the flow of information in both directions.

Later on in his book, Mr Brooks writes about the process of documenting design rationale. He refers to two companies in the same industry, one with a culture of formally documenting how designs evolve and the second where this doesn’t happen; and then looks at the long term effect it has had on the designs of their products. Again,  I’d suggest that this too should apply to strategy planning & road mapping. A couple of years back, I produced a strategic roadmap detailing how we could develop a comprehensive online managed services capability, but subsequently my company changed how it delivers a fair portion of this capability. The detail of my original roadmap in terms of release levels of products is now irrelevant; and yet the strategic intent of what we are trying to do is the still the same and the rationale for selecting each step along the roadmap remains as valid now as it was then.

I only wish I had recorded the rationale for those steps so that the people using the documents had a clearer understanding of what we were aiming to achieve. So I haven’t answered all of the questions, but I’ve made start