EM7 Dynamic App Development

Dynamic Application development in EM7 is easy and a lot of fun.

A Dynamic Application in EM7 is used to gather statistics, configuration data, performance data, set thresholds, and setup alerts and events.

In the past, I've done alot of SNMP based applications where I would have to take SNMP Walks, the MIBs, and put together polling, thresholds, and triggers for events. I'd download the MIB, suck it into Excel, and start analyzing the data. A lot of time would be spent parsing MIBs, verifying tables, and looking at counters.

Enter EM7.

Login and go to System->Tools->MIB Compiler

It provides a list of all MIBs it knows about.

From this, you can see if the MIB you're looking for is there and compiled. If its not, you can hit the import button up on the top right portion of the window and it will prompt you to upload a new MIB file. (Pretty friggin straight forward if I do say so myself!)

To compile the MIB, hit the lightning icon on the MIB entry. Simple as that.

So, lets say you want to create a dynamic application around some configuration items associated with a couple of MIB tables in a MIB. For our example, we will use the CISCO-CCME-MIB applicable for the cisco Call Manager Express systems.  You can view the MIB using the I icon, download or export hte MIB via the green disk icon on the right side of the entry, or compile it using the lightning bolt.  I'm going to view the MIB so I select the I icon for the row for the MIB I want.

I hit the icon and it pulls up a file edit window.  I scroll through to find an object I'd like to work with as an application.  I highlight the object and copy it to my clipboard.









I go to System->Tools->OID Browser, select Where name is like in the search function and I paste the object I was looking at in the MIB.  This pulls up a hierarchy of the OIDs and MIB objects below the object I input. All in all, we're into the second minute if you're a bit slow on the keyboard like me!

Notice on the top of the selection box is the MIB object path.  This is handy to visualize where you are as you start to work with MIB objects.

So, the first application I want to put together is a configuration type of application centered around parameters that are part of the Music on Hold system function.  I select the MIB elements I want to work with in my configuration application by clicking on the box for each parameter.

On the bottom right corner of this window is a selection box with a default value of [Select Action]. Pull down the menu and select Add to a new Configuration Application.  Select the go button directly to its right.

You are then prompted if this is really what you want to do. Select Yes.




What this does is to  take the MIB objects and create a dynamic application with your collection objects setup already.  Here is what it looks like.

If you do nothing else, go to the the Properties tab, input an application Name, then save it. You have just created your first dynamic application in its basic sense of form and function.








This is what the Properties screen looks like:

Overall, you have a lot of work to do in that you probably need to cleanup the names of the Objects so that they show up better on reports. Setup polling intervals.  And setup any thresholds, alerts, or events as needed.  But you have an application in a few minutes. And it can cross multiple tables if you like! CLICK CLICK BOOM!

ENMS Projects

I have been looking over why a significant number of enterprise management implementations fail. And not only do they fail in implementation, they continue to live in a failed state year over year. Someone once said that 90% or greater of all enterprise management implementations fail.

I cannot help but to think that part of this may be something to do with big projects and evolution during implementation.


Another consideration I have seen is that lower level managers tend to manage to the green and are afraid of having to defend issues in their department or their products. When they manage to the Green, management above them loses awareness of how things are really working beneath them in the infrastructure.

One article I really liked was by Frank Hayes called "Big Projects, Done Small" in a recent Computerworld issue. Here is the link to it. I like his way of thinking in that big projects need to be sliced and diced into smaller pieces in order to facilitate success more readily.

Those of us in technical roles tend to operate and function in a 90 days are less role. We know from experience that if you have a project exceed 90 days, the "Dodge Syndrome" will rear its ugly head. (The rules have changed!) In all actuality, requirements tend to change and evolve around an implementation if the implementation takes over 90 days.

The second part you realize is that in projects that need to span over 90 days, mid-level Managers tend to get nervous and lose faith on the project. Once this happens, you start seeing the Manager retract support and resources for the project. The representatives don't show up to meetings.

But Tier 1 managers like the big, high cost projects as it is a way of keeping score. They like the big price tag and they like the enormous scope of global projects.

It is the job of Architects to align projects into more manageable, chunks for implementation and integration. They need to know and plan the budget for these projects so that you get what needs to be done, in the proper sequence, with the proper hooks, and with the proper resources. If this is done by Project Managers, Contractors, or Development staff, you risk the project becoming tactical in nature and lose sight of strategic goals.

When a project becomes tactical, the tasks become a cut list that has to happen every week. When something changes or impacts the schedule, tactical decisions are made to recover. For example, a decision to modify a configuration may be made today that kills or hampers an integration that needs to be done in a few months. These tactical decisions may save some time and resources today but yield a much larger need later on.

It is the equivalent to painting yourself in a corner.

Here in lies the situations that are oh so common:

1) Tier 1 Management wants to show the shareholders and Board of Directors that they are leading the company in a new direction.

2) Mid-level tiers of management can chose to use this project to promote their own enpires if possible.

3) Mid-Level managers can chose just to accept the big project and support it as needed.

4) Architects need to be keenly aware and on top of the project as a whole. They need to set, establish, and control direction.

5) End users need to be empowered to use the product to solve problems and work with Architecture to get their requirements in.

Conclusion

A big project can be accomplished and can succeed. But the strategic direction needs to be set with a vision for both tactical and strategic goals alignment. Things need to be broken up by goals and objectives and costed accordingly. Simplify - simplify - simplify.