Microsoft Word - Ni2_White_Paper_CMDB_System _format_
Upcoming SlideShare
Loading in...5
×
 

Microsoft Word - Ni2_White_Paper_CMDB_System _format_

on

  • 1,144 views

 

Statistics

Views

Total Views
1,144
Views on SlideShare
1,144
Embed Views
0

Actions

Likes
0
Downloads
47
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Microsoft Word - Ni2_White_Paper_CMDB_System _format_ Microsoft Word - Ni2_White_Paper_CMDB_System _format_ Document Transcript

    • 2 N(i) MULTI-DOMAIN CMDB SYSTEM DOMAIN WHITE PAPER This paper offers an introduction to the kind of robust CMDB that IT organizations need today; one that allows them to maintain control and share knowledge across all IT silos; one that takes an holistic approach, and works as an open-object system to exponentially expand the object possibilities of configuration management as a discipline. It will explore figuration the necessary components of a CMDB built to empower all IT groups, making sure they are all aware of all the information needed to be aligned with their company’s business objectives. And, it will explain how the expl N(i)² Multi-domain CMDB system can help an organization bring such control and certainty to ICT infrastructure management and change management, whatever the business model and objectives.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Contents 1.0. Introduction .......................................................................................... 3 2.0. A sea of CMDBs ..................................................................................... 4 3.0. A True CMDB: one part London cabbie, one part R2-D2, one part M*A*S*H’s Radar ......................................................................................... 5 3.1 Radar works in my IT Dept. ................................................................................................... 5 3.2 The London cabbie ............................................................................................................... 5 3.3 R2-D2: the droid that can interface with anything .................................................................... 6 3.4 What does this have to do with a CMDB System? ..................................................................... 6 4.0 What is a CMDB supposed to do? ............................................................ 7 5.0. The N(i)² Multi-domain CMDB System ................................................... 8 5.1. Federation .......................................................................................................................... 8 5.2 The three key elements to federation: .................................................................................... 9 An open object model ................................................................................9 Flexible CMDB Population with an extended scope of CIs ................................ 9 Rules-based reconciliation ........................................................................ 10 5.3 Absolute Visibility to spur creative solutions........................................................................... 11 6.0 Change Management ............................................................................ 15 6.1 Multiple Environments for Planning Changes .......................................................................... 16 6.2 Mastering Change and Release Management.......................................................................... 16 6.3 N(i)2’s End-to-End Change Process ....................................................................................... 17 7.0 Conclusion ............................................................................................ 18 7.1 Features of the N(i)² Multi-domain CMDB system: .................................................................. 18 A standalone product ............................................................................... 18 An extended scope of CIs ......................................................................... 18 Multi-domain configuration management .................................................... 18 Planned change impact assessment ........................................................... 18 Open object model for complete federation ................................................. 18 Multiple viewers ...................................................................................... 19 Multi-tenancy for secure federation ............................................................ 19 Advanced visualization capabilities ............................................................. 19 Catalog and template-driven ..................................................................... 19 Rule-based reconciliation .......................................................................... 19 A spatial engine for better view on assets ................................................... 19 Extensive reporting tools .......................................................................... 19 Technology to accelerate CMDB initial load ................................................. 19 8.0 About N(i)²® ........................................................................................ 20 2|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 1.0. Introduction In the Disney kids’ movie, The Jungle Book, the climactic scene involves a hair-raising chase wherein Baloo, the bear, literally has a tiger by the tail. At one point, a vulture flying overhead advises that it’s safe to let go, but Baloo disagrees. “Are you kiddin'?” he says, exasperated, “There's teeth on the other end!” If you’re working in IT in the 21st century, you’ve probably had a similar experience. It’s one thing to have a tiger by the tail and manage to hang on for dear life, but you don’t want to think about what might happen if you lose your grip. Of course, eventually something’s got to give. So before it does, you need to figure out how to tame that wild animal. Companies of various sizes are quickly realizing they need to organize all the activities of their disparate IT groups into a coherent whole. The greatest challenge for IT operations today is to maintain their grip on the growing inventory of infrastructure needed to keep the systems up and the data flowing for their organizations - as the dependency on that infrastructure continually expands, forging new relationships within its own mesh of complexity. There is no way to even begin to get a handle on the situation without first taking full stock of that infrastructure in its entirety - in other words, caging (or containing) the tiger - knowing exactly what you have, where it is, how it is connected, who depends on it and how it affects the business it is there to support. To gain and maintain control over an ICT infrastructure, IT managers need visibility over all elements, relationships and dependencies. Then, they need to be able to assess how future changes would impact on the infrastructure with minimal disturbance to users and existing services. Often, this sort of information is mission-critical for business continuity, and in ways that are only understood by the most knowledgeable IT staff in the office; but of course, that’s assuming they have a good hold of that tiger’s tail and can maintain their grip. The advent of the Configuration Management Database (CMDB) promised to change all that, with storage of information in one place, where all IT staff can access it (and be sure that it’s the same data everyone else is using, too). Still, there is a whole other dimension to CMDB deployment and infrastructure management that standard CMDBs on the market fail to take into account. 3|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 2.0. A sea of CMDBs Industry experts are hailing configuration management as the next wave of IT. But as with any “next wave,” the bandwagon is filling up with systems that are hyped as CMDBs, when in fact, they are built to go just as far as is necessary to support existing services. Many so-called CMDBs are either discovery-based or process-based in how they are populated. Discovery-based CMDBs are effective at populating discoverable information, such as servers, routers and workstations, but remain reactive in supporting IT organizations during the implementation of changes. On the other hand, many existing process-based CMDBs record information as a by-product of IT businesses processes, but are also incomplete because they lack the depth of discovery, the ability to incorporate undiscoverable data, as well as provide visibility on the dependencies of shared IT infrastructure with customers and services. Many vendors, recognizing an opportunity, have added a CMDB to their offering to complement existing product lines. These solutions are adjuncts to tools that are their true core competency, and as a result only support certain IT domains, such as dependency mapping or business service management. But doesn’t a CMDB need to support the entire enterprise, and not just a single domain such as security or service management? Wasn’t that the whole reason we started looking to a CMDB as a solution in the first place? If the goal is to find the best tool to manage ever-changing ICT infrastructure, perhaps we need to think outside-the-box to get a better understanding of how the successful solution should be modeled. 4|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 3.0. A True CMDB: one part London cabbie, one part R2-D2, one part M*A*S*H’s Radar 3.1. Radar works in my IT Dept. There’s typically a Radar (think: M*A*S*H) in every IT group who acts like a CMDB (in other words, the one person who is the “single source of truth”). Like our enigmatic character from Iowa, they have that uncanny knack of knowing exactly what is needed almost before it is requested. If you want to know when that exchange server first went online, they can tell you all about it, down to every horrific detail about what a disaster that was, when no one could access their email for a week. If you want to know what departments access what database, they can rattle them off without even looking up from their console. They’ll also tell you what systems the Shipping department was given access to, but never use. They tend to have their domain’s entire infrastructure - with all its complexities and foibles - mapped in their minds. They are the ones who can crack each other up with punch lines like: “So he says, ‘No, it’s an RJ-45’”. Then one day, they’re not there anymore; they have figured out they can gouge you far more effectively by resigning and going into business as consultants. And when they go, usually their knowledge goes with them, because we tend to keep them too busy to ever document what they know about our infrastructure or effectively share it with co-workers. 3.2. The London cabbie Let’s examine the seasoned London Black cab driver. He/She’s that cabbie who knows everything there is to know about navigating one of the most complicated and dynamic grids in the world. As he drives around the city, he methodically picks up bits of information about changes in the extensive network of roads. He listens to traffic reports on the radio, and knows which station to tune into, and when. He knows that if there’s a street fair going on, there will be gridlock along said streets. If the power is out on the corner of St James and Piccadilly, it may also be out on Piccadilly and Regent. When there is a rock concert at Wembley Stadium, he knows what routes to avoid at what times. 5|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. If a street name has changed at any time since WWII, he knows when, and the politics of why. Since 1865, obtaining a London Taxi license has involved passing a proficiency test (“The Knowledge”) that requires being able to find the quickest, most efficient route between any two points, and is tantamount to a lawyer passing the Bar exam. Indeed, it can take up to four years of “in the field” study to acquire The Knowledge. But the learning process doesn’t stop there; it’s a mammoth task in information processing that each cab driver has to keep on top of constantly to do their job competently. 3.3. R2-D2: the droid that can interface with anything Remember Star Wars? Remember that scene when the heroes have all infiltrated the Death Star and rescued the princess? Only to find themselves stuck in a trash compactor? Who saves the day? Not our hero, Luke. Not Han Solo. Not the beautiful princess, but R2-D2. How does he do it? Well, luckily, R2-D2 is a well- designed little droid. He seems to be able to interface with everything, even if he hasn’t seen it before. In this case, he plugs into the Death Star and within seconds, he can determine which garbage compactor his master is being crushed in, where the control is, and how to shut it down. He then proceeds to do so without giving away his location to Darth Vader. Let’s just say this little droid is one extensively federated robot. He’s got the ultimate interface to draw information from any source of data, and to cross reference it to other sources of data. He stores the information and can access it at the right time, the right place and in the right context. 3.4. What does this have to do with a CMDB System? A CMDB system needs to store the knowledge captured by Radar, to be maintained as the organization expands like the London cabbie, and to use that information at the right time in the right context, like R2-D2. In the absence of a Radar, or even when he/she is there, the ability to effectively share information with co-workers and other IT departments is essential to having an overall understanding of a whole ICT infrastructure. Too often, the network manager and the data center manager (for example) don’t realize the full effects of something in their own domain on the other, and when one implements changes, it can lead to all sorts of time-consuming (and potentially costly) back-tracking and undoing and starting over for both departments to engage in. Meanwhile, the business waits while they hash it out. Driving a cab is all about understanding infrastructure and managing change: and it’s also part of an IT management system that wants to “choose the best route”. Knowing all the details of an 6|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. infrastructure - and what impacts on what - helps IT managers mitigate risk when implementing change. A proper CMDB system should give IT managers the tools to model change in a virtual environment in order to plan and analyze the impacts before finalizing and rolling it out. R2-D2 is an “open-object model” that can gather information from any existing source, and federate with known data. A proper CMDB system should likewise be built to ensure it can be populated from numerous sources, without being constrained by discovery tools, or proprietary system tools. With a well populated object-oriented multi-domain CMDB system that federates with current systems and information repositories, an organization can be equipped with the same acute knowledge that our characters above enjoy. No more silos of information, no more complex learning curve for every new employee, and no more misunderstandings. Your IT staff no longer has to take a shot-in-the-dark approach to solving their IT problems. The data is all there, it can be assessed an analyzed for intelligent decision-making. Clearly, what’s needed is a CMDB system that shares the right knowledge, in the right context, with the right stakeholders, and in the perspective that fits their domain-specific needs. 4.0. What is a CMDB supposed to do? Wikipedia defines a CMDB as: A repository of information related to all the components of an information system. Although repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems from ITIL. ITIL defines a CMDB as: A database which contains all relevant details of each CI and details of the important relationships between CIs. When true to its core definition, a CMDB amounts to an automated “Radar” - a repository of configuration management data. As a consistent, dynamic and trusted data source with information on relationships and dependencies, a CMDB can help streamline processes and improve workflow within an organization. But why stop there? Why not model a CMDB on all the best available examples of information management – why not incorporate the qualities of all three of the characters in our Dream Team into an integrated system? In order to truly give an organization value, the CMDB must be adaptable to every conceivable interface, like R2-D2; it should be built on an open data model, have the ability to federate to an organization’s current data sources, and be equipped with tools to map and model discoverable and non-discoverable assets and dependences. 7|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Furthermore, the CMDB must add value to all IT groups by effectively breaking down barriers to understanding, and giving all IT staff the tools to better analyze, communicate, and deploy changes to the infrastructure. That is to say, it requires the contextualized multi-domain understanding and systematic change management qualities of our London cabbie. Short these qualities, IT departments continue to struggle to attain operational effectiveness – both in terms of cost efficiency and service quality – even after implementing a traditional CMDB (Radar) solution. Responding to this need, N(i)² created its Multi-domainCMDB System. 5.0. The N(i)² Multi-domain Multi-Domain Configuration Management: CMDB System Offers configuration management tools per domain, and relations and dependencies between CIs from The N(i)² Multi-domain CMDB System is designed to different domains. This capability give IT operations complete visibility over ICT comes complete with domain infrastructure, services and business, making it easy specific engineering rules. These to share data between IT domains. N(i)² adds value to domains include Network, existing IT Service Management solutions by Connectivity, Services, etc identifying how services are connected to underlying physical and logical infrastructure components. MULTI-ENVIRONMENT MANAGEMENT: The N(i)² Multi-domain CMDB System supports any Each repository leverages full type of CI (Configuration item). All elements of an CMDB functionalities to ensure that infrastructure can be entered in the database and the CIs contained in their given attributes. From hardware to IP addresses, from respective environments can be software to printers, all structural items can be manipulated without affecting the visualized. All CI dependencies such as cables and production CMDB. E.g.: CIs can be fibers can also be modeled, providing the ability to modified and added in a planning identify, catalog, track, optimize, and manage CIs. scenario (as Intended) without affecting the ‘golden state’ CMDB. In addition, CIs can be grouped, categorized, and registered on a physical, logical and functional level; ADVANCED VISUALIZATION and templates can be made from grouped CIs, making CAPABILITIES: it easy to populate the initial load and beyond. Not only to map and visualize CIs and their relations within a schematic view, but to contextually 5.1. Federation visualize CIs according to the IT domain (hardware device on the Federation is the ability to offer visibility over the map for the outside planner, entire enterprise using information from as many hardware device on the rack different sources as needed to reflect a elevation view for the data center comprehensive, contextualized picture of an ICT manager, hardware in the network infrastructure. cloud for the network manager…) 8|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. A federated CMDB requires flexible deployment to maximize system performance and to deliver only the information the user needs - for example, information about a specific site or a given region along with common configuration items and relationships with the configuration items of other entities. For a CMDB to provide visibility over the entire enterprise, it needs to offer access to information from all sources to present a complete, accurate ICT picture. Users need to be able to understand data of any type, be it information on physical and logical IT components, information on physical location, or information about the source of data, whether a technology vendor or database. The end result of the process is called federation, enabling flexibility of combining different and disparate data sources into a coherent and global resource management system. 5.2. The three key elements to federation: An open object model N(i)² developed its Multi-domain CMDB System using an open object model to give it the inherent ability to interface seamlessly with other systems and objects, for comprehensive database population. It is thereby generic and easily extensible, having applied the best concepts from different standard inventory object models, including CIM, SID and others. This greatly broadens the scope of the CMDB, allowing for inclusion all possible configuration items (from OSI layer 1 to 7 and above to business layers) and relationships. To remain standards-based, it provides a high- level object model layer. The system offers a software development kit that makes it possible to quickly implement interfaces to other systems and an API generic enough to offer maximum flexibility in customizing interfaces to other data sources. Flexible CMDB Population with an extended scope of CIs To be able to effectively federate, a CMDB needs to support different population strategies, the end result being visibility on the full range of configuration items without having to manage IT domains through silos. N(i)²’s Multi-domain CMDB System can be populated by importing CIs, mapping them to the N(i)² CMDB model; or through federation, accessing data synchronously from external data sources. The latter approach is ideal when some data must still be managed outside of the CMDB; the N(i)² strategy is one of integration, not “rip and replace.” N(i)²’s ability to federate includes items that are discoverable, such as workstations, storage devices and routers, and items that are non-discoverable, such as chassis, racks and cables. It combines this information with any configuration item you need to include, be it documentation, services, user roles, events, essentially any imaginable equipment, service, occurrence or person that is part of your business infrastructure. 9|Page ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Assets such as chassis, racks, cables, service level agreements, warranties and contracts can be entered into the CMDB and given attributes. There are more than 55 categories of predefined CIs, classified into over 240 subcategories that include services, employees, departments, networks and servers. N(i)²’s Multi-domain CMDB system offers default definitions of CIs, which include CI categorizations, all required attributes, CI associations, and business rules. Pre-defined CIs include: • Infrastructure-related CIs, such as network equipment, office equipment, supporting structures, locations, network resources, network link and racks. • Application-related CIs, such as databases, software and processes. • Service-related CIs, such as incidents, problems, requests and services. • Business-related CIs, such as costs, human resources, contracts, cost centres and departments. E x te n d e d S co p e o f C Is S e r v ic e s A p p lica tio n s B u s in e s s O th er • S e rv ice s • S oftw are • C on su m e r • S pecialized • In cid e nts P ackage • S LA e quipm en t • P ro b le m s • A pplication s • C on tra cts • … • T a sk s • D ata ba ses • C os t • … • … • … N e tw o r k F a c ilitie s A s sets S tru ctu re R ou ters B uildings PCs C ables C irc uits R oo m s S erve rs A nten na s C onduits IP A ddress R acks SAN … … … … N(i)²’s Multi-domain CMDB System also offers the ability to attach documents and content to any CI in the form of objects that reference external files in such as Word, PDF or Excel files, email or images. This delivers the flexibility to provide as much information as possible about a particular item. Rules-based reconciliation Ensuring that configuration items are never duplicated and are always up-to-date, N(i)²’s Multi- domain CMDB System was built from the ground up to be able to interface to multi-source, multi- vendor information. It takes data that is owned by different sources, traces all the possible relationships of each item and presents this comprehensive view to the user. 10 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Once the CMDB has collected information, it performs a reconciliation to screen out any redundant data. This is an essential aspect of federation: a true CMDB needs to be able to distinguish new items from items that have previously been discovered. N(i)²’s Multi-domain CMDB System accomplishes this through rules-based reconciliation to detect whether a particular configuration item already exists in the CMDB, intelligently update an item if it has changed and choose the most appropriate source for detecting changes - all based on rules set by the user. This process can be compared to a graph: the nodes represent the actual configuration items and the edges represent the relationships. The reconciliation between two environments is like comparing the two graphs. Rules are provided to compare the nodes and the edges. In the Multi-domain CMDB System’s object model, some configuration items and their relationships may not be dissociated, forming a consistent subset (for example, a card and its ports). In such cases, if a configuration item or relationship of a subset has changed, the complete subset requires reconciliation. Subsets are defined using a theme. Themes can also be used to automate impact analysis. Internally, any CI is identified by its internal root object key, which is timestamp-based. However, the CMDB provides the ability to define the unique set of keys of a specific configuration class externally. For example, if a device is being identified by its FQDN and set of MAC addresses, the unique set of keys will be used to automatically relate a discovered configuration item with a configuration item that exists in the CMDB. They will be considered the same configuration items that need to be reconciled. The outcome of the reconciliation process is a set of change actions that the user can commit or roll back on the target environment. Tasks in the form of configuration items can also be generated for implementing the changes, with changes executed automatically when the tasks are set as “fulfilled” in the change/approval management process lifecycle. The end result of rules-based reconciliation is one central CMDB, with CIs reconciled no matter what inventory they come from. Reconciliation can be scheduled, user-driven or automated and optimized for data mining. 5.3. Absolute Visibility to spur creative solutions A true CMDB is more than just a repository of objects or configuration items. It is a dynamic “It’s a great help to simplify the map of how these items interrelate. This is right management of the entire network. at the heart of the N(i)² Multi-domain CMDB We feel more confident in the data System, designed to spur the kind of creative being accurate… The added value is problem-solving needed in managing change or that we can now follow procedures preparing for new services. You’re never more and work instructions with a than a few clicks (and seconds) away from consolidated source of information. having a relevant picture of the IT dependencies The administration of change between the infrastructure, business layers and management is much quicker and 11 | P a g e ©2008 N(i)² Inc. more structured.” Luc Lornoy, Manager Network and IP Telephony for Federal Public Service of Finance, Belgium
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. mission-critical processes of whatever you need to know about. The ability to see your entire operation brings to the fore relationships that might otherwise have gone unnoticed. It provides the tools to visualize connections, be they peer-to-peer or hierarchical, and it offers the power to consider problems, solutions and alternate configurations from a human resource perspective, a business operations perspective, a technology perspective and more. True visibility means viewing the same data in many different contexts, from many different perspectives, and all on the same screen (including spatial relationships, containers, connectivity and more) through drill-down and drill-up graphical views, lists, reports and maps. N(i)²’s Multi-domain CMDB System thereby provides instant visibility into what would normally take days of sifting through discrete sources of information. All views are synchronized, which means that when you select a CI in one view, it is also selected in all other views that are open. Essentially you can see the same data in many different contexts, from many different angles, making connections you would otherwise not have made. Peer-to-peer context: connectivity views 12 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Location context: map views, plan views, drill down from geographical region to specific room Business context: rack and chassis elevation views, network schematics. 13 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Multiple contextual views. 14 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. Domain-specific views (data center management.) 6.0. Change Management The N(i)² Multi-domain CMDB System breaks down barriers between your organization’s IT domains by making it easy to share data and determine how an event or a change will affect all ICT infrastructure, people and dependencies. It is designed for the management of all types of change, no matter the scale, process, or complexity. With a flexible feature set that gives you complete visibility over your ICT infrastructure, the CMDB works seamlessly with N(i)² Discovery, Modeling, and Change Management applications to facilitate change processes, and maintain the CMDB “Golden State” at all times. Change Management ensures that all changes to CIs are carried out in a controlled process by identifying all business and IT services that will be affected by the change including planning, authorization, testing, and reporting. Many of these processes can be automated with the robust N(i)² Multi-domain CMDB System and Change Management applications. 15 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 6.1. Multiple Environments for Planning Changes Multiple Environments enable the staging of large scale projects in a temporary work environment. These projects may be data import activities that could affect the integrity of the CMDB, or large scale projects that require impact analysis. Multiple Environments allow for the creation of multiple scenarios based on real-time information from the CMDB without affecting its integrity giving IT managers the ability to make decisions based on careful planning and assessment. Multi-Environment Management Features: - The ability to thoroughly plan and assess the impacts of changes - Add, delete, manipulate, and model CIs and dependencies in a virtual environment while extracting data from current infrastructure information (as stored in the CMDB). - Check current configurations for conflicts with future infrastructure changes - Model future “as intended” changes in alternate scenarios - Analyze change impact on business from financial and logistic perspectives No other CMDB offers this kind of information and flexibility with built-in mechanisms to plan change. 6.2. Mastering Change and Release Management A full 70% of IT faults and failures occur as a result of change, which is eloquent testimony to why effective change management is critical to any successful IT operation. N(i)2’s Multi-domain CMDB System offers support for the ITIL Change Management and Release Management processes, in the context of resolving errors or implementing changes in the ICT infrastructure. Throughout the entire process, from request to post mortem, the CMDB system draws information from - and delivers it to - the change and release process, delivering the most complete information possible during the planning stage. This is accomplished by synchronizing change and release management with the Multi-domain CMDB System for a closed-loop process. Like the London cabbie learning of a sudden road closing and re-navigating while en route, everything is done within the CMDB. The data to plan your change is drawn from it, then visualized, staged, tested, approved and finally released within it. At the same time, the change request and possible solutions are recorded as CIs, and closed once complete. (Just as the cabbie will make a mental note of the new route and how long it took to drive it!) 16 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 6.3. N(i)2’s End-to-End Change Process N(i)²’s Multi-domain CMDB System supports three types of change processes: reactive, active and proactive. • Reactive change occurs when unplanned changes are implemented and afterwards discovered through a discovery process. • Active change occurs via the request for change process. The CMDB manages the change process and life cycle of configuration items from the creation of the request for change until its closing. • Proactive change occurs via the request for change process, when the change is modelled and impacts are assessed via “what-if” scenarios. N(i)2 is the only CMDB provider to have developed a modelling environment in which you can simulate the change, even creating several different change scenarios. It delivers the tools to visualize, stage and test changes before implementing them in the real world, significantly mitigating the risk involved. You can test different scenarios, gauge the impact on resources, make adjustments and roll out your change smoothly, with as little negative impact on the business as possible. The modelling environment gives you the tools to effectively transition from design to deployment. Using the Multi-domain CMDB System, you assess the change request, identifying any conflicts, exploring optimal timing and assessing the cost. You can test dependencies and experiment with different sequences of action, all in a hermetic staging area using modelling tools. The reconciliation process in N(i)² displays the differences between multiple environments, including the managed environment and the change environment (reactive, active and proactive). The user controls the change by auditing the differences, accepting all or some of the changes or rejecting the differences. When accepting some or all the changes, the user can generate a release plan, or a set of tasks for implementing the change. The organization is thus empowered to make changes that are completely in alignment with business objectives, whether that is to mitigate cost, reduce risk, deploy on a tight pre-determined schedule, or any other balance of considerations determined by management. Once the change has the green light, you can control its roll-out through a release plan, using integrated project management tools such as Gantt charts. Each task is associated with the affected configuration item. Once you have rolled out the change, the CMDB is synchronized with the new changes, and the change is closed and recorded in the CMDB. 17 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 7.0 Conclusion Many CMDBs on the market today can maintain data integrity and map most configuration items, including their relationships (à la Radar, from M*A*S*H). But N(i)²’s Multi-domain CMDB System differentiates itself on many levels. Using various features, such as its fast, synchronized multi-contextualized visuals, it empowers IT departments with tools that not only federate and store information like R2-D2, but also leverage that knowledge to better serve business needs when navigating an ever-changing landscape - like a veteran London cabbie. With the considerable challenges posed by today’s demands on ICT infrastructure management, it’s a wonder how IT departments can “hold that tiger” without it. 7.1 Features of the N(i)² Multi-domain CMDB System: A standalone product The N(i)² Multi-domain CMDB system operates as a stand-alone product, and ships with a robust featureset to help IT staff share information between IT domains. It includes configuration management, multiple repositories, catalog and template management, reporting capabilities and a highly visual interface for holistic views on impacts to services and business. An extended scope of CIs Built on an extended object model, N(i)² supports any CI type (discoverable or non-discoverable, logical or physical), with the tools to add any attribute to it. Whether a service CI, a business CI, infrastructure CI, or a relationship defined by creating a CI, each CI is an independent object. Multi-domain configuration management N(i)² provides modeling and cconfiguration management tools per domain, allowing for greater precision when creating relationships and dependencies between CIs from different domains. Specific engineering rules are provided per domain, including Network, Connectivity, Services, Organizational, etc. Planned change impact assessment Multiple Repository Management allows for the creation of multiple scenarios based on real-time information from the CMDB system without affecting its integrity. IT managers gain the ability to make decisions based on careful planning and analysis. No other CMDB offers built-in mechanisms to plan change. Open object model for complete federation N(i)²’s open object model allows the CMDB system to interface with other systems and objects to populate the database. Highly generic and easily extendable, it has been designed using best concepts from inventory object models including CIM and SID to address all possible 18 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. configuration items (from OSI layer 1 to 7 and above to business layers). N(i)² also offers an API to customize interfaces to other data sources. Multiple viewers The N(i)² Multi-domain CMDB system dashboard is equipped with multiple viewing capabilities including hierarchical, peer-to-peer, location and business context views. Multi-tenancy for secure federation N(i)² offers clients a holistic view of services and relationships connected to underlying infrastructure components without granting access to other clients. This feature also allows for true federation by securely accessing data from 3rd party applications. Advanced visualization capabilities N(i)² visualization not only displays CIs and their relations within a schematic view, but also contextually visualizes CIs according to IT domain (hardware device on the map for the outside planner, hardware device on the rack elevation view for the data center manager, hardware in the network cloud for the network manager…) Catalog and template-driven The client-side architecture of the CMDB system was built on catalogues and templates to facilitate the standardization of procedures and technology selection, reinforcing maintenance of product compliancy and optimizing resource utilization. It also gives an organization the ability to quickly populate and maintain population of the CMDB system. Rule-based reconciliation The N(i)² Reconciliation Engine provides rules-based reconciliation with multiple external sources of information, resulting in a single, reliable dataset. These rules can control which source of information is most accurate and filter which information should be reconciled. They support standard models such as CIM, SID, OSS/J IM, DEN, etc. Multiple inputs can also be reconciled including project scenarios, requests and items using discovery tools. A spatial engine for better view on assets The N(i)² Multi-domain CMDB system imports and integrates GIS maps to help locate resources. Gain a better view on all infrastructure, including floor plans and distances between physical and logical resources. Extensive reporting tools Facilitate decision-making with instant reports on the impacts of a change, compare costs, or evaluate performance of your assets. Technology to accelerate CMDB initial load N(i)² offers bulk import capabilities (tools to import massive data and transform them into N(i)² object model – raw data into structured object model) 19 | P a g e ©2008 N(i)² Inc.
    • N(i)²® Multi-domain CMDB System White Paper, Rev. 2.0. 8.0 About N(i)²® N(i)² develops ITIL-based software for ICT infrastructure management, giving IT managers unprecedented visibility and control over infrastructure, service, and business layers of operation. The N(i)² Suite is designed to give IT operations ultimate control and visibility over all ICT infrastructure to keep all IT groups ALIGNED, AWARE and EMPOWERED in support of business objectives. The software identifies all resources and visually conveys what they are, where they are, and who depends on them. N(i)² makes it easy to mitigate risk by offering advanced tools to assess and analyze how changes affect IT infrastructure, people and services. N(i)² software facilitates communication between IT domains and helps manage the end-to-end change lifecycle using ITIL-based processes for better quality of service. Considered the forerunner in next-generation change, release and configuration management by analysts, N(i)² technology was developed under the assertion that IT organizations need total visibility and control over all their assets and dependencies in order to effectively manage their infrastructure. For more information, contact us at sales@ni2.com, or visit: www.ni2.com. 20 | P a g e ©2008 N(i)² Inc.