There is a fierce bidding war going on between thetingleytroll and katybuchanan.

As I type, the troll has got it up to £32. & still 1 day 1 hour 11 minutes to go…

All for a good cause etc.!

We have our first bidder for the “baby crying” sign. I suspect the technophobe may have got his finger out as the user name is “thetingleytroll” which is the jokey name for the bloke who collects Butlins ephemera down Tingley way. Yes, he is short, but not green, you’re thinking of Fungus the Bogeyman…

(This article was part four of a series intended to develop a theme for a presentation at the Enterprise Networks Conference 2004, an event which included the CMA Plenary keynote session. See www.enterprisenetworks.co.uk for more details)

When I was in the throes of youth, presence meant actually being there, typified by dear Blondie always being touched by it and Level 42 perfecting it in silence physically.

Charismatic people are sometimes described in terms of their presence dominating the room through force of personality, apparently an essential must-have for MP selection in the days where empathy was less important than staying on message & winning arguments.

Presence doesn’t always mean people, as sung by Alison Moyet going weak in the presence of beauty in 1990.

When the Internet became recognised as a serious business tool, the term presence became accepted to mean having a web site, whether a simple page, a full e-commerce site or all of the variants in between. Indeed a straw poll of ICT people suggests that this is still the general view, although “increased presence” generally relates to improved rankings on the major search engines rather than bigger sites.

From a communications perspective, presence can be thought of as a real-time indicator of likely availability when someone wants to contact someone else. Does this already exist? On some channels but not others.

· With voice, you generally don’t find out if someone is available until you call them, at which point you may get busy tone, get routed to messaging, get answered by someone else or get ignored. In sophisticated PBX systems, the Operator may well be able to see that a user is on the phone or has redirection activated (or possibly has “Do not disturb” with a given reason, such as on holiday or in a meeting). With feature phones, it is often possible to get visual indication of colleague status so that ascertaining when to call is easier. The use of CTI soft phones is making this more flexible but there is still some way to go.

· With mobiles, the likelihood of contacting someone is probably higher provided that they carry their phone around with them in a pocket rather than leave it in a jacket or handbag. However, it still takes a call to find out & there is the possibility of being rebuffed through use of the call reject key, whether a reaction to circumstance (in a meeting, driving etc.) or conscious rejection (I don’t want to speak to him….!).

· With email, the message is sent in hope of being read but there is a certain level of faith involved. An out of office message may advise on non-availability but the reply might come in a few seconds, a few days or never. The same applies to SMS to the extent that if it doesn’t get received immediately it could be delayed considerably.

· With instant messaging, presence is essential- if someone isn’t available then they can’t be contacted. Users create a “buddy list” which is updated real-time showing who is online. Of course, depending upon the implementation, people may be sending messages to users who are showing as available but they aren’t actually sitting at their PC, which may be in screen saver mode.

· With video, the same constraints as voice apply, although once desktop video becomes widespread there is scope to improve this for users not overly hung up about privacy.

· When we take mobility into consideration, another form of presence is whether a user is actively logged on to a specific application or on the network in general. The latter is currently problematic in that whilst we might know when someone last logged on we can’t be entirely certain they still are. Indeed they could be logged on at more than one PC.

So we can see that presence is around but not particularly joined up across the channels. How would we like presence to work?

When we want to contact someone, we make conscious decisions as to what channel to use based on our own perceptions of importance and urgency of the topic. They are influenced by knowing something about the likely response of the other person, i.e. there may not be too much point discussing a complex spreadsheet to someone equipped only with a mobile and a car driving to Edinburgh. They are also tempered by the reality of realising that our own perceptions of importance and urgency may not align with the other person, particularly if there is a seniority deficit.

Sometimes we choose a less than ideal channel out of deference (without even realising).

We may send an email to someone hoping they will ring us because we can’t get past a defensive secretary or we know that they use voice mail as the first line of defence and triage to the level that they never quite get a round tuit. Conveniently wandering past their office often circumvents this but what if they (or you) are 300 miles away or work from home?

Working from home focuses the mind considerably, as that human need to interact with others and feel part of a team is heightened by the lack of contact, even for Agents who talk to Customers all day. Without the comfort of being able to walk around a workspace and see who is in, at the coffee machine, in the restaurant and so on, it is easy to end up feeling detached from belonging. Technology cannot be a panacea for this, but it can go some way to making communication more effective.

How do we want it to work? The instant messaging approach is a good start. We create buddy lists of people we regularly collaborate with and we can see at a glance what contact method is going to work at this moment in time. The traffic light analogy works well-

· red means stop, this method will not be successful (e.g. on the phone, all calls forwarded, currently in a collaboration session)

· green means go, you will almost certainly be able to communicate with the person in real-time. Of course, they may decline to respond due to particular mitigating circumstances (building being evacuated, off for a fag break, don’t like you etc.)

· Amber means warning- it may not be successful as the user is around but not near the phone, logged in but in screensaver mode, mobile switched on but possibly out of contact (poor signal area, in the basement, in a tunnel).

· There is also a fourth state on the traffic light- greyed out (phone unplugged, PDA switched off etc.)

To make this more effective, we want hooks into all of our applications & devices so that it becomes embedded and ubiquitous, coloured entries in our mobile directories, icons in our inbox, even traffic lights on our telephones.

What about people who are pseudo-buddies? Ones we might want to interact with occasionally or on a one-off basis but not to the extent that they are worthy of a constant refresh on our devices. For this we might want the presence equivalent of ring back when free, a check availability button that gives us a snapshot of their public presence status (and preferably not have to pay 10p to use it!)

As someone with a buddy list, this implies making presence information available to others. In this case, it needs to be somewhat Shrek like (Ogres are like Onions) in that it starts off simple at default settings and complexity can be layered to suit so that, for example, during the annual appraisal the only thing that intrudes is the Halon being triggered in the Server Room. Similarly, when generally available, calls from recognised Telesales nuisances go to the messaging equivalent of spamtrap.

There are great claims made for presence- it is suggested that Tel-Tag & multiple contacts can waste up to 20 minutes or so of a typical business day. The reality is more mundane, of course, as that doesn’t necessarily translate to 20 minutes of increased personal effectiveness.

What presence needs to become essential is to prove itself incredibly useful. This means that green lights represent that the other person will definitely see or hear what is sent every time in a timely fashion. How can we ensure this? We could include passive infra-red detectors (or RFID detectors) in our hardware so that there is a high probability that there is someone actually at the desk (or looking at a PDA) when status is green. We can make a lot of the status decisions be based on sensible intelligence- if I am collaborating in a desktop teleconference I don’t want instant messages from the security man asking me if I still have the garden shed for sale (but might want to know if he is telling me I have left my lights on). We have to allow for human error and mitigate against still being on holiday three days after coming back.

What else do we need? The Internet needs to come of age and turn into the Quinternet (the new made up name for the Quality Internet). We need more standards that are designed with presence at their heart rather than the current crop of applications emulating & postulating what is going on across disparate systems. We need seamless integration, Carrier Class ruggedness on hardened Servers, robust software that is particularly resilient in the face of adversity, rather a lot of bandwidth for the vast amount of overhead that all of this burble will generate and a lot of innovation.

There are a lot of things still to get right but if you listen carefully, that grinding noise is the sound of a paradigm being shifted. It isn’t very loud yet but it will turn into a roar.

PC Woody seems to be off the air and has been so for a few days. It told the tale of a new recruit who had given up IT services in favour of becoming a Bobby instead. I wonder if she has had her collar felt?

Meanwhile PC David Copperfield continues to amuse the thousands of us who follow his robust views at The Policeman’s Blog. He does his anonymously but I’ll bet there is a big manhunt going on somewhere & the secret squirrels know who he is.

Both of you, may the Force be with you….

This article was part three of a series intended to develop a theme for a presentation at the Enterprise Networks Conference 2004, an event which included the CMA Plenary keynote session. See www.enterprisenetworks.co.uk for more details

What do we mean by resilience? One dictionary definition is “able to quickly return to a previous good condition”, giving a rubber ball as an example. For people, we generally mean bouncing back after some hard knocks, whether physical or emotional. For Telecoms systems, it is perseverance in the face of adversity, the Pony Express rider ensuring the mail gets through whilst dodging bandits and arrows (or fires in cold-war underground tunnels!)

Phone systems are real-time in software terms- the most important thing they have to do is notice events happening and act on them in timely fashion. These events are generally quite low level, i.e. a user has pushed a button on a featurephone, a DTMF digit has been detected on a trunk line, an E1 interface has received a signalling message, the technician has pressed a key on the system terminal. (In the 1970s, it was lower still- the processor was often keeping track of every dialled digit, validating it for speed, make/break ratio, inter-digit pause etc.)

What often isn’t appreciated is that in many systems letting go of a button on a featurephone is also an event- how else could it be possible to buzz-buzz your Secretary?

There are also a corresponding set of “non-events” to be handled- i.e. timeouts where something should have happened but didn’t. An example of this is a user being given dial tone but not doing anything about it. Often the hardware will react to non-events from the software as well- sometimes called a watchdog timer, to capture the situation where St. Vitus gets involved.

The software architecture will normally revolve around something called a work scheduler- this is the main engine that allocates tasks according to their importance. Giving a user dial tone may involve several iterations around the loop- firstly recognising the event at a low level & ensuring it is placed into the correct signalling buffer, then recognising what the transition actually means, i.e. a user appears to be initiating a call and it isn’t a priority user so put it into the correct call processing buffer, then eventually allocating resources & providing dial tone when it reaches the head of the queue.

So our system is constantly working very hard looking for something to do & leaving imaginary timed notes for itself to check up things that don’t happen when they should. So far, this isn’t that different to what any computer system would be up to, be it an enormous supercomputer at the Met Office or a humble Gameboy in your child’s bedroom. The difference comes in the resilience- being able to keep going despite all odds.

Hardware resilience comes in the form of robustness- duplicate or triplicate processors that work in co-operation or hot standby to ensure call processing continues. Mirrored memory, dual interfaces, backplanes & power ensure that most likely hardware failures result in minimal interruption and automatic recovery.

Software resilience comes in the form of recognising hardware faults and recovering from them. It also means recognising unexpected software outcomes and recovering from them, as well as producing an audit trail so that the situation can be duplicated & a solution found. Providing tools and alerts for the maintainers to ensure optimal service delivery varies from product to product & is generally much more simplistic for a Business system than for a Public Exchange.

In the phone system, unexpected events are hopefully worked around, provided that the scenario has been recognised by the designers. As the only software that runs on the system is proprietary there is a high expectation that outside of beta trials, the systems will run stable. Or, more accurately, they appear to do so- most systems run housekeeping routines that “tidy up” after the call processing routines and close scrutiny indicates that the garden is not totally rosy. Phone systems have generally evolved from older systems where memory capacity, processor throughput and intra-system bottlenecks have resulted in constraints. Stress any one of these and even the best known systems start to behave oddly during the busy hour. (This is inevitable as it is never possible to test for absolutely every eventuality in a complex system).

Contrast this with Servers. High end Servers are available that have redundant power supplies, robust disk arrays, hot swappable cards etc. Whilst they are not totally duplicated internally in their architecture (don’t be fooled by the number of CPUs) they can be clustered together in order to make them more powerful and resilient. Unfortunately, however, it is all too easy to load any old software onto them.

Are they suitable for call processing? They can be, provided that call processing is the primary function, or indeed the only function in a Windows environment. It is also a good idea to have automatic routines to enforce the occasional out of hours reboot in order to minimise the impact of memory leaks. Similarly, call processing needs to be executed as a “service” so that it starts again automatically and the device needs to be tuned for optimal behaviour, something not particularly suited to the ICT policies of using a preferred Server build and load.

Another thing about clustering- it comes in more than one flavour and may require intervention to recover from fail-over. The most useful approach is where one Server can be taken off-line for patching or upgrade whilst the other does the work & then vica versa, preferably seamlessly. This doesn’t entirely exist in the real world, although high availability is possible, even if zero downtime doesn’t. Also, be prepared for occasional intervention whilst the typical Server response to an unexpected event continues to be the “blue screen of death”.

Of course, there are benefits. Servers are streets ahead of legacy phone systems with Ethernet and network connectivity. Woe betide anyone who naively put their Option 11 onto the network without an intervening router, as the system would spend more time watching what was going on out beyond the RJ45 than attending to low priority call processing tasks. Servers enable applications to communicate with each other efficiently and effectively, whether across the LAN or the WAN.

Something that does need to be taken seriously on Servers is in managing threats- without the latest patch fixes they are vulnerable to attack, as are the intervening network devices, increasingly so if they are from Cisco.

We communicate most effectively using all of our senses, i.e. sight, hearing, touch, smell and taste, along with an awareness of acceleration and gravitational force through our balancing mechanisms. ICT mainly concentrates on sight and hearing (once you put aside oddities like Sensurround, Smellovision and Theme Park rides).

Voice communication has an immediacy & convenience factor that has made the humble telephone omnipotent in the developed world and the penetration of the mobile telephone even more remarkable. The convenience factor is a double-edged sword, of course, as it is frequently inconvenient to receive calls and often downright intrusive. The Unidirectional equivalent of the phone is of course Broadcast Radio, although the Tannoy system also fits the analogy.

Text communication has progressed through Telegraph, Telex, Fax and Email, with an exponential increase in content potential and effectiveness. Fax added imaging, the first “rich text format”. Email gave the ability to attach data, graphics, pictures, sounds and programs. However, it remains a unidirectional, non-real time channel, in that whilst it is possible to have email conversations, they are by their nature asynchronous. SMS and MMS are mobility approaches to un-tethered rich text channels and Instant Messaging is an interesting hybrid of immediacy that can be more effective in contacting someone than persistent phoning.

Combining sight and sound, we have Video Conferencing which is poised to become commonplace on most desktops, along with Video messaging, Video broadcast (multicast) and on-demand playback (unicast).

In Telecommunications there are also elements of communication not immediately obvious to the user, e.g. data flow from PCs to the Network, Clients to Servers, Applications to other Applications, housekeeping for connection management and billing.

This is definitely a fractured landscape for the poor old user, further complicated by Chinese walls between channels and devices for home and business use. (That sound you heard was the author giving himself a quick slap for jumping on the buzzword bandwagon).

So how can our new unified systems possibly hang together and work well? Let us take a look at the disparate communications channels that we might possibly want to bring together, along with the transport mechanisms, interfaces and deliverables. This diagram has had several iterations and adding further detail or subtlety has been abandoned for now. It is an exercise for the reader to join all the possible entries and associations together and not make it look a complete rat’s nest!

There are a number of challenges here. As the main theme is resilience, then let us consider what a UCI based system needs to do in a fairly straight-forward set-up, say a single-site office. It needs to communicate with all of the existing communications systems in order to be aware of what is going on. It may need to communicate with the back-office applications where there are associations (or hooks) into functionality. It needs to communicate to all of the users in order to serve their needs & be aware of their current availability set. It will have to be scalable for multi-site and nomadic use.

The important bit is that it has to be able to maximise the user experience in the event of any of these complex interactions failing or behaving inconsistently. Getting everything onto an IP backbone has to make it easier and given time, the other systems will be developed to be aware of and support UCI.

Next article- 21st Century presence, what is it and how can it be tamed?