Category Archives: Strategic Planning

Strategy description tools & methods

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.”


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

Vendors – a word from a poacher turned gamekeeper

Nearly five years ago I gave up working for vendors, having been on the supply side of the IT chain since leaving university in 1982, and moved to the “dark side” by joining an end-user organisation. To be honest, it wasn’t a difficult transition but it is also a constant learning experience.

In the past week the differences between the supply side vendor view of the world, and the demand side end-user world have been bought sharply into focus. As part of a significant project I’m involved in, we have taken out one option and I have had several conversations with a major software organisation and some of its business partners to explain the decision.

I’m not the first person to comment on this, James Gardner(*) in his blog wrote a couple of articles about his view of the vendor approach and especially what he called “Proof of value”. Pity a few vendors haven’t read it.

For me, the biggest issue that the vendors I deal with don’t seem to be able to get to grips with is how end-user projects are costed. Before we go anywhere on a project the rule of thumb we apply is that the vendor costs will be one-third of the total project cost, and that isn’t including cost of ownership. Yep, that’s right: you sell me a £250k licence and I’m looking at a project of about £750k, and as we do the detail to get to business case the rule of thumb tends to be on the low side dependent upon the amount of transformation around the project.

So what is it I’m trying to articulate here? Well, I’d say there are a few points I tried to get over in my conversations this week:

  1. Reducing the product or licence cost is always good, but it rarely makes or breaks the total project: As we move towards product selection, we frequently get into a price negotiation. That is natural, but understand that making a 10% or 20% gesture is welcome, it is only a small part of the total cost. If it’s going to take 500 man days to implement your project then you can do what you like with the licence, it’s not going to reduce the implementation cost. And that leads to the next point…
  2. Implementation does cost: My organisation, like many others, does have to put implementation and other services into the financial reports. I often hear of talk about “funny money”, in one way it is but as far as our accounting team are concerned, it’s not funny at all, it’s quite real.
  3. It’s not the base cost, it’s the options: If I’ve learned anything, it is that the little things around the project that add-up; just like putting the options on your new car. Powerful servers are not that expensive relatively speaking, but start thinking about how many you need if you are to provide a highly available service and the costs rack up….. and we do need to provide a highly available service these days, in fact we’re now having to specify for 24×7 on services that previously wouldn’t have needed that level of SLA.
  4. Proof of Value is crucial: Given the size of some projects, we have to justify them to our governance organisations. If I am committing to a large spend on licences & people, then I need to be able to have mitigated any risk. The larger the project, then the larger the risk, and I cannot offset any potential risk against slideware. I’m not saying that I need a vendor to jump through hoops of fire here, just to understand the size of the project and thus the level of risk their product represents as a proportion of that project.

To be honest I have some personal beefs as well, but I’ll save them for another time.

The conversations I had this week were all based around the four items above taken in-toto. Jointly, yes we do like to work in partnership here, we couldn’t prove the value of one proposition which is why we had to discount it. In every discussion I had, the vendors kept going back to the cost elements and not looking at the whole.

Guys, I’m here to discuss this further if you want to…..

(*) James also wrote about Crowd Sourcing Strategic decisions. I followed this up with him directly & he was extremely generous with his time & experience, a great example of how we should treat each other in business. I am very grateful to him for this.

Strategy Development as a Critical Social Learning System

If you’ve managed to read the title of this post and still get to this point, well done! If you feel you need to know more, then suffice to say that in another life as an OU student, I am studying Systemic Inquiry. Where I struggle with this, other than finding that as an OU student you can’t go to the student union every night and get the worse for wear on cheap Yugoslavian wine (why, oh why, did I ever drink that stuff?), is in trying to put what I learn into the context of my day-to-day life in strategy formulation.

At this moment I’m studying about Critical Social Learning Systems and Communities of Practice. The big case in Critical Social Learning Systems goes back to Australian agricultural issues arising around Hawkesbury in the 1970s, but I’m more interested in the application in IT & business strategy where I suggest we could actually learn a lot.

Probably best if I try & say what a Critical Social Learning System (“CSLS”) is? Well, I’d actually describe it as a way that we all work together to develop our surroundings (I was going to say “environment” but I mean a wider sense than just eco-stuff); and in doing so we learn about ourselves & the changes we’re making so that we keep moving towards a mutually better world in which build up an understanding of how things interoperate & depend on each other. “Hmmmmm..?” as Greg Pfister would say, and “What has this to do with IT Strategy?” which, to be honest, he probably wouldn’t say.

Whilst CSLS is probably most suited to larger, social, situations, I think there are some key tenets that I could take here & suggest we should use when working on IT strategic development:

First up is the use of the word Critical, or applying Critical Thinking around what we do. This isn’t a negative thing, it’s about applying a set of thinking skills around what we’re doing in order to understand what we’re trying to do (in the wider scale of things) & what’s around to do it with. That latter piece: “What’s around to do it with” in IT strategy terms means trying to looks at the alternatives, evaluate them & then apply them to solve what we’ve originally set out to do.

Social brings about thoughts of more social entities, say, families or tribes but it actually applies to organisations; or communities of practice or interest. While I tend not to find a tribe of jungle dwellers dropping emails on me from time to time, I do get organisations and communities of practice of all sorts trying to communicate with me. For me however, the key here is that the communication is two-way in this model. In formulating our strategic thinking it shouldn’t be simply as a response to a challenge (“What is our strategy on cable radius, Russ?”…seriously!) but it should be co-operative across the business and set in the business context. After all, IT is following business strategy so it’s clear we should be working collaboratively.

And so to the elephant in the room…Learning. We do actually do this in our day-to-day work, “If I had known then what I know now….” but I’d suggest we don’t acknowledge it as a key part of what we do. Learning carries with it some bad connotations, “Why did it take you so long to find that out?”, and we’ve got to work past these and understand that we constantly are learning; and that in turns mean we may occasionally have to change our minds. This applies to strategy formulation and roadmaps – the world changes and so do our plans.

But learning actually carries a bit more with it as well, it’s not just about what I learned, but what I learned about how I learned so that maybe in future I can do it quicker or avoid a pitfall. It’s also about learning about how we see the world around us and how that affected what we actually learned this time. How much of what we create is a future plan or roadmap is actually constrained by what we believe to be so. Not good if we’re trying to be innovative with IT provision but our established view of the world cuts off potential solutions before we’ve given them consideration.

And so finally to System, or rather Systems. What is meant here is looking at the dynamics & inter-relationships between the components that make up the situation that we’re interested in formulating strategy for. In IT terms it can be thought about as between the computer systems themselves, but also the organisational inter-relations; and how the information delivery relates to process delivery relates to systems availability relates to organisational capability…..and so on.

In summary, what have we got?

Well, I think that we’ve got to think about IT strategy formulation in a much wider sense than simply looking through the binoculars and deciding which next hot technology to deploy. We’ve got to put what we do in context (yes, the Enterprise Architects will be saying they already do that…”All hail TOGAF!”); but we’ve got allow joint learning on all parts, not just keep this stuff in the dark, and we’ve got to be honest about it.

So now I’ve got that off my chest it’s time to go back to the academic dark side where there is a lot more structure about the use of language, I’ve been very lax in my descriptions above but hopefully I won’t get shot….yet. For me a see a new framework for doing what I do appearing, so watch this space….

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