 |
Welcome and thank you
for subscribing to the EMS Energizer!
Element Management System (EMS)... aha it
conjures up so many emotions in the minds of Equipment
Vendors. Some of it of course is positive! Our
experience however has been, for many Equipment Vendors,
EMS is an after thought...a necessary evil... a check
box item. As a company that is focused on providing EMS
solutions we beg to differ.
We believe EMS is
like a dashboard of a car, while it will not make the
car run, you need a good dashboard to understand what is
going on with the engine and interact with the car. This
brings to my mind the following anecdote. Recently my
wife and I went shopping for a car; based on price and
other factors the choice was narrowed down to two car
models. As a car enthusiast, I looked at the engine,
studied the performance characteristics etc and thought
that "car A" was a winner by a small margin. However my
wife liked the dashboard of "car B" since she felt that
it was more current. I am sure it is not difficult for
you to guess which car is parked in our driveway!
Of course every Equipment Vendors will be quick
to point out that their device is more than a commodity
item and is not as simple as a car. While we agree with
that and clearly understand that the EMS alone will not
win you the business, however we believe that it can
give you the edge in a highly competitive and
commoditized world. Finally speaking of "edge", did you
know that in the recently concluded winter Olympics, the
gold medallist and the silver medallist in the men's
50km cross country ski race were separated by less than
one second. In a race that lasted over 2 hours, just one
second made the difference!
EMS Energizer is a
quarterly publication that is intended to share our
knowledge and experiences with our readers to help them
learn more about Element Management Systems and to help
them build a better EMS. We hope that it will also give
our readers an opportunity to share their thoughts,
ideas and experiences with their peers as well and look
forward to your participation.
Dhyan Infotech
Inc is a software and services company that helps
Equipment Vendor differentiate themselves and their
products in the market place. Dhyan's NMS/EMS product,
DNMS (Dhyan Network Management System) is a component
based Element Management System that has been widely
deployed by Dhyan's customers at many Service Providers
both small and large.
If you have questions on
EMS or related topic that you would like to get answered
or would like to write a guest column in this newsletter
please send an email to ems.energizer@dhyanit.com
|
 |
What is an Element
Management System?
As Dwight Eisenhower once
said, "Put first things first"; let us get this
newsletter started by first defining EMS. EMS consists
of systems and applications that are concerned with
managing network elements (NE) on the network element
management layer (NEL) of the Telecommunication
Management Network model (TMN) shown below.
As recommended by ITU-T, the
Element Management System's key functionality is divided
into five key areas - Fault, Configuration, Accounting,
Performance and Security (FCAPS). Portions of each of
the FCAPS functionality fit into the TMN models. On the
northbound the EMS interfaces to Network Management
Systems and or Service Management Systems depending on
the deployment scenario. Southbound the EMS talks to the
devices.
The following grid exhibits a subset
of functionality prescribed by ITU-T and Telcordia for
the key functional areas. |
| Fault |
Configuration |
Accounting |
Performance |
Security |
| Alarm
handling |
Auto
Discovery |
Service
Usage |
Performance monitoring |
Prevention |
| Alarm
correlation |
Network
provisioning |
Service
level agreements |
Report
generation |
Authentication |
| Alarm
forwarding |
Auto
back up and recovery |
Billing |
Data
collection and correlation |
System
Access Control |
| Filtering and Filter management |
Service
Activation |
|
|
Detection |
| Log
management |
Software
upgrade to devices |
|
|
Intrusion recovery |
| Threshold based reporting |
Inventory management |
|
|
Containment and
Recovery | |
| In the forthcoming
issues of the Energizer we will look at each of the
modules in more detail. In the mean time if you have any
questions in those modules feel free to email it to ems.energizer@dhyanit.com
|
 |
Once Equipment Vendors
decide to develop an EMS for their device, they would
like to get it developed as quickly as possible, since
most often they start thinking about an EMS when they
have to respond to customer RFP's or when they are in
"trials" with their customers. Naturally the burning
question on every Equipment Vendors mind is how do we
get the EMS developed quickly and cost effectively.
Following three options are available to developing an
EMS. (i) Custom development of EMS (ii) using frameworks
to develop an EMS and (iii) using components to develop
an EMS.
In the first approach a team of 10
people develop an EMS from scratch and typically the
development effort lasts for a period of a year [to
develop FCAPS (Fault, Configuration, Accounting,
Performance and Security) and Topology modules]. The
development of EMS could be done in house by the
Equipment Vendor or outsourced to another company. The
advantage of this approach is that since the application
is built from scratch it could be highly customized and
made to represent the device very well. The drawbacks
are obviously cost and time.
The second approach
is to buy frameworks that are readily available in the
market, customize it so that it meets the Equipment
Vendor's needs. The frameworks that are available in the
market typically have a preset architecture, which
cannot be altered. They provide API's using which an
additional layer of application could be developed to
customize the framework to meet individual requirements.
The benefit of this approach is that the EMS can be
developed quickly. The drawbacks of this approach are
that the ability to build a custom application is
greatly sacrificed for speed of development. Also since
the framework is rigid most of the EMS's developed using
this approach tends to have the same look and feel.
Finally a key drawback with this approach is that
additional functionality cannot be added easily.
The third approach is the components based
approach. In this case the EMS is architected from
scratch but developed using pre-built components. For
example, if a fault module needs to be developed then
first the architecture of the fault module is defined
based on the Equipment Vendor's requirements and then
the module is developed quickly by using pre-built fault
components such as log management, alarm correlation
etc. The advantage of this approach is that it combines
the benefits of the custom approach and framework
approach. Since the architecture is not pre-defined it
can be designed to suit individual requirements. At the
same time since the development is done using pre-built
components, the development time is much shorter than
custom development. Another key factor is that with this
approach additional functionality can be added easily.
Below is a graph that compares the three
approaches to EMS development.
As you can see with the custom approach
there is no pre-built functionality that exists when the
development process is started. The addition of
functionality varies linearly with time and the target
functionality is achieved in time T1. With the
components based approach, since the development work is
done using pre-built components, some amount of
functionality is available at the start of development
process and the addition of more functionality varies
linearly and the same target functionality is achieved
in time T2, with T2 being less than T1. With the
framework approach, since pre-built functionality is
already integrated into a framework it is more
functional to start with. However since it is rigid,
more functionality cannot be added easily and hence you
see the flattening of the curve thereby taking a longer
time to achieve the target functionality.
If we
make a reasonable assumption that the project cost is
directly proportional to the time it takes to deliver
the project (everything else remaining the same), then
it can be easily seen that the component based approach
in addition to being flexible, delivers the EMS
application faster and is more cost effective.
| |
|
| Dhyan Trade Show Participation
|
 |
Network and
Interop
April 30th to May 5th, 2006
Convention
Center, Las Vegas |
|
Globalcomm
June 4th to 8th,
2006
McCormack Convention Center,
Chicago |
| If you are interested in meeting
with Dhyan representatives at the show please send email
to ems.energizer@dhyanit.com |
| Q |
As a device manufacturer
we are thinking of having an EMS |
for a
device. Please let me know when is an appropriate time
to start the EMS development?
|
| A |
We are glad that you have chosen to
have an element |
| management system application for you device...it
warms our heart! The time to get started on an EMS
depends on several factors while we have listed the
important ones, there are many more to consider
depending on your particular situation.
(i) Device maturity
(ii)
Customer/Market place requirements
(iii) Financial
situation
(iv) Skill set availability and
prioritization As you would have noticed, of the
four key factors listed above, three of them (device
maturity, financial situation, skill set availability)
are internal to the company while customer/market place
requirement is external to the company and depends to a
very great extent on the market place that you are
participating. If you want to be truly a market driven
company you will put item (ii) as the most important
factor which we will discuss as the last factor.
As a first set step let us look at the internal
factors of the company over which the company presumably
has some control. Based on our experience, in general we
recommend that the customer's start their EMS
development when the device development is almost
completed and the device is stable. This allows the MIB
definition of the device to be complete and the MIBS are
also stable – a key requirement for a successful and
stable EMS.
The second key factor is the current
financial situation, since most of the money during the
device development phase are earmarked to developing the
device (and rightfully so), there may not be enough
funds to be allocated for the development of an EMS.
This would mean that the development of a full-fledged
EMS might have to be postponed for a while till
additional funds are obtained. In the mean time the
device has to do with a CLI or kraft interface.
The third key factor is the skill availability
and prioritization. Since the EMS has a different set of
drivers from your device, the skills required to do EMS
development are different that from your device. If you
were to do the EMS development in-house, then the EMS
team needs to be staffed up and managed. There is a
lead-time involved in putting together a good EMS team
which should be taken into account. Managing another
team is a load on the engineering management team that
needs to be prioritized as well.
Lastly the most
important of all the factors is the customer/market
place requirement. From our experience we've noticed
that some markets (especially when selling to larger
service providers and carriers) and some products (high
end devices and devices that need to be deployed in
volume) require an EMS when the device is introduced to
the market. Since a full-fledged EMS development takes
about 9 to 12 months, it is advisable to understand your
market requirements and start the EMS development about
a year in advance before you enter the market in a big
way.
|
 It is almost a year since I
embarked on a search for the tools and manpower to do an EMS
development. The task was enormous as the company had no EMS
and needed to play "catch up" in a big way to support the many
RFP's that required EMS functionality. The obvious candidates
were considered and rejected as they seemed too rigid in their
approach for little or no savings in "Time to Market".
After a very extensive and exhaustive search I settled
on DNMS as it allowed more flexibility in development and
afforded a more unique interface tailored to my requirements.
Indeed Release 1.0 validated the choice perfectly as I recall
we had to change from a totally SNMP based system to more of a
hybrid SNMP/Web GUI approach, thereby utilizing the existing
Web GUI interface while adding SNMP controls for
auto-discovery and alarming functionality.The above change was
made after the project was started. Too many of the other
companies I talked to this would have been an unthinkable
change but for Dhyan it was business as usual and without any
slip in the schedule.
Since then we have made 2 more
Releases adding more and more bulk functionality and mass
configuration options both through SNMP and the native GUI
interface. These developments have also been performed on time
and within budget a truly amazing feat. Thanks to Dhyan our
EMS is now gaining acceptance and we have successfully come
from behind to have a truly world class product for which we
can all be proud.
So here we are, 3 Releases and 10
months later and I am happy to report that the product is
working perfectly. The components based approach of DNMS has
lived up to the promises it made by giving us more
flexibility, more functionality and all delivered in the
scheduled timeframes set at the onset of development.
(Something that I very much doubt would have happened with
Framework approach which would surely have failed at the very
first hurdle we hit.)
Engineering Manager
EMS
Development
|
