Total Immersion

One of the most fun debates I have had in recent times was with a couple of execs from IBM and Cognos, and with a senior analyst from IDC, at last week’s Information On Demand event in The Hague. The question was innocuous enough - “what do you think is the addressable market for Business Process Management?” “That’s tricky,” I replied, “as I don’t believe that there exists a BPM market, as such.”

There followed a great deal of debate, at the end of which I remained to be convinced that there was such a thing right now as a BPM market. That’s not to say that BPM doesn’t exist - far from it, it is an essential facet of many technical capabilities. However it is exactly this factor that makes it very difficult to define BPM as a market.

Where can we see BPM? The ability to capture business activities and use them as a template for service delivery exists in many technologies, as indeed it has done for some time. We have for example:

• Within content management and collaboration tools, BPM is becoming an accepted term for that element of the software that manages the flow of content across different business roles.
• Within enterprise application integration, there is a clear need to understand how applications and dataflows map onto business activities. Initial releases of Microsoft Biztalk, for example, came unstuck until they built in this element.
• Within software development, a logical extension of modelling business processes as part of requirements capture, is to the use the models to support solution delivery.
• Enterprise applications such as SAP have long been delivered through customisable workflows, which require a level of management from a business process perspective.
• Also, BPM works hand in hand with IT and business service management from an operational perspective, such that service delivery can be monitored and supported appropriately post-deployment.

BPM is clearly a highly valued element of IT. But can it really be considered a market - and if so, how should it be defined? Should it consist of the superset of all of the above, or just the BPM element, if indeed it can be separated out in any useful way? Or should it consist only of the “pure play” BPM vendors, those which have a heritage in one of the areas above but are positioning themselves by leading with BPM?

My debating stance, which happens to still match with my opinion, is, “none of the above.” We discussed the comparison with the transport industry - throwing a car, a tank and a plane into a (figurative) bucket just because they all require an engine does not mean we can define the “engine” market. So, as with BPM, there isn’t a coherent enough boundary to frame a market space.

The debate did not result in any shared epiphanies between the participants (though its always nice when analysts from different firms agree). For me, the thought processes didn’t stop there: a few nights’ sleep allowed things to ferment, alongside all those other things I picked up at IoD, not least a slightly flummoxed acknowledgement about the value of Master Data Management. Absolutely nothing wrong with MDM per se, but I still find it quite surprising that it took the industry so long to work out it would be useful to have a single, shared, defining structure for structured information assets.

To whit: following other conversations it occurred to me that the real pain with BPM remained how views of business activities could be shared across tools. IBM claim export/import capabilities between tools such as InfoSphere and Lotus, for example. But what lacks is the knowledge of which is the “master” view - an issue exacerbated when we consider how such information is distributed (and worse, locked in) to applications and software tools across the organisation.

Perhaps what we need, like with MDM, is Master Process Management - tools that enable representations of business activities to be catalogued independently of any application, and then translated between one application and another. The sign-off of a form in the content management system may also signal the acceptance of a new customer in the CRM system, but such information is stored in the heads of those using the tools, and delivered as a point-to-point linkage. How useful it would (and I’m speaking from experience, having been involved in several such activities) to capture such information and relationships once, and use the “single view of business processes” to feed all of the above applications, if not more.

But let’s be clear. Apart from a couple of obscure vendors (pipe up, if you’re out there), such capabilities do not currently exist. There’s no MPM Gartner Magic Quadrant or Forrester Wave, and even if there were, few if any vendors would appear at all. All the same, if we did have MPM tools, I have no doubt that plenty of end-user organisations out there would be much better off. And indeed, we would have an addressable market.

It always seems quite ironic to me when I read how industry analysts are accused of ‘bigging up’ vendor offerings, when I and my peers seem to spend so much of our time resetting the expectations of over-optimistic marketeers. Indeed, without such a position, we would offer a far less useful service - on occasion I have been positively surprised that certain companies have wanted to work with us at all, given the utter trouncing we have given their products or how they are taking them, like Beanstalk Jack and his cow, ‘to market’. I should perhaps apologise (and I frequently do) for being so direct - we want people to get the best out of your technology, we really do, so we’d rather be straight with you.

As such, it can be quite a relief when something comes along that is so clearly, obviously useful to so many organisations. Like Internet Protocol (IP) address management, for example. I can’t confess to know the whole space in technical detail, but here’s the skinny from my perspective. It is a well-known fact that the number of devices that need an IP address to connect to the enterprise network, or indeed the Internet has rapidly outstripped the original numbering standard, of 32-bit addresses enabling a potential four thousand million addressable devices. Such things as Network Address Translation (where a local router/address server allocates IP addresses on an as-needed basis using a local subnet, and then translates between local addresses and a reduced subset of externally-visible addresses) have helped reduce the burden somewhat; as of course has the arrival of IPV6, which extends the number of addressable devices to 2^128 (a very big number).

However, a remaining issue is how to manage said pool of addresses. These days the number of required devices has increased dramatically, notably with the arrival of Voice over IP (VoIP) handsets, which are replacing traditional, analogue telephones. From an address management perspective, the Domain Name Service (DNS) protocol is the standard for allocating specific address ranges to specific subnets, but some organisations are ending up with a large number of DNS servers, which themselves have to be managed. The original protocols were never conceived to manage the address allocation, deallocation and reallocation process on such a scale - and don’t facilitate the cataloguing of what address belongs to which department (Microsoft Excel is a more used, but still inadequate tool). Theoretically, organisations could of course allocate addresses statically, once and for all - but all it takes is an office move (requiring a number of devices to move from one subnet to another) and all hell breaks loose.

So - IP addresses need managing, and existing mechanisms aren’t cutting the mustard. This is the breach into which are stepping organisations like BlueCat Networks (who I have spoken to), and Alcatel-Lucent, BT-DiamondIP and Crypton Computers (who I haven’t - but these chaps have) - essentially delivering management tools and distribution mechanisms that really can cope with such huge numbers of addresses and offer quite some respite to those managing the IP network. It is notable that, when I asked BlueCat whether I could speak to a customer, they jumped at the chance and before long I was speaking with Investor AB, a Swedish organisation.

On the call I learned little that was unexpected: yes, the problem existed and was real; yes, it was for the reasons I understood; and yes, the deployment of BlueCat’s address management solution had been a great help. What’s there not to like, I said as we finished the call. And yet, I was left feeling a little puzzled at the end of the call. Notably, whether by agreeing with the problem and solution, I was in some way implicated in yet another attempt to foist unnecessary technology on an unsuspecting public. Particularly in this case - where the solution itself resolves an indisputably technical problem.

But however we might like things to look, the problem does exist and so does the solution. Just as the invention of carpets required the subsequent creation of carpet cleaners, so can today’s overstretched networks benefit from address management. This won’t be a panacea for all ills - it never is, and it should go without saying that technology can never be more than a crutch to poor operational processes or bad managers. I could add a string of caveats at this point but I won’t - rather, I will acknowledge the fact that most network managers do have their heads screwed on pretty well, and defer to their ability to decide whether this would be an appropriate technology for them.

As part of the briefing cycle for Aruba’s announced acquisition of Airwave Wireless, I had a very interesting conversation with Roger Hockaday, EMEA marketing director for Aruba. In part it was about the announcement, but it quickly turned (as these things do) to a discussion of the wider picture of wireless, and indeed wired network management. “Discussing the wider picture” can sometimes mean, for analysts, expressing poorly veiled disdain at the fact that a vendor has not taken things far enough - a bit like when the triumphant person comes into the room to demonstrate, after 6 months of hard graft, that he can now juggle with 3 balls, only to be shot down by some smart alec who says, “yes, but to do it properly, you’ll need to jugggle with 4.” Not that I ever would of course, and certainly not with this - because the challenge is not one that can be resolved in one go.

In this particular case, it is more like juggling with a ping pong ball, a meat hook and a chainsaw. Wireless networking protocols remain all over the place as the bubble-headed wonks of 802.11 land continue to squeeze yet more bandwidth, and indeed distance out of some highly unreliable physics; on top of the base protocols are build a number of security and management capabilities, which are supposed to be compatible, but sometimes don’t quite manage to integrate. While all the attention has been (laudably) on driving up bandwidth and resolving compatibility issues, the black hole remains centralised management, particularly for legacy products that were not built for remote configuration and monitoring.

Aruba’s acquisition signifies both the need to centrally manage the variety of wireless switches that are out there, and the resolve to do something about it. Having not researched this specifically I don’t know if this is down to latent demand or direct customer pressure, but it makes sense that organisations which have rolled out wireless access points on a more ad-hoc basis in the past, are now seeking to integrate their operation with the rest of their network management activities. And incidentally, it may be that Cisco have been able to offer a more integrated approach for a while - but it is a rare organisation that is a wall to wall Cisco shop, so the same issue arises.

While WLAN remote management might be able to bring wireless management into the same room as wired networks, this is still a step away from bringing both onto the same console (and I don’t mean through screen scraping, or “sure, we can do SNMP traps” type conversations). It is true that wireless network configuration and monitoring has different drivers to the wired equivalent: one will largely be to support roaming end-point devices running a limited set of functions, while the other needs to consider the entire network architecture; there will be different (e.g. security) policies applied to each, etcetera. However, more integrated management tools lead to more efficient (and therefore, less costly) management.

We should therefore see this acquisition, and the impetus behind it, as a flag along the road - an indication of where we are in this work in progress. From the end-user perspective, where (as we have seen in recent studies) people care little about how they are getting their bits, just that they can get them, networks and their management tools should be able to see not just wired and switched wireless, but also “mobile” protocols such as HSDPA as part of the same, managed network architecture - particulalrly when things like Unified Communications really start to tip, and picocells extend such protocols into the office. Now that, if and when it comes, will be juggling.

… was how the Oxford Dictionary of Computing defined a system administrator. Or at least it did in the second-hand copy of the first edition, I used to own in my university days, 20 years ago (ouch). While I loved the self-effacing humour, only today did I discover it was also a hat-tip to Dr Johnson, whose dictionary, first published in 1755, defined a lexicographer as:

“A writer of dictionaries; a harmless drudge, that busies himself in tracing the original, and signification of words.”

In these hyperbolic days of IT, perhaps it is right to wonder whether one day the role of the administrator can once more be distilled to that of a lexicographer, be it no less useful or rewarding a position nonetheless.