There are a number of ‘standards’ out there that, as a system integrator or product vendor, you may want to use within your OSS solution. Stuff like MTOSI, OSS/J, SID, 3GPP all look like useful starting points for inventory-like data models and their integration points.
It is important to appreciate the difference between a standard’s published specification and an implementation of a useable database model and business logic.
Let’s consider TeleManagement’s MTOSI as an example, as it is the most popular standard for network data exchange right now. The MTOSI specification is not concerned with implementation of an inventory model, or how it is maintained by a database and operated against by an application. Nor does MTOSI define ‘metadata’; the definitions of what are valid models, e.g. what equipment comprises a specific type of Cisco router. MTOSI just provides a means of describing network elements. MTOSI arose out of a need for a standard way of pushing up the data held by network element managers in to network management systems or cross-technology OSS platforms. So, it’s main focus is in defining a data format and a number of operations around retrieving or modifying the data.
Here’s a very high level picture of the MTOSI physical model. There are many other entities that can be modelled, and much more detail in the actual specification, available from the TeleManagement website.
above. Simplified MTOSI Physical Model. Click to Enlarge.
Looks good. If I’m developing any application that needs its own internal record of network equipment, this would be a great place to start.
MTOSI’s physical equipment model is quite straight forward. It allows hierarchies of objects to define the common device-shelf-slot-card-interface model of telco equipment.
To some extent the MTOSI model looks like a database model, as if it could be mapped directly in to tables to create a useful inventory. This is not the case, for a technical and design reasons.
Object-Relational Mapping. The MTOSI model is an object oriented model. Databases are usually relational model. It’s the old ‘object-relational impedance mismatch’ that requires applications to do apply business logic to an object model but persist those objects in a relational database, such as Oracle or MySQL.
There are also OSS and application-specific design considerations that will mean the MTOSI model may be best implemented in a particular way. These three factors normally have to be balanced depending on the OSS application’s requirements. For example one might have to sacrifice some performance in favour of flexibility.
Design for Performance. Response times, concurrency and scalability all combine in some acceptable compromise to deliver an application that 'performs well'. In OSS, raw single-thread performance is usually traded-in for good concurrency (multiple process/user threads) and scalability (effective use of additional hardware). Overall performance is usually best when building data schema and code to a static design, i.e one that does not rely on introspection and data-driven code. A static design allows for assumptions to be made, reducing checks, queries, lookups, error handling and process roll-back overhead.
Design for Flexibility. Some applications work to an original, fixed design. Rarely is this true of OSS applications. In OSS flexibility must be offered to allow customers to deploy their own inventory objects, provisioning processes and activation scripts. If done well, flexibility is enabled through data-driven configuration and clearly defined APIs. Architecting these features requires extra layers of abstraction and checks which inevitably result in reduced performance.
Design for Maintainability. While the end customer needs application flexibility to make changes to their deployed product version, the software developer needs to be able to maintain the application as requirements change between product versions. For example, an inventory product based on the MTOSI 2.0 standard will one day need to be upgraded to support MTOSI 3.0. This could either require a redesign of the data scheme, possibly impacting backwards compatibility, or it could be achieved through metadata and limited schema changes supported by clever 'introspection' by the system's public APIs.
At one extreme, systems that have critical performance requirements, such as data migration or bulk update processes, would be designed for high performance at the expense of flexibility and maintenance: assumptions might be hard-coded in the process, integrity constraints disabled, layers of system architecture replaced by transaction scripts. A multi-purpose OSS inventory, that needs to support several applications and business functions, would expect to sacrifice performance in favour of flexibility: Layers of system abstraction, configuration, metadata and integrity constraints would be implemented.
above. Design Requirements for OSS Applications. Click to Enlarge.
When implementing a standard, designing database schema and coding business processes, one has to start by establishing what the priorities are that will drive the system architecture design.
> The standard’s specification itself does not dictate how you implement it, only what data and services it should support.
> There’s many, many possible ways of coding a database and Java application for any one given standard, such as MTOSI.
> An implementation of a standard will vary depending on the type of application that is using it.
>The first question to answer is, how important is performance, flexibility and maintainability? They can’t all be high priority!
Coming soon! Part two will look at options for mapping an MTOSI-like standard to a relational database such as Oracle, considering common architecture options and their suitability for particular OSS applications.
