Tag Archives: Design

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

Advertisements

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