Application Backlog? Call A Plumber

A Day Late and a Byte Short The answer of how to best address today's application-level protocols, like directory services, lies not in which brand-name horse you should back, but in who should be working on the problem in the first place. Network architects continue to concentrate on better, faster and cheaper ways to sling packets, while everything else is simply payload. Because nature and the market both abhor a vacuum, the venture capitalists have stepped in. As a result, the problem of directory services has been abdicated to vendors without a great deal of broadly based active user involvement. E-commerce solutions are being developed by companies where previous technical challenges involved paperwork reduction by way of image processing. It's like having a spreadsheet macro programmer design an OLTP (online transaction processing) server.

Forget about serendipity. In the world of network infrastructures, it's simply not a just-in-time universe. Assertions about the computer industry's rapid pace of change simply don't hold water (and the exact opposite is actually true): The process of change is painfully slow and costs too much. Want evidence? Take a look at Kerberos. It was originally described back in 1988 as part of project Athena and it's just now rolling into NT. Enhanced directory services with improved functionality will take even longer. Paradoxically, Cisco and other companies are only now looking at directory services with intent.

So, who should be responsible for e-commerce and directory services? The answer really depends whether you think an application's effects are apparent in six months or six years. For example, there's little doubt competing directory services products have a positive impact today. But who will support them in six years? This phenomenon of lag time between application rollout and its devolution into an issue for network support has tangible results. Today many corporations are addressing two-year-old business problems with five-year-old technology while supporting a crumbling infrastructure that was based on decisions made 10 years ago. It should be patently obvious: Addressing application issues from the network out can reduce time to market now and maintenance tomorrow.

It 's impossible to model the interactions between producers and consumers of technology, between today's technology adoption curve and tomorrow's support burden. However, networking engineers within organizations can add an incredible amount of value if they remain involved with all the players. It's not about joining some committee searching for the grand unified-string theory to solve every problem. It's about developing a China policy--if you aren't engaged on an ongoing basis, you cannot influence the outcome.

Directory services and e-commerce are begging for attention. Either or both of these disciplines show real signs of creating fragmented solutions that we'll need to maintain and which will, in turn, divert resources away from the next generation's business problems.

The current state of directory services is simply not good enough. You cannot shoulder the burden of supporting thousands of users and hundreds of servers without them. There are no uniform schemes; replication between heterogeneous servers doesn't work; and client access across different servers only sort of works. All this comes to a head at a time when the corporate IT staff is asked to support more users with fewer full-time staff members.

E-commerce doesn't fare much better. Exactly how long have we heard about SET (Secure Electronic Transactions)? News flash: MasterCard declared that SET is out of beta and it's ready to start implementing 1.0. This is hardly the record-breaking speed necessary for supporting the "networked economy." It sounds to me much more like the dragging of feet to maintain market share--in other words, don't hold your breath for much of anything.

Redirect Talent for the Common Good A sword of Damocles hangs over the future of the Internet. What grew out of simplicity and elegance has now morphed into mind-numbing complexities. Network engineers are ahead of the pack by nature--having perceptive insights into what works and what's vapor. When you consider that against the predicted complexities of networked applications, you can see why network engineers' involvement in application problems like directory services and e-commerce is so necessary. The best way to start, I think, is with a specific problem like facilitating your shop's adoption of X.509 certificates and go from there.

Out of necessity, network engineering talent within the organization has been directed at the problem of pushing bits around the network. That network will soon be outsourced to a service provider (that is if it isn't already outsourced). Therefore, the organization could derive the greatest benefit by slowly redirecting the internal skill sets consumed with managing routers and bandwidth to higher-level problems.

My best advice to a company concerned with minimizing down-the-road costs and doing it right the first time is to give its network group the power to make decisions about e-commerce and directory services technologies, and let its Web group concentrate on vertical applications, not applications that make u p the infrastructure. Also, send network component vendors and backbone providers the message that you care about application-level services and you expect your vendors to embrace them and add value as well.

Brian Walsh is the founder of bwalsh.com, Portland, Ore., a networking and communications consulting firm specializing in Internet and client/server product strategies, development and testing. He can be reached at www.bwalsh.com.


Other Columnists
In The Middle
By Nick Gall
On The Edge
By Art Wittmann

Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers