Before you can develop a TMN system you need to decide upon a
development platform. There are several development platforms and
environments out there. Here are some things to look at when making
your decision.
Staff
Before you can
attack any of the issues related to TMN development you need
to have a staff that has TMN development experience. If you
can't find people like that, and there are not that many, then
try to find someone with OSI network management development
backgrounds preferably with CMIP and X/Open (XOM/XMP) experience.
If you can't find people with CMIP then SNMP is the next level
down. But you must understand that GDMO objects are more complicated
than SNMP. And CMIP development is just as equally complicated.
A good alternative is to take some courses. Various vendors
offer courses that use their particular software/hardware.
In some cases, the training will be free of charge and one-on-one.
The less experience your staff has with any of the concepts
(GDMO, CMIP, TMN, OSI, etc) the more time you need to allocate
to your project. Without a mentor (ie; someone that knows
these things) double your estimates. It is really that time
consuming to learn these things. And a simple mistake can
take days to debug and figure out.
Standards Compliance
The first criteria of selecting a platform is to determine
whether the development platform is standard compliant.
This can be difficult with all the marketing pitches you
are getting. Here are some points to examine.
Building metadata.
How does the platform incorporate the GDMO objects
into its metadata? It is important to ensure that the
top level documents are the X/Open documents instead
of CMIP-1. By using X/Open you will have cross platform
code level compatibility with other X/Open development
environments.
MIB compilers
This is a critical area of compliance. You will find
that different MIB compilers will react to the same
document in radically different ways. If at all possible,
test the GDMO documents you want to use in your development
with the MIB compiler you want to use BEFORE you purchase
it.
Cross Platform
Hypothesis:
if you stick to development environments following the X/Open
standards then you should have few, if any, problems developing
code that will work across different platforms.
Reality: much like the fallacy of Java... The first pitfall
here is that one vendor is compliant to draft 4 and another
to draft 5 and obviously the two won't work exactly the same
way.
Most vendors have their code only on one particular hardware
platform (though that is slowly changing). Once you buy into
a system like that you are stuck with that vendor.
Development Features
One thing the developers will be looking at is the different
features of the development environment. Things to look
for here are:
Visual oriented development.
Some platforms provide a very visual front end to the
developer. This will then in turn churn out C or C++
code. I have used this approached and found it extremely
efficient.
Handles complexities of routine X/Open programming.
From the agent side of the development I can say that
almost all agents are the same. There are development
kits out there that can help you have an agent running
in almost no time at all because they already handle
90% of the work.
On the managing side you are looking for easy to use
interfaces that hide the complexity of XOM/XMP programming.
You still need to know the basics of XOM using these
interfaces but not in as much detail that one normally
would.
One caveat here is that the toolkit can generate such
large applications that the debugger can't load the
application! Make sure this doesn't happen to you.
Along the same lines as the previous point is having
an object oriented interface for the manager. Some vendors
have tools which will take GDMO and produce C++ classes
to manipulate these objects. This work is being spearheaded
by OSF in the CMIS High Level API Working Group.
Interactive MIB Browser.
One of the biggest needs for the developer is testing
an agent and MIB Browsers are the only way to do it
unless he wants to develop his own test applications.
Conversely, you need to be able to generate test agents
quickly.
This way the managing applications are not waiting
around for the agent development to be completed before
they can start testing.
Cross-talk
In this day
and age of standards you would not think this to be a problem.
But getting different NM platforms to talk to each other can
be in some cases impossible.
I was involved in the evaluation of NM platforms for a particular
development environment. The first order of business was to
prove that their environments could talk to an agent that
I had already developed and was up and running. I had also
ensured that the agent could be talked to by at least one
other hardware platform than the one it was developed on.
We had each of the vendors bring their platforms into our
environment and talk to this agent. Not one of the other platforms
was able to talk with this agent. We were given all sorts
of excuses why their particular CMIP implementation was incompatible
with the platform my agent was running on. Each vendor was
given ample time and information ahead of the demonstration
to get things working. This was an eye-opener!
Now this is not a condemnation of any of the vendors, it is
just a picture of how things are. Many network managers are
trying to achieve vendor independence in their environments.
This is a difficult task to say the least.
Moral of this story? Do as much testing on this issue if you
are striving for this.
Re-evaluation period
Unlike most
development you need to add in periodic re-evaluation of the
development platform into your schedules.
One reast is that not all technical/standard issues will arise
immediately. In fact, some problems/limitations can stay hidden
for months. Plan into your schedule to possibly having to
switch platforms mid-stream. You might end up finding that
the particular vendor you have settled on has a problem/limitation
which can not be corrected without seriously jeopardizing
your schedules.
I've seen this exact scenario happen before.
Front End
Almost all vendors
provide some kind of a front end interface to do basic network
management functions. These interfaces are generally very
generic and therefore provide minimal functionality. You will
probably want to design your own network management applications.
Developing your front end management applications needs to
address your particular business case.
Integrated Distributed Objects
Distributed
objects are becoming a hot new buzz word. Some development
environments are starting to provide built in distributed
objects for the management side of things. Look for CORBA
support.
Also, look at the speed and scaleability of the CORBA implementation
you plan to use. I saw a project go belly up because the CORBA
implementation selected worked fine with a small number of
objects, but once several hundred thousand objects were instantiated,
the whole thing crawled to halt.
Vendor Development Support
What kind of
support will you get from the vendor after you have bought
into their vision? This milage varies. I have had excellent
free support from some vendors with direct email access to
their platform developers. On the other hand, I have had absolutely
abysmal 'expensive' paid support with access to only a go
between to the vendor's developers.
This is an important issue especially if you are using a platform
no one on the staff has experience with. Many problems do
end up being trivial user errors but getting access to someone
that recognizes the problem to help solve it is essential.
Otherwise you are spinning your wheels waiting and losing
valuable development time in the interim.
