Connectivity
Lets first look at the implications on connectivity: at present, the Internet is defined, for most users, by the needs and demands of the World Wide Web. This is the space they see and work with on a
Lets first look at the implications on connectivity: at present, the Internet is defined, for most users, by the needs and demands of the World Wide Web. This is the space they see and work with on a regular basis. A few enthusiasts use other technologies like IRC and ICQ and, of course, theres a huge community who connect via AOL. But the Web is the predominant vehicle for Internet content.
Most Internet content is targeted at the 56K modem marketplace. There are pockets of high bandwidth large photographic sites, streaming news video, scientific and university departments and so forth but, despite there being a large installed base of cable modems in the US, the majority of usage is still aimed at 56K modem users.
So, how quickly will the Internet split into two, with a traditional slow-speed world and a new high-speed world? Although everything points to this happening rapidly, theres no real sign of it yet. Indeed, if you look at the sort of business-to-business transactions that are happening today, theres little thats really high volume on data. Obviously Im excluding custom solutions, like high-speed information feeds for the financial marketplaces and so forth, and taking a broader business view. You might even conclude that the rise of XML and the B2B processes supported by technologies like Microsofts BizTalk will generate a large increase in traffic. This is true, but the traffic will be finely grained and probably not hugely time-sensitive.
Theres a fundamental reason for this happening. Connectivity is still expensive if you want lots of bandwidth, but this isnt the real killer. The big problem is the reliability of the connection. If a B2B solution is to be built whereby a portion of my business process is supplied by your company and youre at some distance from me over the Internet, then I need to ensure that I can keep working when theres a fault on the line or some other interruption to connectivity.
If youre used to using a modem, then it is, by definition, an interrupted and interruptible solution. Once you move to a 24/7 solution like DSL or a professional feed such as Kilostream/ Megastream, you find that the connection is still bursty and often disrupted. This is the nature of the beast the Internet is an unstable cloud of interconnections. Sometimes the thunderstorms in the clouds are bad, such as a major routing flap at an interconnect point. Other times the cloud splits, when international connectivity fails due to undersea cable failures. Then there are the times when a helpful telco engineer chops your phone line or fibre into several pieces.
All of these things conspire against a direct-connected B2B working space, because you cant rely on the other party being present. I accept that the frameworks of .NET allow for interruption of connection and for this to be managed in a grown-up fashion. This isnt the sort of interruption Im talking about Im referring to the downtimes measured in tens of minutes or even hours.
This problem isnt new in the connected business world. We have SLAs (Service Level Agreements) that say that your ISP will provide a 99.9% uptime on the connection and that theres a sliding set of refunds to be applied if the quality drops below certain thresholds. Even if you get 25% of the monthly fee back for a 90% SLA uptime, can you afford to have ten per cent downtime on your business? That might represent three whole working days or 96 hours of Internet time in one trading month.
Now lets take a .NET-style scenario where your line-of-business application uses technology provided, in real-time, from vendor B. This might be a complex stock-control reordering engine, for example. Lets assume that vendor B didnt write all of its technology, but has licensed two smaller engines from vendors C and D.
As contracts go, my business arrangement and subsequent SLA is with vendor B. But vendor B will have business arrangements with vendors C and D, and therefore SLAs. The SLA doesnt just cover the availability of vendor Bs solution Ill have a separate SLA with my ISP providing the pipe over which my traffic will flow. Lets imagine that something goes wrong and my line-of-business application doesnt work. Whos going to be liable? How are we going to measure the effectiveness and efficiency of each of these components, all balancing on a whirlpool of complex SLAs and interacting subsystems? As the financial director of a large company said to me recently, Who do we sue? Its a sobering thought.
The reality is that there will be relatively simple interconnection points and low expectations for the foreseeable future. Only a fool would build such an interrelated solution as the one I propose above without ensuring theres bomb-proof connectivity and SLAs that really bite when something goes wrong. If Im losing money due to someone elses downtime, I need to be able to sue or get adequate recompense.
As a result, I expect to see .NET solutions clustering around large points of connectivity, almost certainly hosted in managed server room spaces. The developers will sit in their own working offices, connected to the Internet via a single- or dual-diverse solution, and will upload their solution to the managed server farm for operational use.
The need for managed networking will occur within an intranet solution too. For some years, theres been the technology for QoS (Quality-of-Service) management on a network. In other words, its possible to say Fred is doing video streaming for an important teleconference, so make sure his packets get through and Mary is sending an email, so is much less bandwidth-sensitive. Hardware solutions are available from the major switch manufacturers, and theres even support inside Windows 2000 and Active Directory. However, few companies have implemented this sort of technology because its an additional complexity. When we eventually have geographically diverse multi-tier applications, the need for QoS will become more prevalent.
This article appeared in the May, 2002 issue of PC Authority.
Thoughts on this article? Add a comment below.
Be the first to comment on this article.