Software Engineering

Dec 13

NM Integration (Nagios & Netcool) – Catch the headfake!!

Fault Management, Nagios, Netcool, Service Assurance, Solution Design 1 Comment »

Some product/consulting companies charge upto 25K USD for integration of FM-FM/FM-PM products. One has to be careful of such offerings because not only they have a one time cost, but also they come with a continual license fee for the gateway. BAD!! So let me save you some money by generalizing this process by an example of integrating two highly used NMS solutions – Tivoli Netcool [from IBM] and NAGIOS [Open source offering]. Integration from Nagios to Netcool is simple [not sure why people pay tones of money for this] and can be done in couple different ways:

Overview

Asynchronous uni-directional data flow [from Nagios SBI to Netcool] : In this method of integration, Netcool shall receive events as forwarded, but shall not acknowledge the event back in Nagios. This is useful when Nagios is not used by operators for RT monitoring.
Synchronous bi-directional data flow: An event in Nagios will flow to Netcool and will be confirmed back in Nagios as recieved by Netcool. On every update on the event [such as journal entry, acknowledgements] the event in Netcool, status shall be updated in Nagios.

Either options work based on the business/solution requirements. So without further ado:

Implementation:

Asynchronous uni-directional data flow [from Nagios SBI to Netcool]

To understand the implementation, I shall divide the steps as southbound implementation and northbound implementation. Southbound implementation refers to the changes/configuration on Nagios end, and Northbound implementation refers to updates in Netcool.

Southbound updates [On Nagios];

a) Create a script to send tcp socket messages or snmp traps or direct JDBC insert to NBI.

You can use snmptrap command for writing the script, if you are not a SNMP guy you can use a simple script to do socket message communication/JDBC inserts into Objectserver. Test this script.

sample snmp script:

Send trap

# Arguments:

# $1 = Management Station

# $2 = Community String

# $3 = host_name

# $4 = service_description (Description of the service)

# $5 = return_code (An integer that determines the state

# of the service check, 0=OK, 1=WARNING, 2=CRITICAL,

# 3=UNKNOWN).

# $6 = plugin_output (A text string that should be used

# as the plugin output for the service check)

# Sample

# /usr/bin/snmptrap -v 2c -c $2 $1 ” NAGIOS-NOTIFY-MIB::nSvcEvent nSvcHostname s “$3″ nSvcDesc s “$4″ nSvcStateID i $5 nSvcOutput s “$6″

b) Define a global event handler in Nagios: Global event handler will help execute the script on every state change on Nagios instance and will communicate, failure and seizure of the problem. How to configure GEH: http://nagios.sourceforge.net/docs/2_0/eventhandlers.html

Northbound updates [On Netcool]

If SNMP:

a) Download the Nagios MIB and compile with MIB2Rules

http://sourceforge.net/projects/nagiosplug/files/nagiosmib/

b) Update the rules file and include it in mttrapd main ruleset

If socket:

a) Update the socket probe to parse message based on delimiters

b) Ensure all mandatory objectsesrver fields are accounted for

If JDBC:

a) Ensure all mandatory objectsesrver fields are accounted for

b) **CAUTION** Watch the objectserver profiler for IDUC consumption, as this is not so much of a conventional approach

DID YOU CATCH THE HEADFAKE?

Nagios an Netcool were just examples, you can integrate most FM-FM/FM-PM solutions using the aforementioned procedure, you just need to know the NBI data model, SBI data model, right triggers on the SBI system and right listner on NBI system. Made your life easy, din’t I? So start saving your company some money now!!

In the next post, I will talk about method 2 {bidirectional data flow}. Keep visiting!!

Tagged with: Integration • Nagios • Nagios- Netcool Integration • Netcool • NMS

Nov 11

Network Management in the LTE and SAE paradigm

Business Service Management, Enterprise Architecture, Fault Management, Network Management, Service Assurance, Service Management, Software Architecture 7 Comments »

For those in the Service and Network management industry who are not aware of what is going to hit us in the next 5 years, I would like to give an overview of what LTE and SAE and then talk about the effects of these technology evolution on our ways of working. I am Software solutions expert and not a Network scientist and had to get in touch with a lot of folks, do a lot of research and dig a lot of books to find this data. Below are very high level abstract explanation of LTE and SAE networks and the purpose they serve.

LTE [Long term evolution] is the one of the proposed 4th generation radio access network technology and if all goes as planned the world will be wireless and with much higher data rate after a successful implementation. Recent tests on the field have been successful and all the investments planned by US telecom market indicates that this is definitely going to be the future of access Networks. The main node of this network would be the eNodeB which would encompass the functional behavior of multiple nodes of our current network paradigm. The end goal architecturally is to have a flat architecture for 4G networks. End goal from user perspective is increased data rate and quality, along with reduced cost and access anytime/anywhere.

SAE [System Architecture Evolution] on the other hand will be the core for the 4G networks, is focused on a all IP, flat architecture, improved data rate and reduced CAPEX/OPEX expenditures. Evolved packet core [EPC] to which the eNodeB will connect, serves as the central functional unit of the core architecture.

Now, what does all of the above mean to Service and Network management as it is known today to what it would become in the coming years of 4G networks. Will get to this in my next post. Stay tuned!

References:

http://www.radio-electronics.com/info/cellulartelecomms/lte-long-term-evolution/sae-system-architecture-evolution-network.php

“Self-configuring and self-optimizing network use cases and solutions: Release 9”; 3GPP TR 36.902; Sept, 2009

Tagged with: LTE • NMS Architecture • SAE • SON

Sep 07

BSM Solution Documentation Step 1: solution architecture document

Business Process Management, Service Assurance, Service Management, System Architecture 1 Comment »

For a BSM/SQM/Service Assurance solution, initial solution architecture document is one of the most crucial artifacts which not only details the strategic objectives of the solution but also provides a competitive analysis and an alignment to the existing capability of the organization. Furthermore, it provides an insight into the driving requirements, architectural background and key organizational context to ensure that the solution being built for the organization and is not something rammed down the throat off-the shelf.

Detailed below is the template:

1 Executive Summary

CONTENTS OF THIS SECTION: This section an overview of the content of the rest of the report, giving key facts that management would like to know about its contents. The executive summary should give the most important aspects of the report while omitting details and some supporting information. Generally speaking, the summary should be not longer than 1 page and preferably as short as possible while conveying the required information.

1B [Optional, for mature organizations] Strategic Capability Network

Analysis of how the strategy aligns with the organizations capabilities and resources. You can safely skip this section if you already have a defined BSM strategy and a competitive analysis document detailing the value propositions that drive the business. For details refer the patent here and my analysis with an example here.

2 Introduction

CONTENTS OF THIS SECTION: This section gives the name of the system and describes its high-level functions. This is expanded upon by the history and stakeholders sections.

2.1 History

CONTENTS OF THIS SECTION: This section provides the historical context for the system. It answers how the system was developed and by whom.

2.2 Stakeholders

CONTENTS OF THIS SECTION: This section provides a list of the stakeholder roles important to the system. For each, the section lists the concerns that the stakeholder has that can be addressed by the system.

3 Architecture & Problem Background

CONTENTS OF THIS SECTION: The sub-parts of Section 3.1 explain the constraints that provided the significant influence over the architecture.

3.1 System Overview

CONTENTS OF THIS SECTION: This section describes the general function and purpose for the system or subsystem whose architecture is described in this SAD. Include a high-level context diagram of the system and summarize major inputs and outputs.

If you don’t know how to build an accurate context diagram, look here.

3.2 Goals and Context

CONTENTS OF THIS SECTION: This section gives the name of the system and describes its high-level functions that the BSM solution is offering and more importantly how the solution would fit into the current value chain of the organization.

3.3 Significant Driving Requirements

CONTENTS OF THIS SECTION: This section describes behavioral and quality attribute requirements (original or derived) that shaped the software architecture. Included are any scenarios that express driving behavioral and quality attribute goals.

This section should only list the key driving requirements and not detailed requirements for the solution.

4 Competative Landscape

CONTENTS OF THIS SECTION: This section lists and briefly describes the major competitors of the system. Competitors are those systems that do the same thing as the system or those systems that could otherwise be used in place of the system. It also gives a high level overview of the strengths, weaknesses, opportunities and threats of the system explained in more detail in the following sections.

4.1 Strengths

CONTENTS OF THIS SECTION: This section describes the functions that the system does well either in comparison with its competition or in absolute terms.

4.2 Weaknesses

CONTENTS OF THIS SECTION: This section describes the functions that the system does poorly in relation to its competitors or in absolute terms. Also included could be features that competitors have but the system does not, or features that the system should have but does not given the stakeholders and high-level requirements described in the previous section.

4.3 Opportunities

CONTENTS OF THIS SECTION: This section describes what the opportunities are for the system. Opportunities are factors external to the system (e.g., in the overall environment) such as general trends or actions of competitors that enable the system to increase its market share or usefulness to stakeholders.

4.4 Threats

CONTENTS OF THIS SECTION: This section describes the threats that the system is likely to experience. Threats are factors external to the system such as general trends or actions of competitors that decrease the market share of the system or its usefulness to stakeholders; in the extreme case, threats might render the system obsolete.

5 Referenced Materials

CONTENTS OF THIS SECTION: This section provides citations for each reference document. Provide enough information so that a reader of the SAD can be reasonably expected to locate the document.

6 Directory

6.1 Glossary

CONTENTS OF THIS SECTION: This section provides a list of definitions of special terms and acronyms used in the SAD . If terms are used in the SAD that are also used in a parent solution description document and the definition is different, this section explains why.

6.2 Acronym List

If you work in telecom or finance world, you would know as i do, the TLA’s [Three letter acronyms] are annoying from organization to organization. So, don’t assume – take 10 minutes and add value to your BSM document.

Acknowledgements:

SEI Architecture documentation

Professor Jeff Thompson

Professor J Vayghan

Tagged with: BSM Architecture • NMS Architecture • Software Architecture • Solution architecture

Jul 13

TOGAF 9: An Implementation Perspective

Enterprise Architecture No Comments »

My first observation on TOGAF 9 was that it is more business focused compared to TOGAF-8 with the addition of Business vision, drivers and capabilities (which is also inline with SCN). Before this version 9 TOGAF was definitely in the IT realm, and IT was essentially defined as hardware and software. By bringing business perspective with lifecycle into Business, Information, Data and Application architecture TOGAF has added a new set of offerings to its arsenal.

Note 1: The definition of IT in TOGAF 9 is the lifecycle management of information and related technology within an organization. In-line with what we have been discussing in class that we need to take a problem and build a business solution rather than build a solution and find Business problem.

For past few years, IT has been looked at a medium of simply automating tasks to reduce cost and getting tasks accomplished by throwing requirements over the wall. TOGAF provides an approach of integrating IT with Business using the ADM as a comprehensive guideline for establishing Enterprise architecture program by step by step procedures. This is especially useful for organizations considering starting an Enterprise architecture program.

Note 2: The single biggest news about TOGAF is a new, mature, well-defined architecture content framework of 170 pages, built on the experience of major systems integrators through hundreds of architecture projects. Emphasizes on Organizational learning (also discussed in class) via meta model is an important aspects.

Developing meta-model for enterprise content across the organization and utilization of the content for strategic and operational planning is the only way Business, Operations and IT can be aligned together. Most large organizations like the one that I work for; have multiple data repositories disparately fragmented across the organization. Due to lack of catalog management of this data, the organizational learning curve is low and leads to accessibility problem for right information at the right time and for the right objective. TOGAF proposes a detailed solution to this problem with the architecture content framework; by putting emphasis on the actual information, its access, presentation, and quality, so as to provide not only transaction processing support, but analytical processing support for critical business decisions provides great edge to TOGAF. This change gives new perspective value proposition for Enterprise architecture framework.

Note 3: TOGAF 9 puts emphasis on Service Oriented Architecture and Integrated system approach – Business Perspective of SOA
The biggest implementation aspect of TOGAF 9 is the emphasis on service oriented systems and integrated system approach. This is due to involvement of system integrators; who are one of the most important stakeholders of the Enterprise architecture program. To get the best return on investment for SOA, it is important to understand from a business perspective what capability your business has and why. One thing that’s really key about TOGAF 9 is that it takes a lot of ideas and practices that exist within individual organizations or proprietary frameworks, building a consensus around it, and releasing it into a public-domain context. Once that happens, the value you can get from that approach increases exponentially. Now, you’re not talking about going to one vendor and having to deal with one particular set of concepts, and then going to a different vendor and having to deal with another set of concepts, and dealing with the interoperability between those.
Note 4: TOGAF 9 allows enterprise architecture to be molded with operations management, system design, portfolio management, service management, business planning, and the Governance Institute’s COBIT guidelines. – Compatibility

One critical aspect of adopting a framework is evaluation of compatibility of the framework in the organizational ecosystem. TOGAF is very well equipped in this aspect due to compatibility guidelines for managing operations, systems design, portfolio management, service management, business and strategic planning. In addition to this, TOGAF provides governance guidelines to ensure alignment of Business, operations and IT and providing the equilibrium to provide optimal solutions for priority business problems.
To conclude, Fred Brooks has very truly pointed out that there is no silver bullet for building the best solution and “Doing the things right!!” but using TOGAF solves four of the most critical aspects for reducing the accidental complexity which are: Organizational learning via Content model frameworks, emphasis on Business perspective of SOA, Value propositions alignment to investments and finally the guidelines for effective governance by Enterprise architecture program.
References

Name
Reference
TOGAF 9 users see benefit for SOA
http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1347340,00.html
TOGAF 9 advances IT maturity while offering more paths to architecture-level IT improvement
http://briefingsdirectblog.blogspot.com/2009/02/togaf-9-advances-it-maturity-while.html
Never Mind the Architecture Frameworks: Here’s TOGAF 9
http://rasmussenreport.wordpress.com/2009/02/06/never-mind-the-architecture-frameworks-heres-togaf-9/
TOGAF 9 Architecture Documentation
http://www.opengroup.org/architecture/togaf9-doc/arch/