Crystal balls

It’s always fun to speculate about the future.

History is of course littered with men who made predictions which were ever so slightly wide of the mark: my favourite is the prediction of Thomas J Watson, IBM president in about 1950 who opined: “I think there is a world market for maybe five computers.” To be fair to him, that was probably true of the computers of the day, but even so it was a bust flush by the time the fifth was delivered.

To take great leaps of imagination about the more distant future is relatively safe. I could aver that by 2100 we will be taking holidays on Mars, and we might agree that this is an interesting speculation, but since both I and my audience will be dead long before then, it is not exactly sticking my neck out.

Looking at the near future, extrapolating from the world today is more interesting: it is possible to get pretty close to what is likely to happen, but getting the timing right is much more difficult. For example, the use of mobile handsets to run non-telephony applications has been not only long predicted, but operators have been trying to go there for some years now. Only recently however has this started to become the norm with modern high spec smart phones now reaching the mass market.

Now I started to think again about predictions as we seem to be debating the future on several related communications issues. We have the concerns about delivery of television programming, and the (this time predictable!) self-interested complaints from Mr Murdoch; we have comments about the potential demise of newspapers due to competition from digitally provided news; there’s discussion about how we deliver faster broadband across the country (and who pays), and meanwhile the mobile operators are at last moving their services into information provision (or at least enablement for third party information providers), fuelled largely by the surge in smart handsets – thank you again, Apple, for the stimulus of the iPhone.

I’m sure we can draw some strands out of these trends. Here then are my top five predictions.

1. Broadcast TV is doomed.

The BBC iPlayer is the first step in this process. Essentially, we will all move more and more towards watching what we want, when we want it, from the internet – even for live events: not home in time for kickoff? See it from the start when you do get home.

This would mean the TV channel companies becoming more aggregators of content, probably published on a daily or weekly basis, rather than to a serial timetable like today. Content providers will be like the TV production companies or film companies today, and may well start publishing directly since they don’t need airwaves.

I would not be surprised to see the BBC therefore become more a channel to market for published content, including pay per view (which is much easier to arrange on the internet), and focusing its production efforts more on information and news services.

Of course, all this requires adequate high speed internet access – and a lot of it will be mobile. The government no doubt will be slow to give up on TV due to all that investment in the digital switchover, but the frequencies can no doubt be put to other profitable uses, including more wireless internet services. I wonder what Sky will do with all those satellites?

2. Telephony is doomed.

OK, I’d better qualify that a bit. What I mean is that making and receiving voice calls over a switched network is already looking outdated. Skype is pointing the way: internet based voice traffic (VoIP) is increasingly how both business and personal calls are made – unless a mobile is used. And in the case of mobile, with more handsets becoming WiFi enabled and mobile broadband aware, I see VoIP increasingly the way in the mobile world as well.

What this really means is that both fixed and mobile networks will evolve into data only networks delivering just broadband service, with old fashioned switched voice dying a death. It already irks that there is a complicated tariff for voice calls, and in order to attract customers they have to build even more complicated products to give a lot of it away again. Very little call traffic nowadays actually needs individual call pricing: premium rate numbers perhaps, where the operator is collecting a fee for the called party, and – er – well, nothing else really. Even calls to other operators’ networks – including international – could be covered by inter-operator agreements given the low cost of carriage over IP.

This will change all sorts of areas. Billing systems can be much simplified with no need to price most calls, and with effectively all bills becoming prepaid monthly service charges. Quite a lot of things will change in the networks, with no further need for voice switches and IN platforms – ‘calls’ will still need some form of processing but not through this technology. Even the needs of security forces will be impacted – phone taps are different in VoIP networks!

3. Books are doomed.

Alright, I don’t really mean it, but I do think that we are close to the point where eBook readers will become mass market. I doubt we will see dedicated eBook devices, but I do anticipate that smart phones and notebook PCs will quite soon start to become the devices of choice for books (and, indeed, whatever passes for newspapers in the new digital age). As people become accustomed to taking these devices everywhere, thanks to the ‘internet anywhere’ attitudes now emerging (maybe this should be a prediction too? – no, it’s already happening), no-one will want to carry a large paperback as well when it can just as easily be downloaded for no extra weight.

This will have considerable ramifications for the publishing industry. Anyone will be able to publish their latest novel; the only value the publisher will add will be the marketing organisation and revenue collection – oh, and the ability also to produce the hard copy version (which I’m sure will still exist, albeit in reduced form, much like CDs today alongside MP3 downloads).

4. The ‘core network operator’.

It has been interesting to note the growing proliferation of Virtual Mobile Network Operators (MVNOs), buying their airtime in bulk and then addressing everything from tightly focused market sectors to broad spectrum markets. In addition we have the recent coming together of Orange and T-Mobile in the UK.

In effect what is happening is that we have a saturated market – no likely significant growth in the overall subscriber base – and a steady erosion of revenues as services become commoditised and competition drives prices down. The operators are trying to push up the added value chain with triple and quad plays and data services, but network costs are a significant issue for them. One of the significant factors for the Orange/T-Mobile merger is in network savings.

Now in effect we have only two national local loop wireline networks in the UK: BT and Virgin Media (other networks from the likes of COLT are local and business oriented). Virgin’s network is of course dominated by television; but BT is increasingly losing out on telephony service delivery to many other wireline service companies, such as Talk Talk. This ecosystem nevertheless continues to be sustained on the single local loop network that BT runs as a regulated service.

But we still have four mobile networks, effectively providing the equivalent of a ‘mobile local loop’. Now I can see continued cost pressures reducing that number further – even perhaps to one regulated core network? Wouldn’t it be better for the network operation to become a separate business, delivering service through as many MVNOs as wish to set up in business? There’s plenty of market space for the likes of Virgin Mobile, Tesco, and so on to compete for the end user, so why should a mobile operator sell them air time, only to compete with them for customers, and all the while groaning under the cost of maintaining an expensive national network? Might it have made sense for Orange and T-Mobile to combine and float off their networks and continue as separate retail companies?

5. A wallet on my phone

The advent of the electronic purse has been predicted for a long time, but progress has been slow. Mobile operators have explored how this might work for several years, but trial services like buying your can of cola from a machine have not been wholly successful – the palaver of texting to make a payment is so much more long-winded than sticking a coin in a slot. Operators have shied away from serious solutions partly because of concerns about straying into the territory of banking regulations, money laundering and so on.

This is an area where more advances have been made in developing countries – particularly in areas like the Philippines – where banking is less well developed or accessible to ordinary people. Services are now available there for transfer of small amounts of cash, using the mobile phone account as a kind of purse. This is another key development – it’s one thing to use a phone to pay a retailer, but the ability to pay small amounts to friends and family is what will make this into a mass market service.

I am not an expert in financial regulation, but I suspect the pressure to be able to deliver such services in the UK will lead to ways being found before long.

So in conclusion, I don’t think these are particularly outrageous predictions; however getting the timing right may be tricky. I don’t think I’ll stick my neck out there...

Tweet

What's in a name?

I've been in the IT industry for - well, you don't need to know, but suffice it to say many years. There has been such huge technology change in that time: when I started as a trainee, there were no personal computers, only monolithic mainframes which you programmed by writing code with paper and pencil, and then sat at your desk and effectively executed the program line by line on paper. When you were happy, you sent this to a room wherein young ladies of the type much admired by male trainees typed onto punched cards for loading onto the mainframe.

But it's not so much the technology change, constant and amazing though it is, which I am interested in exploring here; it is the continual change in job titles. Thus I was a Programmer, but these days of course you don't have Programmers, you have Developers. You don't have Programmers because you don't write Programs any more, you write Software. I don't know why the change arose, because despite the technology now enabling code writing and testing to be done online and in real time, it is still essentially the same job of producing logic instructions to achieve a business requirement.

In the main, however, the issue driving changes in job titles is essentially one of 'job inflation'. When I started my career, a company was administered by the Board (as it still is today), but headed by a Managing Director, assisted by the Finance Director, Operations Director, Sales Director and so on. Then there was the management layer, where the managers were all called - well, Managers. At the Project level, you had a Project Leader running the show, and within the Project there were Teams, each led by a Team Leader.

Then it was decided that being called a Manager was not sufficiently important sounding, especially if you were in Sales, and if you were called a Director you sounded much more impressive to a prospective client. That in turn meant that the Board's important titles were diluted, because you couldn't tell if a Director was really important or just moderately important.

Much the same thing happened in the States, where Directors were known as Vice-Presidents. A few years back, I encountered the delightful title of "Vice-President of Blue Sky", which I gather meant he looked for new business markets. (So were existing customers, by implication, Grey Sky?)

So the Board members became Chief Officers, and the Managing Director as a title now means the head of a subsidiary or division.

Interestingly, there is now a trend where the management layer is populated not by Managers or Directors, but by Heads of Department. My own favourite job title, which I came across recently, is "Head of Web", a title I now espouse when assisting the technologically challenged amongst my family. They of course, in their ignorance, still think a Head of Web is what you find in those corners you don't dust as assiduously as you should.

Now, large developments are not just big Projects, today they are Programmes, and Leaders have become Managers (since the Management layer no longer needs the term, and it sounds more impressive than Leader). Except that even quite modest developments are now Programmes, so that what used to be a Team is now a Project. Thus the leader of a small team is now a Project Manager, and quite possibly has no Project Management training or accreditation. It is getting harder to decide if it is better to present myself as a Project Manager, a Programme Director or a Head of IT Implementation.

We have also started to see that the leader of some project teams is known simply as 'Lead'. Thus the head of the Testing team, who has recently been known as the Test Manager (Head of Testing is obviously too grand for what is an essential but regrettably unglamorous role), now seems to be increasingly termed 'Test Lead'. Clearly this is not the same as Test Leader, because we don't want to go back to the past, and Lead sounds more modern - or at least, with the use of an adjective as a noun, more American.

So, where next? I suspect that the next round of title inflation is overdue, that the Director will become a Chief of something, if not a Chief Officer, and all Project Managers will become Project Directors. This will only be acceptable to the Board members if they in turn have their escalation route mapped out.

I have a suggestion: how about Minister? After all, the important Government ministers are now all Secretaries of State, so their importance can still be maintained. And I would love to go into a meeting with my Board level boss and be able to agree by means of a simple "Yes, Minister!"

Tweet

Agile Waterfalls?

There is something of an ongoing debate at present concerning project methodologies between the traditional approach known as Waterfall, and the new kid on the block, Agile, which has become somewhat - dare I say it - trendy. So is it appropriate to change IT development strategy from Waterfall to Agile?

Now there are many different flavours of each of these models, but broadly speaking the principles of each are as follows. Waterfall requires that the project moves through defined stages (broadly - requirements confirmation, design, development, test, acceptance, deployment), whereas Agile is about reducing time into service for software developments by establishing a collaborative relationship between developers and users, and using iterative development techniques to ensure best correlation between requirement and solution. This is normally achieved by time-boxing the overall interval between releases to typically 3 months, and by reducing the project stages to four: release planning, where the approach to the release, including dates, budgets, resources and functionality focus areas, is agreed with the principal business sponsors; the hothouse, an intense, competitive workshop over normally 3 or 4 days to agree the requirements scope and the business case for the release; iterative development, a period comprising typically four or so iterations through the development cycle, delivering successively refined prototypes of the solution; and finally deployment into service.

So should all developments in future move to an Agile model? Agile certainly has some key benefits that are highly relevant to certain project scenarios.

Implementation of new products and services in a fast-moving business can happen more responsively due to the short release cycles. This in turn leads to increased customer satisfaction due to rapid delivery of usable functionality.

There is a closer relationship between business benefit and functional delivery prioritisation, which has to be a good thing. Furthermore, the close co-operation between users and developers leads to a better understanding of the business by the developers, and an increased sense of collaboration and ownership of the solution by the business.

New requirements that are developing during a short implementation timeframe can be accommodated in a method which allows for some flexibility of requirement and prototyping during the development iterations.

However, there are also disadvantages of Agile compared with Waterfall.

Pressure for throughput of development can lead to short-termism of design - a lack of attention to the overall solution architecture and the way that this supports future flexibility and maintainability. Similarly, the rigidity of the time-boxed development cycles can lead to releases being changed in scope at a late stage.

Agile relies largely for its success on a high level of involvement of user communities with the development teams through the iterations, in order to maintain a close link between requirement and solution. This is much harder to deliver effectively where the development teams are off-shore.

Developers need to be experienced and responsible in order to maximise business benefit from the development cycles. This can also be an issue with Indian development teams due to the strongly hierarchical culture in India. Furthermore, it can also increase the average cost per developer day, as it is harder to use more junior resources effectively.

Requirements documentation is often insufficiently precise to form a sound basis for acceptance (or indeed for business process amendment and staff retraining) and can lead to commercial issues between supplier and user, as well as scope creep during development iterations.

Finally, because of the fluidity of requirements and delivered scope inherent in the Agile approach, it is harder to tie a supplier’s contract price to functionality.

In conclusion, it seems to me that where there is the need to provide change on an existing environment, and to keep that change focused on maximum return in a short timescale, then Agile provides a compelling case. However, for major developments - particularly for large scale IT refresh programmes (e.g. billing system replacement) or for greenfield developments for start-ups - there seems still to be a strong case for these being managed in a Waterfall based approach. But there are lessons to be learned here from Agile experiences: large Waterfall projects also benefit from being broken into appropriate phases for frequent delivery of value, from establishing and maintaining a close involvement of the relevant communities within the business, and from a more progressive approach to Acceptance.

Although the advantages of Agile are widely promoted at present, it is also becoming increasingly clear that not every project would benefit from being implemented through wholly Agile techniques.

Tweet