Why Ethernet OAM Software?

The question we used to hear about Ethernet OAM was, "Do we really need it?" We are past that now. Anyone that has done their due diligence knows that Ethernet OAM is table stakes to sell Ethernet technology into all but very traditional LAN applications. Even there, Ethernet OAM gives a product offering a distinct advantage. From a prospect's perspective, if they don't know that they don't need it, they need it.

So, now the question is "How do we get Ethernet OAM into our product?" There are several paths, but the first choice is to find an off-the-shelf Ethernet OAM software package. This can be developed in-house and was by the very first equipment manufacturers to offer it. They had no choice since Ethernet OAM software was not available as IP. Now, it is. Now, you can add this critical capability without devoting major internal resources to research, coding, test and integration to make your product standards compliant.

Some people will say that they can do this in-house. That is very true. The question is whether or not that is a good business decision. To evaluate whether to license Ethernet OAM software or develop it internally, three parameters need to be evaluated; these are cost, quality and schedule. Let's look at these in turn.

Will licensing software reduce the development cost let alone the total cost of ownership? Just by the nature of licensed software, the cost to license and integrate is almost always less than the internal development alternative. In many cases it is much less. Lifetime product cost is dependent on the testing prior to delivery, level of support available from the software vendor, the form of code delivery (source or object), the documentation of the code for self-support, and the general robustness of the software. Many of these things can be either directly observed or evidence obtained from knowledgeable references.

Will licensing software increase or decrease my expected quality? If licensing will not allow you to reach commercial quality, don't do it. On the other hand, if internal development introduces this risk, that is not an option. It has been said that cost and schedule are performance issues; quality is an employment issue. Here again, the reputation of the software firm and their customers' experiences can give you a very reliable measure of what you can expect. All else being equal, including well tested, off the shelf software in your project should increase your product's quality. Scratch development and the ability to test to catch real world as well as standards compliant operation puts all the risk in front of you. Fully tested and field tested software obviously increases the confidence level.

Does licensing code or developing it in-house get me to market faster? If the off the shelf software is worth buying, it almost has to contribute to getting your project released sooner. And, many people believe that you can never make up what you lose in release delays. There are several ways licensed code assists in getting a faster product release. First, whatever development line the code is on will become shorter. The code is done and integration with some verification testing is all there is left to do. That timeline shrinks and the probability that it will be met increases because it (should) come to you completed, tested, and supported by experienced developers. A second way it gets you to market faster is by making more of your resources available for the rest of the project. These freed up resources can be applied to getting to First Customer Ship (FCS) faster or can be applied to releasing a more feature rich product in less time than otherwise.

Are there any downsides? There are a few potential concerns worth talking about. The first is that the internal team will not have the expertise they would have otherwise. The importance of this varies. If the software is in an area the firm intends to add product differentiation, losing the initial experience might be significant. On the other hand, if the software is filling in a standards based requirement, this is less an issue. If it's a standard requirement that everyone has to meet, you meeting it will not differentiate your product. Not meeting it will differentiate it and internal development is more likely to not meet the standards out of the chute. Even improving a standards compliant piece of functionality can break it by definition.

Ethernet OAM not only requires standards compliance, but also demands interoperability with other equipment in the network. NComm's Ethernet OAM software delivers it all. It improves your cost, quality and schedule. It increases your projects expected value. The bottom line is how much is it worth to be standards compliant at FCS? And, how much would it cost to fail? The answers are obvious and so is the decision to talk to NComm to see how our software might meet your project's needs.

For further general evaluation of Ethernet OAM software requirements, visit our Ethernet OAM resources page.