The Undercover IT Correspondent

GOOD GUY AND BAD GUY TECHNOLOGIES

IT technology change is usually driven by organizational politics

After the Apollo 11 moon landing in 1969, journalists fantasized about mining colonies on the moon (never mind the monotonous scenery and the terrible economics of transporting coal across a quarter million miles). Well, similar fantasies occur within IT every time a new technology appears. Like the moon colonies, there is always a hype cycle that starts with a selling proposition that’s just too good to be true – often fuelled by journalistic flights of fancy – followed a few years later by a reality check. The script, as predictable as a Hollywood movie, runs something like this:

·         Selling proposition: New ‘good guy’ technology appears, which is invariably sexier, simpler and so much better than the old, ‘bad guy’ technology.

·         Reality check: New technology doesn’t take over the world after all, and the old technology sticks around for a long time still because: (i) the new technology has yet to acquire the economics of usage and the reliability of the old technology (ii) we wrongly assume that the old technology is standing still and not getting any better or cheaper.

A 19^th century economist of no uncertain notoriety once drafted a manifesto whose opening words were: ‘The history of all past society is the history of the struggle between classes’. Well, if this person were around today and applied his observations to the world of IT, all he’d have to do is change a few words and he’d have a new manifesto which this time round he’d have gotten right, and for which he’d get full Marx: ‘The history of all IT innovation is the history of the struggle between classes’.

Most IT innovations are of the ‘revolutionary’ kind, often accompanied by ‘holy wars’, in which a new technology is embraced as much for reasons of organizational politics as for addressing actual business requirements. There is invariably a struggle between some parts of the organization, or between some vendors. Fuelled by a passion generated by some ongoing conflict, one of these classes seizes upon a new technology to advance its particular organizational aims (eg decentralization) or commercial aims (eg crushing a competitor). It then raises high the banner emblazoned with the new technology, and basically tells some other class, as Woody Allen so eloquently put it, to ‘be fruitful and multiply’ – though not in those words. This enables a lot of people to make money publishing magazines, newspapers and books to cater to the faithful and play the various groups against each other, as we shall now see.

MAINFRAMES – THE GREAT DICTATOR

When mainframes first appeared in the fifties, their size, weight and floor space were so impressive that science-fiction writer Isaac Asimov actually predicted that most of their bulk would eventually have to be placed in space (otherwise where on earth would you put it?). Mainframes were therefore associated with a technical caste of high priests who spoke in terms of bits, bytes, MIPS and FLOPS, and saw themselves as the enlightened pioneers of a new age which only they could really understand. They consequently favored heavy-handed central control of both the technical and business environments. By the sixties therefore, the bubble was ready to burst and the time was ripe for a revolt, which came in the form of the minicomputer.

MINICOMPUTERS – GOING IT ALONE

By the mid-sixties, a new company called DEC (Decentralized Entry-level Computers) had firmly established itself as the leader in a new class of machines called minicomputers. The ascent of this new class of machine had as much to do with organizational politics as with technology (it boasted technological improvements like transistors instead of vacuum tubes –  and a novelty called a video monitor).

When decentralized business units analyzed their internal allocations or charge-backs to central IT, they found that they compared very favorably with the price of low-cost minicomputers from DEC. On a purely hardware purchase-price basis therefore, they found they could easily justify the creation of their own IT departments, which began to spring up left, right and center. Minicomputers thus ushered in a new information age, suitably ‘liberated’ from the yoke of central IT, whose mainframe-based monopoly began to crumble.

Over time, however, the decentralized IT departments running minicomputers became victims of their success. Though they rightly viewed themselves as far more responsive to the business than the original mainframe dictatorships, they also found it difficult to cope with the huge increase in demand for their services.  Financial reality also caught up with them, as it gradually became clear that computing costs went far beyond the initial price tag on the hardware. So even the decentralized computer departments found themselves suffering a fate similar to that of their previous central masters, albeit on a much smaller scale.

So by the mid-seventies, another bubble was ready to burst. The time was ripe for yet another revolt, which came with the arrival of the microcomputer or PC.

MICROCOMPUTERS – RAISING THE MIDDLE FINGER

In 1976 Apple was created in a garage –  thereby ensuring for posterity the mythical status of the garage as a great place to start a business. And when it brought out its first microcomputers in the mid-seventies, users for the first time in history were able to use computers on a purely individual basis. And once microcomputers could be networked together, the stage was set for another round of ‘liberation’ from the IT Department ‘oppressors’.

When IBM itself eventually joined the fray in 1981 with its PC, the momentum snowballed.  Dealers took orders for 250,000 units on the first day, whereas IBM had expected to sell 275,000 units over the product’s entire lifetime of five years – talk about giving forecasting a bad name.

Whereas the previous minicomputer revolution was pure organizational politics between centralized and decentralized cultures, the new microcomputer revolution went further and added an ideological dimension. It was not enough to want better computing services in the enterprise; one also had to take a stance in favor of the individualism and freedom that microcomputers supposedly embodied. This implied the overthrow of the central IT dictatorships with their mainframes and minicomputers, symbolized by the oppressive Darth Vader and his evil empire, a.k.a. IBM. One newspaper even proclaimed itself ‘The Voice of Personal Computing in the Enterprise’, and in 1991 its editor-in-chief went as far as predicting that the last mainframe would be unplugged in 1995! This prediction was all the more misplaced given that around this time, both Microsoft and Apple were using very large IBM minicomputers to run their own businesses, and showed absolutely no signs of wanting to unplug them!

Apple had the GUI field to itself for six whole years, from 1984 to 1990, which gave Bill Gates every reason to be mad at Steve Jobs for threatening his dreams of world domination. Bill’s take on this was ‘don’t get mad, get Steven’, so he quietly went away and prepared his revenge. When Microsoft came out with a workable version of Windows in 1990, Apple’s fate was sealed as far as corporate IT was concerned. It also lost the ill-conceived lawsuit against Microsoft for copying its GUI, since Apple itself had copied the idea from Xerox (itself a copier company…).

WEB 2.0  - HERE WE GO AGAIN?

It would be nice to think that the organizational ‘holy wars’ and ‘class struggles’ ended with the mainframe-mini-micro technology battles above, but this was not to be the case. Organizational politics by technology proxy continued with NCs (that’s Network Computers for the newbies) vs PCs, Navigator vs Explorer, client/server vs host computing and OS/2 vs NT. All of these battles were always about more than just technology; they were also about ‘good guys’ vs ‘bad guys’. Adopting them would not just enable you to better resolve your business or technical problems; they would also ‘liberate’ you from some ‘undesirable’ part of the organization, or from some ‘undesirable’ vendor.

And with Web 2.0 we’re coming full circle again. Many articles on this new wave of computing are already evoking the apparent inability of the traditional IT department to come to grips with it. Now throw in some ‘digital generation’ stuff for good measure, and one part of the organization will soon be seeking 2.0 ‘liberation’ and telling some other part of the organization to go ‘be fruitful and multiply’ – though not in those words. MG

BEHIND THE SCENES IN IT AFTER A MERGER 

Just watch the Delta and Northwest IT staff slug it out behind the scenes!

With the Delta  and Northwest mega-merger now imminent, journalists have already conducted in-depth analyses of what it’s going to mean from a business perspective. But what’s it going to mean from an IT perspective? Nobody talks about that – and yet, this where a lot of organizational battles, turf wars and power plays are going to take place, as frightened IT staff wonder whose systems will win out, and whose will be relegated to oblivion.

What happens to IT departments after a merger offers a fantastic insight into organizational politics. But first, let’s start out by saying that in reality there are no mergers, only acquisitions. Even in the very rare case of a ‘merger of equals’ (ha!), with complementary products or services contributing to a better overall portfolio, there will still be a dominant player calling the shots: one of the parties must have a greater ‘need’ to be acquired than the other. So merger is really a politically correct term which is bandied about for press consumption to placate employees and shareholders.  For example, have you ever heard of Scopus? You haven’t? Well, you’ve just dated yourself as an IT rookie – they ‘merged’ with Siebel in 1998 (at least Larry Ellison had the good grace to call Peoplesoft  an acquisition).  Daimler-Chrysler 10 years ago might have been a ‘merger of equals’, but is was clear to everyone in Detroit that merger was spelled a-c-q-u-i-s-i-t-i-o-n.

So what awaits the new CIO after a merger? Well, to start with, both companies will in all probability have different infrastructures, architectures and technical standards. They will also be running different types of applications in terms of ERP, CRM, billing, etc, and probably using different vendors such as SAP, Oracle, etc. The term driving a square peg into a round hole does not even begin to describe the complexity of the task at hand. And this already tall order must in addition be accomplished without disruption to existing operations, and without upsetting any customers.

With this firmly in mind, let’s try and answer the following question: ‘ which of the following criteria should be used when deciding which systems to keep and which to phase out? ’

(a)   cost-effectiveness

(b)   customer satisfaction

(c)    total cost of ownership

(d)   reliability

(e)    scalability

(f)     ease of integration

(g)   process effectiveness

(h)   level of ROI to date

(i)     some of the above

(j)     all of the above

(k)   none of the above.

The correct answer is of course (k) – none of the above.

After the official merger announcement, a photo op of the two CEOs back-slapping and high-fiving in front of the cameras appears on CNN and in the press, and great care is taken to achieve a politically acceptable balance at board level, for employee and shareholder reasons. However, there is no such requirement for IT – who the new CIO is and which company’s architecture and systems are going to dominate is of absolutely no interest to CNN and the Wall Street Journal. Which essentially means that the rules of engagement are not very different from those of the animal kingdom, ie the instinct for survival and protection of the herd decides the outcome.

So what should in reality be a fairly complex process of identifying the ‘best’ systems based on a set of rational and objective criteria actually turns out to  be fairly straightforward. The dominant company puts its key people in place, makes some token concessions, then  essentially tells its team to take what they think is useful from the other side and phase out the rest. Period. It’s as simple as that. Oh sure, some mega-mergers put on a show of actually going through an objective selection and consolidation process, but the end result is rarely in doubt. Which is just as well, because it is questionable whether a consultative, democratic and rational approach could ever work. After all, a systems manager from company A is hardly going to tell his counterpart from company B, ‘You know Jim, your CRM system and underlying architecture are really much better than ours. We should definitely standardize on yours. I therefore agree to trash our system and phase myself out of existence.’

Objectively merging the IT departments of two large companies is an impossible task, from a technological, organizational, political and cultural perspective. Key people will understandably seek survival by protecting the herd that constitutes their power base, and that power base comes with a number of systems attached. So by definition there’s going to be a painful transition period in which you’re going to have to phase out both people and systems, and you want to try and keep that period as short as possible. And in a perverse way, this pre-historic approach is probably the best answer amongst a host of bad choices. MG

The SDLC (SYSTEMS DEVELOPMENT LAUGHTER CYCLE)

IT’s a serious business folks – so don’t laugh…

We’re a strange bunch in IT. For the past 50 years we’ve been working to a methodology based on the construction industry, with a strict linear approach from analysis, development and testing through to implementation and operations, with each phase performed by different teams of specialists. Even though the success rate of this approach is the pits, we still take it quite seriously – which when you come to think of it is actually quite funny.  Which is why SDLC might as well stand for Systems Development Laughter Cycle.

REQUIREMENTS – ANALYZE THIS!

The first phase in the SDLC is requirements analysis, which is traditionally conducted by analysts (you want to be careful how you pronounce the first syllable …). Analysts sit down with users in an attempt to understand their business problem – then produce a thick ‘requirements’ document that no one really understands.

Once this so-called ‘statement of requirements’ (SoR) has been duly ‘signed off’ by the business, IT will then try to build a system to meet those requirements. Now the requirements might be incorrect, incomplete, or might even have changed since. But that doesn’t matter, because if (when…) the documented requirements that IT delivers on don’t correspond to actual requirements, it can use the signed-off SoR as a ‘get out of jail free’ card in Monopoly, and not be penalized.

DEVELOPMENT – MISSION IMPOSSIBLE

Once analysts have tricked the business into signing off on the SoR, they toss it over the wall to the development team. This group now has the unenviable task of programming useful deliverables out of what is ultimately a mix of real requirements, perceived requirements, wish list and pure fantasy. Usually the things you hear from developers when they read the SoR are things like ‘This is impossible! We can’t do this!’.

So developers sometimes find that they have to develop a system in three months that allows the business to ‘analyze customer behavior based on any combination of profiling information, order history, billing patterns and customer service interactions, using user-friendly point-and-click technology which gives graphical results on a real-time basis’ – something that can take one to five years, if at all possible. As you have probably gathered by now, developers and analysts have a love-hate relationship, and don’t exactly hang out together after work.

DOCUMENTATION – SOME LIKE IT NOT

In theory, developers are supposed to document their systems so that others can work on it later. In reality of course, this is rarely done.  Any token documentation that does emerge will in all likelihood be inaccurate, incomplete and difficult to understand.

There is no economic incentive to spend any serious time on system documentation because, unlike user documentation, it is not part of customer deliverables.  So it is eternally put off, or given to an intern or a junior hire who will spend a challenging few weeks producing a set of documents that no one will bother to check for quality, for the simple reason that probably nobody will read it. So it ends up as shelf ware or server ware – except when IT needs something to show the auditors: ‘See, we have documentation. We are good people. Now go away and leave us alone !’

At the end of the day system documentation is like an insurance policy. You don’t know what’s in it until you’re in trouble, and then you discover you’re not covered for much.

TESTING – PASSING THE BUCK

In the manufacturing industries, testing is basically ‘just in case’ testing, ie you’re almost sure you got it right but you’re just checking. You’re therefore happy when you don’t find any defects. In IT, however, it’s the other way round. You’re sure you didn’t get it right, and you’re damn well going to prove it! You therefore expect to find defects, and if you don’t, then you’ve got a real problem! In fact, there’s a truism in IT which says that a good test is one that finds a defect!

There are four categories of testing: unit testing, system testing, integration testing and User Acceptance Testing (UAT):

·         Unit testing:  This first phase of testing, which is done by the developer who coded the programme, usually uncovers the most bugs. By the time he’s finished, he knows there’s still a lot more to be found, but he’s pretty fed up with testing by now.  So he hands it over to another developer, who tackles it from a different angle, and finds yet more bugs. Once they’ve fixed these bugs they announce the completion of the unit testing phase, not because there are no more bugs to be found, but because they don’t know where to find them – and in any case they want to get back to some real work. So they pass the buck down the line to the system testers.

·         System testing :  System testing ensures that all the different parts function together as a whole. So if you enter a test order for two widgets and a packet of nails in the order entry programme, and the invoicing programme prints an invoice for two nails and a packet of widgets, then you know you’ve got a problem. System testing usually ends when they run out of time, definitely not when they’ve found and fixed all the bugs, which they never will. And in any case, they know they can pass the buck down the line to the users…

·         User Acceptance Testing (UAT): The buck stops here! After IT has finished its part and hopefully delivers something workable, the users do a final round of testing, which is as real as it gets before going into production. UAT is like trial by jury. When the users are done, they go away to deliberate, leaving IT to wait an agonizing week before knowing its fate. When they finally emerge, they either proclaim the application good enough to be put into production (ie reasonable bugs), or they charge IT as guilty (ie beyond reasonable bugs).

The final phase of testing, the real one that discovers the remaining bugs, is called production.

OPERATIONS – THE REVENGE OF THE NERDS

Ops run production systems. This is probably the most technical and procedures-oriented part of the IT organization, because it manages the complex hardware, software and networking infrastructure that runs the core applications of the enterprise. Now there’s a thin line between being procedures-oriented and being bureaucratic, which explains why Ops staff are often negatively viewed by both users and their colleagues in IT, as illustrated by the following question: ‘How many Ops staff does it take to change a light bulb?’. ‘We can change the bulb in five-to-ten working days. If you have a valid work request number and you submit your application before 5pm, we can get it changed within 24 hrs. And don’t forget to put your name and cost centre code in the upper right hand corner of the light bulb application form.’

Which is all a bit unfair, because if the company’s core operations were impacted (orders, billing, finance, etc), then these same users and the rest of IT would be the first to press for better procedures.

One of Operations key tasks is seeing to backups. No other industry is so obsessed with avoiding information loss; having your PC crash and not having a backup can be a very traumatic experience. It sits right up there with other personal tragedies like having your car stolen or getting audited by the IRS, which require counseling and time off. We’ve all seen such people at work (‘you don’t want to go near Joe this week. He’s in a foul mood because his PC crashed and he’s got no backup.’

 So Ops instructs users to back up their work onto the server every day. But that’s not enough. Modern servers operate at only 99.9999% reliability, so we clearly can’t take any chances here. We therefore make a backup of the backup. And if we’re really paranoid, we’ll make two copies and put them in different safes in different buildings – maybe even in different parts of the country! And the amazing thing is that even with all these precautions, people still find themselves at least once or twice in their lives suffering this particular form of personal tragedy. I guess it’s like seatbelts – you could probably pass a law (‘Backup – it’s the law!’) but you’d still find people who forget to make backups.

So it doesn’t really matter what people think about Ops; as long as they can provide users with their latest backup, they’ll always be forgiven their bureaucratic side. MG

IT cannot harm the business, or through inaction let the business come to harm 

In his famous science fiction epics, novelist Isaac Asimov handled the conflict between humans and robots by hard-wiring the three laws of robotics into the latter’s positronic brains. Clear, established rules governed all human/robot interactions, protecting humans from robots:

1. A robot cannot harm a human, or through inaction let a human come to harm.
2. A robot must obey the orders given to it by a human, except where such orders would conflict with the first law.
3. A robot must protect its own existence, except where this would conflict with the first two laws.

Given the sometimes conflicting relations between users and the IT department, we could also use some clear, established guidelines to govern all user/IT interactions. My suggestions for the three laws of IT follow:

Law No. 1: IT cannot harm the business, or through inaction let the business come to harm. This one would really get IT off its collective butt and into proactive mode. No more waiting around until Joe User decides it’s time to build a data warehouse a year after the competition has already been there and back. And when a new system is finally implemented, it had better work or the business might be harmed. IT would be expected to anticipate user requirements and be judged by the effect its systems have on the bottom line.

Law No. 2: IT must obey the orders given to it by a user, except where such orders conflict with the first law. Things get even better here. For users, no more battles with an uncooperative IT staff hiding behind technical excuses that can’t be proved or disproved. Straight questions must yield straight answers.

For IT, all user requests would be evaluated on purely business grounds, with the first law acting as a control for users who might inadvertently harm the company, as in the following example: Sales director to IT: ‘ I want the new SFA (Sales Force Automation) system in place within three months. ’ IT reply: ‘I’m sorry, Dave. That is unrealistic. A failed implementation could impact sales, and I cannot allow that. ‘

The second law would really reap benefits when IT can simply refuse to build certain applications until users revisit the underlying business processes to make them more effective.

Law No. 3: IT must always protect its own existence, except where this would conflict with the first and second laws. The ultimate sanity check. IT would counter any threats to its existence, unless it could be shown that the business stood to gain from its elimination. (Fat chance!)

IT would be guaranteed its rightful place within the organization, exempt from any hatchet jobs by know-it-all, MBMA (management-by-magazine-article) users or VPs with hidden agendas. Even outsourcing would be stopped dead in its tracks under the third law, because the CIO would have to be convinced that dismantling IT would benefit the business.

With the three laws of IT, everything would be under control. No more having to deal with cranky users who don’t know what they really want. No more building systems to support inefficient business processes. And no more coping with the enlightened user who seeks his 15 minutes of IT fame by trying to deploy a home-grown PC application on the network.

Now who would have thought that being a robot could be such fun?

Copyright 1995 by Computerworld Inc., One Speen Street, Framingham, Mass. 01701.  Reprinted by permission of Computerworld.  All rights reserved. 

MG

Natural selection seems to apply to users too – only the fittest survive outsourcing!  

Now who decided to call them users? It rhymes with losers – which probably explains why the only other category of people to be graced with this term are drug users. Then there’s the anatomical variation called end-users – probably justified given how often they have to take it up the tailpipe. No, there is absolutely no doubt about it: the term user is so negative that it could only have been coined under negative circumstances. 

An apocryphal story holds that the term originated during the first wave of computing in the fifties, which targeted the massive replacement of administrative staff by computers. These were the original clerks (in their Clarks Originals), personified by a timid Jack Lemmon in the 1960 academy award-winning movie ‘The Apartment’, co-starring Shirley McLaine. The opening scene sees him sitting with a hundred other grey-flannelled insurance clerks in orderly rows of desks, toiling over slips and vouchers with pencil, paper and an adding machine. Once these people figured out that all those IBM salesmen in the corridors couldn’t all be coming to buy insurance, they knew their jobs were on the block. So the more cynical amongst them started to refer to themselves as the losers of the upcoming computer revolution. 

Then, as inevitably happens when common sense takes a back seat to lofty objectives and unproven technology, it soon became apparent that so-called unskilled office work wasn’t that unskilled after all. A lot of human intervention was required for handling exceptions, something which no computer could hope to do. So the clerks weren’t going to be phased out after all, at least not in numbers anywhere near those dreamt up by the techno-visionaries. So rather than be replaced by computers, our supposed losers were actually going to start using computers (or strictly speaking the output of those computers) to work more effectively. So the term loser gradually evolved to user, and the term has stayed with us to this day.  (Of course, if you can believe such a story, then you probably are a loser!).

There are two categories of losers – sorry, users – in the organization: 

• Back-office users, who stand at the back of the line and have little say in the type of systems inflicted upon them. They are the enterprise equivalent of workers in the engine room – they keep the ship moving, but you want to keep them out of the sight of customers.  Back-office users come from the traditionally automated functions like order entry, accounting and billing, and are associated with systems like ERP (Enterprise Rectal Pain). 
• Front-office users, who stand at the front of the line, and whom IT has to bend over backwards to please. They are in direct contact with customers and bring in the money, and as such need to be kept as sweet as possible, lest their dissatisfaction starts to impact revenue, or spills over to the outside world. Front-office users come from recently-automated functions like sales, marketing and customer service, and are associated with systems like SFA (Sales Force Aggravation) and CRM (Can’t Really Matter). 

The differences between these two categories are manifest in their relationships with IT. Back-office users, for example, have no option but to use whatever system is being proposed – or rather imposed. At the level of Joe or Jane User in these functional areas, you don’t usually propose anything; you install it and then train people for the new procedures, which are not open for discussion. Whether they like it or not is hardly the question. They have to use it, because their previous system has been unplugged, and without a system, they cannot do their jobs. 

Front-office users, however, are relatively new to automation, especially the largest group amongst them, the sales force, who historically have always worked without a system. Their job is to sell and make their numbers; how they do it is secondary. So if for whatever reason they’re unable or unwilling to use a new system, all they have to say is that they won’t make their numbers if forced to use it, or that it’s negatively impacting customer relations. And since there is theoretically nothing to stop them from making their numbers the way they’ve always been doing before the project came along, any new front-office system is ultimately ‘discretionary’. After all, sales commission plans don’t include big bonuses for ‘achieved 100% compliance with the CRM software process manual’.  

So IT can be, and often is, extremely heavy-handed in its relationship with back-office users. It makes little distinction between them, and mistreats them equally badly.  However, it steps lightly and wears kid-gloves when it comes to the front-office.  And even within this privileged group, there is a clear pecking order: 

• At the top there’s the sales force, because of their size and the fact that they bring in the money that pays everyone else’s salary. IT doesn’t want to mess with this group. A failed SFA or CRM project is one of the quickest exit routes for the CIO. 
• Next comes marketing, which is the enterprise equivalent of your mother-in-law: their view of the world is not always grounded in reality, and they’re always interfering, but you can’t have a marriage without one. For example, the marketing department of one long-distance telco created a campaign that targeted prisons because of the high volume of outgoing calls from the captive – no pun intended – client base.  But this was a non-starter because, not surprisingly, prisoners prefer to use cell phones. So while an angry VP of marketing can still give the CIO a hard time, he or she will probably survive a system that doesn’t deliver. 
• Customer service is the most junior member of the front-office club because it’s a cost-centre staffed with call-centre agents on minimum wage. So not only were CIOs never in jeopardy of losing their jobs with this bunch of losers/users, they actually had the upper hand and shipped their jobs off to India. 

The moral of the story is that users are not all created equal; there are users and losers. It would seem that Darwin’s natural selection applies here too: only the fittest (in terms of costs and organizational influence) survive outsourcing – just ask any call centre agent. MG