Network and Telecom Strategies Blog

Vendors wagging the customer

To quote Mel Brooks as Louis XIV in “History of the World, Pt 1”: “You do It, I do It, we all do It.” In this case, process is the “it” that needs to be clearly defined before selecting tools to enable efficiency and productivity in an operations group. More often than not, groups look at software to address a technical and business need before they know how they’ll use it, the problem they are trying to address, and how the tool will blend with current processes and existing software.

Process

One of my undergrad majors was marketing. The key concept I took away from that coursework: someday you’ll buy something, not because you need it but because of marketing. Do we all need the latest and greatest gizmo we see or hear about? Of course not, yet many will buy it because of great marketing. I almost applied for a Capital One credit card because those marauding Vikings tried to convince me they might be in my wallet, yet Carl Malden’s convincing dialogue remains the one I “don’t leave home without”.

Vendors, good and bad, have a unique way of marketing and selling technology products based on customer relationships, reputation, support by industry experts, and/or my favorite: FUD – fear, uncertainly, doubt; what’s in your wallet? The problem is, until a group has succinctly spelled out the process they’ll follow, selecting a tool first is the vendor wagging the customer.

I can’t stress the importance of understanding your processes, and how they affect the organizations and dependencies around you. In the technology world, we are wrapped around software, servers, laptops, firewalls, switches, routers, load balancers, wireless devices, Blackberries, multiple operating systems, and a host of service level agreements just to name a few. Software tools are the stuff that keeps us running on the bleeding edge of success and failure.

Twenty years ago, a software failure wasn’t the end of the world. Today, with tight integration of systems and processes, OSS (operational support systems) becomes even more critical to an operations group than ever.

Know the process, be the process. Once you are one with your process, start the tool evaluation process.

The Wheel

The wheel wasn’t created looking for a problem to solve. It was discovered that the wheel addressed the process prehistoric man used for dragging their important stuff around. Not real technical; simple; short users’ guide; no government warnings like “CAUTION: KEEP FEET FROM UNDER WHEEL. COULD CAUSE LOSS OF FOOT AND LIFE AS WE DON’T KNOW ABOUT PENACILLIN OR MODERN MEDICINE.” The wheel complimented the process people used for moving items and they didn’t become slaves trying to maintain it.

If an application doesn’t compliment the business and technical requirements of the processes developed by an organization, it becomes:

1) a burden,

2) wasted capital, and

3) a labor vampire if the organization tries to adapt itself to it.

Careful examination and discovery of how well an application functions and enhances productivity is critical to selection. “So easy, even a caveman can use it” should be the ground rules for tool selection.

Creating a Wolf Trap performance

Selecting software is a balancing act between cost, functionality, compatibility, complexity and requirements. Until you know the process you are trying to address, don’t rush to make a selection. It could very well end up being a square wheel.

OSS - why you need it

Posted by Chuck Bessant

Air travel has come a long ways since Wilber and Orville gave it a go at Kitty Hawk, NC. As air travel matured, planes became more sophisticated with the assistance of avionics, or electronics designed for aviation. Humans are still required (even for pilotless planes, someone is controlling them from a remote center) to fly aircraft. The more that is expected out of an aircraft’s mission, the more sophisticated the avionics. In addition, avionics allows for less flight crew members resulting in lower labor costs. Imagine trying to safely fly a Boeing 777 with no advanced avionics.

Large enterprise networks are complex. They span hundreds or even thousands of locations over a variety of vendor equipment and operating software, service provider connections, private connections, fiber, copper, microwave, transport a variety of protocols, require different service level requirements per application and/or customer, transport timing sensitive data, must block malware and nefarious attacks, and be reachable by thousands of internal (employees) and potentially millions of external (customers and partners) users. They are depended on for reliability and performance to carry voice, video and data each with unique performance characteristics. As each user conducts a transaction to view email, place a VoIP call, move an MRI to a radiologist in Australia for evaluation or cerf the web to order the latest footwear from Zappos.com, an expectation is set that each transaction, regardless of type, will be completed properly and efficiently. The expectations and reliability of data networks today is that of a POTS (plain old telephone system): you always have dial-tone and the call is always completed.

Since starting back in the early 1980s with networking at Digital Equipment Corp (DEC), I've always viewed management of networks as a critical component to a successful environment. Since the days of thick-wire Ethernet with brick-sized transceivers and X.25 circuits, the complexity and dependency we have placed on networks to conduct day-to-day activities has increased exponentially to the point without proper management, business would collapse under excessive labor costs associated with monitoring, assuming people can perform as well as computers. Service level agreement (SLA) penalties can also kick in (kick you?) when SLAs are breached.

OSS (Operational Support System) was originally a collection of systems architected and designed to support large, complex networks for telcos and ISPs. It is impossible to manage these infrastructures using similar "seat-of-your-pants" technology Orville and Wilber depended on for flight, albeit a short and safe flight.

OSS follows a basic fault, capacity, accounting, performance and security (FCAPS) model. Pretty much everything you need to know about managing a network but were afraid to ask. Riddle me this: Why is it that enterprises look at OSS as "it's a telco thing" and feel they don't need or want it? I've heard this description of OSS many times, and to be truthfully I find it annoying. Excellence should always be sought, even if it is a “telco thing”.

In many ways, enterprise networks have become more complex than many ISPs with the use of WAN optimization, compression, encryption, intrusion detection systems (IDS), VoIP, VPNs, regulatory requirements, HSPDs (Homeland Security Presidential Directives), multicast, caching, malware detection and efficient use of capital equipment to contain cost just to name a few.

Call it network management, Frick-and-Frack or whatever the kewl expression du jour is, it should still cover FCAPS - a simple and elegant model that works and does what people expect. How it is architected, designed and implemented is for another discussion. Each enterprise will have different technical and business requirements, yet each need to cover FCAPS. The magic is in how it is planned, architected, designed, implemented and maintained.

Network and application performance is a direct reflection of the perception of quality the enterprise brings to all users. Without the proper tools, systems and processes in place, service, quality, security, and performance can't be monitored, managed and tuned.

Who's on the network? How close is capacity saturation, or before users slam into a mountain they didn't see on the horizon? Who’s using the resources? Has unauthorized accessed been gained? Have systems been compromised? Outage isolation and problem determination - things break and these need to be found and fixed quickly.

NOCs (Network Operations Centers) are staffed by support engineers that are (should be) more sophisticated than the Vikings in those great Capital "What's in your wallet?" One commercials. To properly do their job, engineers need the right processes, policies and tools, in that order, already in place to help avert a disaster, and to deal with disasters when they occur.

Tools are used to facilitate the processes and policies that were developed based on business requirements. No one tool fits all. Careful selection and integration must be made after close evaluation to ensure capital investment is not wasted. A mix of tools from a variety of vendors will be required.

The sophistication of OSS deployment will vary based on business and technical requirements that are appropriate for the required and offered services. Good analysis will help determine the level of sophistication required to properly and cost-effectively manage services offered by an enterprise. There is no silver bullet or single vendor approach to OSS. It can be complicated yet eloquent and actually save the business money. Less staff can support more, yet not be a burden on the support and design engineers - not too shabby, and shareholders will appreciate it too.

You can call it network management or you can call it operations, but don't call it unnecessary. Try to think about OSS as not just a “telco thing”. Perform a gap assessment using FCAPS as a guiding light, and see if your business can has what it takes to survive growth, an outage or disaster.

OSS most certainly applies to enterprises, and if done properly will enhance the technical, management and cost effectiveness of the business.

Chuck