Archive for the ‘IT Management’ Category
Beyond words: visualising arguments using issue maps
Anyone who has struggled to follow a complex argument in a book or article knows from experience that reasoning in written form can be hard to understand. Perhaps this is why many people prefer to learn by attending a class or viewing a lecture rather than by reading. The cliché about a picture being worth more than a large number of words has a good deal of truth to it: visual representations can be helpful in clarifying complex arguments. In a recent post, I presented a quick introduction to a visual issue mapping technique called IBIS (Issue Based Information System), discussing how it could be used on complex projects. Now I follow up by demonstrating its utility in visualising complex arguments such as those presented in research papers. I do so by example: I map out a well known opinion piece written over two decades ago – Fred Brooks’ classic article, No Silver Bullet, (abbreviated as NSB in the remainder of this article).
[Note: those not familiar with IBIS may want to read one of the introductions listed here before proceeding]
Why use NSB as an example for argument mapping? Well, for a couple of reasons:
- It deals with issues that most software developers have grappled with at one time or another.
- The piece has been widely misunderstood (by Brooks’ own admission – see his essay entitled No Silver Bullet Refired, published in the anniversary edition of The Mythical Man Month).
First, very briefly, for those who haven’t read the article: NSB presents reasons why software development is intrinsically hard and consequently conjectures that “silver bullet” solutions are impossible, even in principle. Brooks defines a silver bullet solution for software engineering as any tool or technology that facilitates a tenfold improvement in productivity in software development.
To set the context for the discussion and to see the angle from which Brooks viewed the notion of a silver bullet for software engineering, I can do no better than quote the first two paragraphs of NSB:
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
The familiar software project, at least as seen by the non-technical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet—something to make software costs drop as rapidly as computer hardware costs do.
The first step in mapping out an argument is to find the basic issue that it addresses. That’s easy for NSB; the issue, or question, is: why is there no silver bullet for software development?
Brooks attempts to answer the question via two strands:
- By examining the nature of the essential (intrinsic or inherent) difficulties in developing software.
- By examining the silver bullet solutions proposed so far.
That gives us enough for us to begin our IBIS map …
Issue Map – Stage 1
The root node of the map – as in all IBIS maps – is a question node. Responding to the question, we have an idea node (Essential difficulties) and another question node (What about silver bullet solutions proposed to date). We also have a note node which clarifies what is meant by a silver bullet solution.
The point regarding essential difficulties needs elaboration, so we ask the question– What are essential difficulties?
According to Brooks, essential difficulties are those that relate to conceptualisation – i..e. design. In contrast, accidental (or non-essential) difficulties are those pertaining to implementation. Brooks examines the nature of essential difficulties – i.e. the things that make software design hard. He argues that the following four properties of software systems are the root of the problem:
Complexity: Beyond the basic syntax of a language, no two parts of a software system are alike – this contrasts with other products (such as cars or buildings) where repeated elements are common. Furthermore, software has a large number of states, multiplied many-fold by interactions with other systems. No person can fully comprehend all the consequences of this complexity. Furthermore, no silver bullet solution can conquer this problem because each program is complex in unique ways.
Conformity: Software is required to conform to arbitrary business rules. Unlike in the natural sciences, these rules may not (often do not!) have any logic to them. Further, being the newest kid on the block, software often has to interface with disparate legacy systems as well. Conformity-related issues are external to the software and hence cannot be addressed by silver bullet solutions.
Changeability: Software is subject to more frequent change than any other part of a system or even most other manufactured products. Brooks speculates that this is because most software embodies system functionality (i.e. the way people use the system), and functionality is subject to frequent change. Another reason is that software is intangible (made of “thought stuff”) and perceived as being easy to change.
Invisibility: Notwithstanding simple tools such as flowcharts and modelling languages, Brooks argues that software is inherently unvisualisable. The basic reason for this is that software – unlike most products (cars, buildings, silicon chips, computers) – has no spatial form.
These essential properties are easily captured in summary form in our evolving argument map:
Issue Map – Stage 2
Brooks’ contention is that software design is hard because every software project has to deal with unique manifestations of these properties.
Brooks then looks at silver bullet solutions proposed up to 1987 (when the article was written) and those on the horizon at the time. He finds most of these address accidental (or non-intrinsic) issues – those that relate to implementation rather than design. They enhance programmer productivity – but not by the ten-fold magnitude required for them to be deemed silver bullets. Brooks reckons this is no surprise: the intrinsic difficulties associated with design are by far the biggest obstacles in any software development effort.
In the map I club all these proposed solutions under “silver bullet solutions proposed to date.”
Incorporating the above, the map now looks like:
Issue Map – Stage 3
[For completeness here’s a glossary of abbreviations: OOP – Object-oriented programming; IDE – Integrated development environment; AI – Artificial intelligence]
The proposed silver bullets lead to incremental improvements in productivity, but they do not address the essential problem of design. Further, some of the solutions have restricted applicability. These points are captured as pros and a cons in the map (click on the map to view a larger image):
Issue Map – Stage 4
It is interesting to note that in his 1997 article, No Silver Bullet Refired , which revisited the questions raised in NSB, Brooks found that the same conclusions held true. Furthermore, at a twentieth year retrospective panel discussion that took place during the 22nd International Conference on Object-Oriented Programming, Systems, Languages, and Applications, panellists again concluded that there’s no silver bullet – and none likely.
Having made his case that no silver bullet exists, and that none are likely, Brooks finishes up by outlining a few promising approaches to tackling the design problem. The first one, Buy don’t build, is particularly prescient in view of the growth of the shrink-wrapped software market in the two decades since the first publication of NSB. The second one – rapid prototyping and iterative/incremental development – is vindicated by the widespread adoption and mainstreaming of agile methodologies. The last one, nurture talent, perhaps remains relatively ignored. It should be noted that Brooks considers these approaches promising, but not silver bullets; he maintains that none of these by themselves can lead to a tenfold increase in productivity.
So we come to the end of NSB and our map, which now looks like (click on the map to view a larger image):
Final Map
The map captures the essence of the argument in NSB – a reader can see, at a glance, the chain of reasoning and the main points made in the article. One could embellish the map and improve readability by:
- Adding in details via note nodes, as I have done in my note explaining what is meant by a silver bullet.
- Breaking up the argument into sub-maps – the areas highlighted in yellow in each of the figures could be hived off into their own maps.
But these are details; the essence of the argument in NSB is captured adequately in the final map above.
In this post I have attempted to illustrate, via example, the utility of IBIS in constructing maps of complicated arguments. I hope I’ve convinced you that issue maps offer a simple way to capture the essence of a written argument in an easy-to-understand way.
Perhaps the cliche should be revised: a picture may be worth a thousand words, but an issue map is worth considerably more.
IBIS References on the Web
For a quick introduction, I recommend Jeff Conklin’s introduction to IBIS on the Cognexus site (and the links therein) or my piece on the use of IBIS in projects. If you have some time, I highly recommend Paul Culmsee’s excellent series of posts: the one best practice to rule them all.
IT does matter
Does IT matter? This question has been debated endlessly since Nicholas Carr published his influential article over five year ago. Carr argues that the ubiquity of information of information technology has diminished its strategic importance: in other words, since every organisation uses IT in much the same way, it no longer confers a competitive advantage. Business executives and decision-makers who are familiar with Carr’s work will find a readymade rationale for restructuring their IT departments, or even doing away with them altogether. If IT isn’t a strategic asset, why bother having an in-house IT department? Salaries, servers and software add up to a sizeable stack of dollars. To an executive watching costs, particularly in these troubled times, the argument to outsource IT is compelling. Compelling maybe, but misguided. In this post I explain why I think so.
About a year ago, I wrote a piece entitled Whither Corporate IT, where I reflected on what the commoditization of IT meant for those who earn their daily dollar in corporate IT. In that article, I presumed that commoditization is inevitable, thus leaving little or no room for in-house IT professionals as we know them. I say “presumed” because I had taken the inevitability of commoditisation to be a given – basically because Carr said so. Now, a year later, I’d like to take a closer look at that presumed inevitability because it is actually far from obvious that everything the IT crowd does (or should be doing!) can be commoditised as Carr suggests.
The commoditisation of IT has a long history. The evolution of the computer from the 27 tonne ENIAC to the featherweight laptop is but one manifestation of this: the former was an expensive, custom-built machine that needed an in-house supporting crew of several technicians and programmers whereas the latter is a product that can be purchased off the shelf in a consumer electronics store. More recently, IT services such as those provided by people (e.g. service desk) and software (e.g. email) have also been packaged and sold. In his 2003 article, and book published a little over a year ago, Carr extrapolates this trend towards “productising” technology to an extreme, where IT becomes a utility like electricity or water.
The IT-as-utility argument focuses on technology and packaged services. It largely ignores the creative ways in which people adapt and use technology to solve business problems. It also ignores the fact that software is easy to adapt and change. As Scott Rosenberg has noted in his book, Dreaming in Code
“…of all the capital goods in which businesses invest large sums, software is uniquely mutable. The gigantic software packages for CRM and ERP that occupy the lives of the CTOs and CIOs of big corporations may be cumbersome and expensive. But they are still made of “thought-stuff”. And so every piece of software that gets used gets changed as people decide they want to adapt it for some new purpose…”
Some might argue that packaged enterprise applications are rarely, if ever, modified by in-house IT staff. True. But it is also undeniable that no two deployments of an enterprise application are ever identical; each has its own characteristics and quirks. When viewed in the context of an organisation’s IT ecosystem – which includes the application mix, data, interfaces etc – this uniqueness is even more distinct. I would go so far as to suggest that it often reflects the unique characteristics and quirks of the organisation itself.
Perhaps an example is in order here:
Consider a company that uses a CRM application. The implementation and hosting of the application can be outsourced, as it often is. Even better, organisations can often purchase such applications as a service (this CRM vendor is a good example). The latter option is, in fact, a form of IT as a utility – the purchasing organisation is charged a usage-based fee for the service, in much the same way as one is charged (by the meter) for water or electricity. Let’s assume that our company has chosen this option to save costs. Things seem to be working out nicely: costs are down (primarily because of the reduction in IT headcount); the application works as advertised; there’s little downtime, and routine service requests are handled in an exemplary manner. All’s well with the world until…inevitably…someone wants to do something that’s not covered by the service agreement: say, a product manager wants to explore the CRM data for (as yet unknown) relationships between customer attributes and sales (aka data mining). The patterns that emerge could give the company a competitive advantage in the market. There is a problem, though. The product manager isn’t a database expert, and there’s no in-house technical expert to help her with the analysis and programming. To make progress she has to get external help. However, she’s uncomfortable with the idea of outsourcing this potentially important and sensitive work. Even with signed confidentiality agreements in place, would you outsource work that could give your organisation an edge in the market? May be you would if you had to, but I suspect you wouldn’t be entirely comfortable doing so.
My point: IT, if done right, has the potential to be much much more than just a routine service. The example related earlier is an illustration of how IT can give an organisation an edge over its competitors.
The view of IT as service provider is a limited one. Unfortunately, that’s the view that many business leaders have. The IT-as-utility crowd know and exploit this. The trade media, with their continual focus on new technology, only help perpetuate the myth. In order to exploit existing technologies in new ways to solve business problems – and to even see the possibilities of doing so – companies need to have people who grok technology and the business. Who better to do this than an IT worker? Typically, these folks have good analytical abilities and the smarts to pick up new skills quickly, two traits that make them ideal internal consultants for a business. OK, some of them may have to work on their communication skills – going by the stereotype of the communication-challenged IT guy – but that’s far from a show-stopper.
Of course this needs to be a two-way street; a collaboration between business and IT.
In most organisations there is rarely any true collaboration between IT and the business. The fault, I think, lies with those on both sides of the fence. Folks in IT are well placed to offer advice on how applications and data can be used in new ways, but often lack a deep enough knowledge of the business to do so in any meaningful way. Those who do have this knowledge are generally loath to venture forth and sell their ideas to the business – primarily because they’re not likely to be taken seriously. On the other hand, those on the business side do not appreciate how technology can be adapted to solve specific business problems. What’s needed to bridge this gap is an ongoing dialogue between the two sides at all levels in the organisation. This is possible only with executive support, which won’t be forthcoming until business leaders appreciate the advantages that internal IT groups can offer.
Once in place, IT-business collaboration can evolve further. In an opinion piece published in CIO magazine, Andew Rowsell-Jones describes four roles that IT can assume in a enterprise. These are:
- Transactional Organisation: Here IT is an “order taker”. The business asks for what it needs and IT delivers. In such a role, IT is purely a technology provider; innovations as such focus only on improving operational efficiency. This is basically the outdated IT-as-service (and not much else) view.
- Business partner: Here IT engages with the business; it understand business needs and provides a solution appropriate to business requirements.
- Consultant: This is takes IT engagement to the next level: IT understands business issues and technology trends, and feels free to suggest solutions that will help drive business success- much like an external business/technology consultant.
- Strategic: This is the semi-mythical place all IT departments want to be: In such organisations IT is viewed as an asset that plays an important role in developing, implementing and executing the organisation’s strategy.
[Note that levels (2) and (3) are qualitatively the same: A business partner who understands the business and is viewed as an adviser by the business is really a consultant.]
These roles can be seen as describing the evolution of an IT department as it moves from an operational to a strategic function.
Moving up this value chain does not mean latching on to the latest fad in an uncritical manner. Yes, one has to keep up with and evaluate new offerings and ideas. But that apart, shiny, new technologies are best left alone until proven (preferably by others!). Even when proven, they should be used only when it makes strategic sense to do so. Business strategies are seldom realised by shoehorning organisational processes into alleged “best practices” or new technologies. Instead, organisations would be better served by a change in how IT is viewed; from service provider to business partner or, even better, consultant and advisor.
IT is more about business problem solving and innovation than about technology. Corporate IT folks must realise, believe and live this, because only then will they be able to begin to convince their business counterparts that IT really does matter.
Dysfunctional IT attitudes: processes are more important than people
The service desk phone rang one morning. The guys were busy attending to other jobs, so the manager picked up the call, “Morning, IT service desk, Jake speaking. How can I help you?”
“I had asked for Consolidate to be installed on my new computer, but have just noticed that it wasn’t.” The lady at the other end of the line sounded irritated. The software should have been installed on her computer – it was on top of the list she had provided to the service desk when she’d put in the request for her new computer.
“Have you logged a service request?” enquired Jake.
“Yes,” she said, ‘but this is urgent. I have to send my sales figures for the month to head office this morning, and I can’t do it without Consolidate. Could you please send someone up right away?”
There was a short pause at Jake’s end. “I’m looking at the SLA right now, and Consolidate isn’t listed as a business critical application. There’s no way we can do this right now.”
“Look, it’s critical as far as I’m concerned. It’s got to be done right away or head office won’t get their sales figures. So, when can I expect a response?” Her annoyance levels were starting to increase
“Not before tomorrow, or may be even day after, depending on how soon we clear other, pending jobs.”
“I think I’ve made it clear this is important. Can’t you do it sooner?”
“No.” Jake clearly thought that no further explanation was necessary. Can’t have folks jumping the queue; service desk processes were put in place for a reason.
She took a more conciliatory tone, “Please understand,” she said, “I wouldn’t make an issue out of it if it weren’t important… the sales figures must be done by this afternoon. I just need the application installed; it shouldn’t take more than five minutes.”
“Sorry, you’ll just have to wait.” He didn’t sound sorry at all.
She’s starting to get really ticked off now. “It was a help desk mess-up in the first place. You should take responsibility and fix it now.”
“Perhaps you didn’t hear what I said; someone will come by tomorrow or day after. That’s the best we can do given that Consolidate is not a business critical application. You’ll just have to wait your turn.” There was no response from her side, so he added, “We have processes in place. We can’t bypass them for just any request.”
Jake’s reference to processes only annoyed her further, “Obviously your processes – whatever they may be – don’t work. The application should have been installed when I got my computer.”
“I’m sorry about that, but I can’t make any exceptions to the way we deal with service requests.” He sounded even less sorry now.
She seethed. “Thanks….you’ve been so very helpful.” Her tone made it clear that she thought Jake was being singularly unhelpful. She hung up, not waiting for a response.
—
Jake had a point: proper functioning of a service desk depends on processes. Bypassing these can lead to problems – not the least being that everyone would expect an instant response. Service desk processes ensure efficiency and transparency. Everyone knows what they can expect when they lodge a request; expected service levels being documented in excruciating detail in service level agreements. Yes, all this is true, and can’t be argued. Even so, I can’t help but think that the lady deserved better. Jake could have explained his position in a more acceptable way, or damn it – even got off his rear and fixed the issue himself in five minutes flat. He would have bypassed his beloved processes, but gained much goodwill in doing so.
Over the years, processes have become entrenched in corporate IT, as witnessed by the plethora of best practices such as ITIL and CMMI. Implementation of processes based on these frameworks and methodologies helps standardise the way corporate IT carries out its functions. This, in most cases, is a good thing. Yet, processes aren’t the be all and end all of IT. At the receiving end of IT services are ….yes, real people doing real work that keeps businesses ticking. Conflicts between IT and the business occur when IT folks forget that people are more important than processes; like Jake in the true incident described above. This holds not just for operational IT (like the service desk), but also for development work (i.e. projects) as I’ve mentioned in an earlier post. Trouble is, processes trump people more often than not. When that happens, things aren’t working the way they should- processes are intended to help people, not to hinder them. This is something folks who work in corporate IT would do well to keep in mind; especially these days, when business leaders are being seduced by the call of outsourcers and the IT-as-utility crowd.
All too often, IT management thinks of processes as a panacea for all IT ills. The way I look at it is a little different: processes are fine and good, and even necessary; but the people who are served by IT must come first. If that means making the occasional exception to a mandated process, then so be it.
Eight to Late 