Evolving Productivity with IT Asset Lifecycle Management and Configuration Management

By January 4, 2017 Papers
Download PDF Version

 

Evolving Productivity with IT Asset Lifecycle
Management and Configuration Management

for

Master of Science

 

 

  

Software Design and Programming

Brandon Rose

University of Denver University College

March 6, 2016

Faculty: Steve Else, Ph.D.

Director: Thomas J. Tierney, Ph.D.

Dean: Michael J. McGuire, MLS

 

Executive Summary

            As the business grows, the tasks that were once tolerable, soon become burdensome. This is especially apparent in a business where silos prevent the true end-to-end view of work flows and processes. Asset and configuration management are two pain points that multiple business units participate in, but have constant hurdles due to its age, lack of automation and missing interactions with other vital applications. The proposal of a new IT Asset Lifecycle Management (ITALM) and Configuration Management (CM) system using up to date Reference Architectures (RAs) like ISO 55000-2 for asset management and ANSI/EIA 649B for CM, will help ensure that best practices are being implemented. Wireless asset tracking technologies can also play a part in creating a seamless and hands off way to track asset life cycles from the beginning to the end of its life. While hardware is mostly thought about when mentioning assets, software is also an important asset to track. The software that runs on physical assets is prone to change due to constant software defects and newly found vulnerabilities. Having a means to track and assess these software versions that run on physical assets can help guide proactive patching and upgrades to avoid critical software caveats. Although the business does not actively promote or institute an Enterprise Architecture program, its practices are recommended throughout this process by using reference architectures, The Open Group Architecture Framework (TOGAF) and its Architecture Development Method (ADM), agile scrum of scrum methods and assembling the right people to take a step back and look at the enterprise-wide picture.

Table of Contents

Executive Summary

The Problem

The Vision

Current Architecture Issues

Issue 1: Asset Data Collection and Information Management

Issue 2: Configuration Management Processes and Standards

Issue 3: Lack of Inter-system communication and Data Exchange

Issue 4: Manual End-to-End Asset Provisioning Process

Implementation and Issue Analysis

Issue 1: Asset Data Collection and Information Management

Business Context

Current State

Future State

Future State Requirements

Gap Analysis

Issue 2: Configuration Management Processes and Standards

Business Context

Current State

Future State

Gap Analysis

Future State Requirements

Issue 3: Lack of Inter-system communication and Data Exchange

Business Context

Current State

Future State

Future State Requirements

Gap Analysis

Issue 4: Manual End-to-End Asset Provisioning Process

Business Context

Current State

Future State

Future State Requirements

Gap Analysis

Recommendations

Solving Asset Data Collection and Information Management

Alternatives Analysis

Solving Configuration Management Processes and Standards

Alternatives Analysis

Solving The Lack of Inter-system communication and Data Exchange

Alternatives Analysis

Solving The Manual End-to-End Asset Provisioning Process

Tentative Roadmap of Solution

Closing Thoughts and Next Steps

Appendix

References

The Problem

General asset tracking of hardware and software can be an inundating process in itself, especially when the underlying implementation requires constant manual intervention and lacks the capabilities to easily integrate with other key systems. The definition of what an asset is varies within and between industries, but the International Organization for Standardization (ISO) 55000:2014 Asset Management specification defines an asset as an item, thing or entity that has potential or actual value to an organization (ISOa 2014).

The current asset system implementation is a home grown solution that works, but has a narrow vision in its capabilities, which has created more and more burden as the business has grown. The system is labeled as a Sever Asset Management Data Base (SAMDB), which was its originally intended purpose, to track physical server assets. The capability to add network elements was added a few years ago and included new fields to track the model type, major Operating System (OS) type, Internet Protocol (IP) addresses and other management information. Using Cisco Systems as a vendor example, the only network OS type available as an option in the system is ÒCisco IOSÓ, which provides little value given there are about five different versions of Cisco networking software. This is limiting to be able to sort and report on devices running a certain OS, plus it doesnÕt give detail to the exact software version it is running. Additionally, the SAMDB system does not address the issue of network devices that are modular or chassis based. These devices have several Field Replaceable Units (FRUs) that can be inserted and removed from the device. These FRUs are tracked in the system, but not tied to the device in a relational manner. When a line card or power supply is moved from one device to another, the system has no way to know this happened. The system includes fields that specify the site, rack and rack position of physical assets, but the data entry of these are manual. If a server or network element moves to another rack or datacenter, it has to be updated or the record is essentially invalid.

Due to the current limitations of the SAMDB, there is not an effective way to track the Beginning of Life (BoL), Middle of Life (MoL), and End of Life (EoL) of a hardware element or the software that runs on it. This is essential to gauge the level of paid vendor support that may be needed depending on what stage the asset is. Also, without being able to effectively track when hardware or software support expires, it could lead to situations where replacement parts are no longer obtainable and software that has stopped including bug fixes with no upgrade path. An asset lifecycle system is needed to track all this, but should also provide additional features that can create relational views and functionality to integrate elements of configuration management, software compliance management and automated provisioning.

The Vision

In essence, an IT Asset Life Cycle Management (ITALM) system is envisioned to enhance existing functionality and introduce new capabilities. The system should effectively track hardware assets using wireless technology that allows tracking mobility and the ability automatically update its datacenter and rack location when moved. Software information running on a physical asset, such as OS type and specific version, should be learned though auto-discovery methods using standardized protocols such as the Simple Network Management Protocol (SNMP) or Link Layer Discovery Protocol (LLDP). The ITALM will utilize this information to preform software compliance checks and remediation. Vendor software release notes and upgrade guides can also be tied in here and updated when software versions change. Software bugs and security vulnerabilities should be incorporated into this overall software schema in order to provide an automated and proactive assessment of new risks that could potentially impact a device and services. Device configuration management will also be a capability where configuration templates for specific devices or roles can be used for initial provisioning. Gathering production configurations for backup and historical purposes should be done as well, which will also aid in configuration auditing and remediation when configuration deviation occurs.

The ITALM system would provide a single source of authority for hardware and software assets. These high level  capabilities allow stakeholders such as procurement, logistics, datacenter operations, hosting operations, network operations and security operations to effectively manage the beginning to end lifecycles of hardware and software. Having deeper insight and an overall relational view of these components will help inventory tracking be more accurate and provide less effort in locating equipment. Informed support decisions can also be made towards the middle or end of an asset’s hardware or software lifecycle in terms of Total Cost of Ownership (TCO) and Return On Investment (ROI). This can aid in whether support contracts are missing for a device, need to be renewed or if support is no longer needed. The beginning to end view and automated process of turning a device up down can be reduced from months or weeks, to days or possibly hours. This can lead to exceeding time to market for new services or being able to quickly augment constrained resources. The amount of time saved from the efficiencies of the system, provide additional benefits of being able to tackle priority projects sooner or contribute to further innovation efforts.  Figure 1 in the appendix shows the service goal diagram for this solution.

Current Architecture Issues

An Enterprise Architecture (EA) program is not currently implemented within the company, although one existed a couple of years ago. It was based off a coordination type of business operating model where there is a higher level on system integration as opposed to standardization (Ross et.al 2006, 29). A core diagram of this model is shown in figure 2 in the appendix. System integration is not applied everywhere though based on the present example. Without a dedicated EA team providing company-wide oversight, it is advisable that key business unit stakeholders are involved for this proposed solution and others. Since there are still previous EA architects within the company in other roles along with Agile development practices in daily use, an architecture scrum of scrums would be advisable to discuss the relationships and inter-dependencies of the existing and proposed asset management system. This proposal does not stipulate that a EA program is needed to evaluate the business and IT strategy alignment, but does lean towards a program being re-established. By following some of the EA best practices and frameworks, such as, The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM), it can help provide guiding principles to make each stage of the process as effective as possible.

Issue 1: Asset Data Collection and Information Management

The lack of data fields along with inconsistent data prevents the necessary level of information context that is needed for stakeholders to make knowledgeable and informed decisions; but this also requires a more dynamic and automated collection mechanism rather than relying on human input. 

Issue 2: Configuration Management Processes and Standards

Software and configuration standards are needed to provide stability, consistency and predictability for all platforms along with providing a method to audit and measure compliance.

Issue 3: Lack of Inter-system communication and Data Exchange

Tasks such as assigning IP addresses for devices in the IPAM (IP Address Management) system and creating DNS records are siloed to their individual systems and not synchronized in the SAMDB system.

Issue 4: Manual End-to-End Asset Provisioning Process

The missing elements in the first four issues results in a provisioning process that is very manual and leaves a lot of room for errors, inconsistencies and time sunk into retrieving necessary information from multiple locations.

Implementation and Issue Analysis

Issue 1: Asset Data Collection and Information Management

Business Context

The use of an Asset Information Management (AIM) strategy is a critical component in order to ensure that asset data is acquired in a timely and accurate manner (Ouertani et. al 2008, 32-33).  With a consistent and accurate raw data structure, an information-centric view of assets can be seen and used to gain the appropriate level of knowledge for human or system actors when needing to make manual or automated decisions. The importance of data, information and knowledge in asset management can be viewed from financial and engineering business perspectives. The financial view focuses on cost reduction, reliability, performance, Return On Investment (ROI) and overall asset value; while an engineering viewpoint utilizes data and information to track an asset through its lifecycle in order to make decisions regarding maintenance, asset sweating or reuse (Ouertani et. al 2008, 31). New dynamic methods to capture these asset data need to be investigated rather than relying on manual and error-prone methods currently in use.

Current State

The current asset management system architecture is home grown solution using proprietary vendor software. It utilizes several Microsoft SQL servers running different software versions and has been modified and made more complex over the years to accommodate new requirements and growth as needed. Database backups happen regularly, but the systems involved are not geographically dispersed, and subject to service outage should the main datacenter incur a major power outage, telecommunications failure or natural disaster.

The current SAMDB system utilizes a multitude of data fields to be populated, which are mainly related to physical asset attributes. A majority of these for any given asset have no associated data tied to them due to the irrelevance of that data field to the asset, or it simply being overlooked with nothing entered. The schema does not enforce required fields for everything, so if important asset attributes are not entered in at the time the asset is received by logistics or at any point of the provisioning process, it will likely be forgotten. Data entry is also manual, which takes time to gather the appropriate data if located in multiple locations, and leaves a lot of room for human error. Without consistent data points, information context related to an asset is incomplete will lead to poor and uninformed decision making.

 Future State

A successful ITALM system using an AIM strategy should use standardized practices, protocols and technologies to populate data, provide high availability and data recovery. The ISO 55000:2014, 55001:2014 and 55002:2014 asset management standards are the most up to date foundational reference architectures in use today and should be used for guidance (ISOa 2014). Each specification covers a particular area that should be reviewed and implemented as an organizational-specific architecture. These ISO standards are defined as follows:

  • ISO 55000:2014 –  Overview, principles and terminology
  • ISO 55001:2014 –  Asset management requirements
  •  ISO 55002:2104 –  Asset management guidance and application

Physical asset data collection should look to use Real-Time Location System (RTLS) methods such as active RFID, Product Embedded Information Device (PEID), Near Field Communication (NFC) or Line Of Site (LOS) technology. This will track which data center site, aisle, rack and rack position a physical asset is located. Chassis based assets like servers, routers and switches that utilize Field Replaceable Units (FRUs) such as line cards, server blades and power supplies, should also utilize one of the RTLS methods to track these individual components, while being recognized as a relational component to the parent chassis.

Future State Requirements

Filter Criteria Discriminating Criteria
Automation Capabilities Automatically update inventory site, rack or chassis location as assets are moved
Tracks software lifecycle on servers and network elements Software Bug Tracking

Software Security Advisory Tracking

Tracks hardware lifecycle of servers and network elements Hardware Field Notice Tracking
Compliance Functionality Software Compliance Reporting

Configuration Compliance Reporting

Hardware Compliance Auditing

Hardware Compliance Reporting

Hardware Compliance Remediation

Based on open source technologies and standards LAMP/MEAN Stacks

o   Linux/Node.js

o   Apache/ExpressJS

o   MySQL/MongoDB

o   PHP/AngularJS

Gap Analysis

Current State Future State Actionable Items
Limited fields for software attributes New fields will track specific software versions, bugs and
security vulnerabilities
Confirm field quantity upper limits and ensure solution can
accommodate customized fields
Manual data entry of asset attributes Dynamic asset attribute entry based on asset polling and RTLS capabilities Identify any dynamic update limitations of the solution
Minimal required fields Multiple required fields Identify all required fields, how users are notified and how system reacts when this criteria is not met
No geographical system diversity Geographical diversity using IP anycast for active/active high availability Test that systems closest to the users are always preferred and
that seamless failover happens when a site goes down
Vendor proprietary implementation Open source and standards implementation Services, Applications and protocols  should be validated
as open

Issue 2: Configuration Management Processes and Standards

Business Context

Ross et. al (2006), discuss four stages of architecture maturity as it related to EA, which are:

  • Business Silos
  • Standardized Technology
  • Optimized Core
  • Business Modularity

These define maturity levels that an enterprise can use to compare themselves against. The business silos stage is more of a representation of where the business stands today, so there is some work to do. Standardization is gaining momentum, but will still take years to accomplish. In terms of Configuration Management (CM) of assets, having standardized configurations and software can lead to qualitative benefits of reducing complexity, increased interoperability between the same or different vendors, and more predicable behaviors (Mac Neela 2013). Overall, this reduces operating costs by incurring fewer outages that can result in customer credits and paint a bad public picture of business instability. Additionally, if configurations are standardized and persistent, deployment of new devices and services can be significantly faster. A 2014 ISO study of several companies in different industries around the world was able to relate the quantitative benefits of standardization. One of the key benefits was streamlining internal operations, which found that reducing time to perform tasks and increasing productivity, resulted in profit increases from 0.15% to 5% (ISOb 2014, 9).

Current State

A Configuration Management Data Base (CMDB) system does exist today. It pulls device information from SAMDB to populate devices that can be searched and sorted by vendor, model and role within the network. Device configurations are also backed up on a daily basis, and it can also be used to push changes to devices. Today, this is about the extent of its capability. It does not provide an easy way to search through configuration records, include any kind of software management capabilities, or any auditing and compliance checks. One of the main reasons that compliance and auditing do not occur is the fact that configurations are not standardized. This is the same for software running on assets. Configurations and software versions can vary from device to device. Although efforts have been made to rectify this, it usually proves difficult to implement due to the sheer number of assets and the lack of personnel to dedicate to the effort. As a result, individuals tend to develop their own solutions to assist them in configuring an asset, which compounds the problem and still results in inconsistency.

Future State

The current CM capabilities should be enhanced and be an integrated as part of the new ITALM solution. The Institute of Electrical and Electronics Engineers (IEEE) 828-2012 standard for CM is an example of an industry reference architecture that can be used to follow best practices in this area. In accordance to the IEEE (2012) CM standard, the CM system should:

  • Identify functional component characteristics
  • Control changes of characteristics
  • Track changes of characteristics
  • Perform auditing and compliance status

Based on the ITALM assets, the CM system should be seeded with these entries in order to obtain initial configurations and software states from all assets in the network. This should happen in regular intervals and be compared to current configuration templates and approved software. The system will require initial manual entry of company approved software versions, which can then be used as means to audit what is currently in use on a given asset. Configuration templates will be based on a specific software version due to the fact that configuration attributes can change between software versions. Configurations should be further broken down into modular contexts in order to provide flexibility of building custom configurations and allow reuse. Configuration modularization will allow for specific audits and reports to be ran, while also providing a fast way to update a section of a template. At this point, the system should provide the functionality to update software on any asset and also push the necessary configurations based on that version of software. As configurations change over time, the use of a Concurrent Versions System (CVS) can be used to manually search and report configuration differences, but ideally this would be automated to provide reports of software and configuration non-compliance. The Internet Engineering Task Force (IETF) Network Configuration Protocol (NETCONF) and YANG data model are two particular standards that should be available in the system in order to aid in the configuration of network devices. Relevant and open APIs such as REST should be available as another method of communication for these and other tasks. Standardized protocols like SNMP and LLDP can also be leveraged to aid in the collection of system software, BIOS and firmware information along with other system data that may be relevant to aid in configuration and software compliance.  

Gap Analysis

Current State Future State Actionable Items
No software version tacking capabilities Integrated software version tracking Determine level of effort to add this functionality
Configuration backups Configuration backups None
Difficult to search through configuration records User friendly way to search and correlate data What methods need to be used to make this easier?
Ability to push configurations to assets Ability to push configurations to assets None
No software or configuration auditing capabilities Integrated software and configuration auditing capabilities Requires configuration standardization effort
No ability to modularize configurations Configurations can be modular to support reuse and specific functions Requires configuration standardization effort
No ability to link configuration to software version Configurations can be linked to specific Software versions Requires configuration standardization effort

Determine development effort needed to accomplish this 

Future State Requirements

Filter Criteria Discriminating Criteria
Compliance Functionality Software Compliance Auditing

Software Compliance Remediation

Configuration Compliance Auditing

Configuration Compliance Remediation

Auto-remediation

Uses open source and standard protocols, APIs and  applications REST/JSON

NETCONF

YANG

SNMP

LLDP

Multi-Vendor Configuration
Management
Configuration Backup

Configuration Concurrent Version System (CVS)

Issue 3: Lack of Inter-system communication and Data Exchange

Business Context

The power and potential integration of certain applications or services that could fit in with other critical process may not be immediately realized. As these potential symbiotic relationships go unnoticed, day to day processes continue to be cumbersome and inefficient. This is where EA helps the business. It connects business and IT strategy by identifying and coupling the Business, Application, Information and Infrastructure layers into a holistic enterprise-wide view (Godinez et. al 2010, 26). More specifically, a Service-Oriented Architecture (SOA) may be needed to address these “islands” of services that have little to no interactions with the rest of the business. SOA has many definitions, but in essence:

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.(Sprott and Wilkes 2004)

 SOA has many benefits which include: service re-use, which consumes less development resources; asset wrapping, which allows existing systems to be integrated; service composition, which allows new functions to be developed based on using existing service combinations; and service discovery, which optimizes performance function and cost (The Open Group 2013). 

Current State

The SAMDB creates a lot of inter-dependencies on the data it tracks. Two items in particular are IP addresses and their Domain Naming System (DNS) Fully Qualified Doman Name (FQDN). These are two separate fields in the SAMDB and are very important in asset identification and reachability. When a new asset is being brought into service, it must be assigned an IP address if it will reside and communicate on the network. IP allocation is done using the open source IP Address Management (IPAM) application called IPplan. This is a function specific application that is great at tracking the thousands of IP addresses in use throughout the network. The problem is the lack of integration into SAMDB. As part of the provisioning process, once a provisioner assigns an IP address to an asset, they must enter that address into SAMDB. Once the IP is allocated and entered into SAMDB, the necessary DNS entry needs to be created. This is generally done using a specific web application to create the forward and reverse host entries. The forward DNS entry is then manually added to SAMDB for the asset (e.g. host.domain.com). This is a common task performed daily and shows some of the manual details involved for this particular operation.

The monitoring of assets is done using SNMP, but today, monitoring has no direct tie-in with SAMDB. This too is an extra step in the provisioning process and very important not to miss. Manual notifications must be sent to the monitoring team to add the asset to the system for discovery and monitoring.

Future State

The notion of a provisioner needing to look for an available IP address to assign to a new asset, seems a little outdated. For starters, the IPAM system should have the intelligence built into it so that larger blocks of IP addresses are used and assigned for a specific purpose. These blocks could even be shared depending on the role and service the asset provides. The provisioner should simply have to add an asset’s datacenter location, role and services capability, then automatically get assigned the next appropriate IP address in the pool. Upon IP allocation for a given asset, forward and reverse DNS entries should be created. All this information should be automatically populated in the new ITALM system. Adding a new device to be monitored should also be as simple as clicking a checkbox in the ITALM system to initiate calls to start the monitoring process. Operations can also utilize this to toggle monitoring on and off during planned maintenance to prevent unnecessary alarms from triggering.

Future State Requirements

Filter Criteria Discriminating Criteria
SOA Capability
DNS and IP Assignment Integration IPAM Address Pool Assignments

Automated IP to DNS Entry Creation

Device Monitoring Integration

Gap Analysis

Current State Future State Actionable Items
Manual IP address assignment Automated assignment based on device role Work with software development team to see how this can be done
Manual DNS creation Automated DNS creation when IP address is pulled from pool Work with software development team to see how this can be done
Manual add for device monitoring ITALM automated addition during provisioning Work with software development and monitoring team to identify
this process flow and how it can work

Issue 4: Manual End-to-End Asset Provisioning Process

Business Context

An end-to-end view of any process reveals its true benefits or inefficiencies. This view is rarely analyzed in depth by the
typical individual contributor, as their focus is on their task at hand, then to move on to the next one. Part of an EA programÕs purpose is to see beyond the boundaries of the business unit and establish an IT engagement model that links senior leadership decisions with project priorities, project implementation decisions and process design across the company (Ross et. al 2006, 9). The IT engagement model is the final stage in establishing a foundation for execution that the business can use to achieve its strategic business and IT goals. The model further defines governance mechanisms to promote and guide the right use of IT, including effective project management practices and linking mechanisms that connect projects, stakeholders and decision makers (Ross et. al 2006, 118-119).

Current State

            When a new asset is received by logistics the process begins. Single or multiple asset IDs are assigned depending if the asset is a modular chassis or not. Serial numbers are entered in the SAMDB and the appropriate individual or business unit is notified by a logistics e-mail that the asset has been received. The individual fills out a request within the SAMDB system to add a new device type by providing the serial and the FQDN of the host (See manual IP/FQDN example in issue #3), then the location and operating environment (service) it will be a part of. Once the request is submitted, reviewed and approved by data center operations. The new host record, which includes the original asset information, still requires datacenter aisle, rack and rack positions to be entered. There are many other fields that may pertain to this turn up, which still may require manual entry later in the process. Taking the perspective of a network specific turn up, the asset may have the ability to automatically provision itself once it is attached to the network, but this is dependent on the environment and is not consistent. Providing this ability is not available, the provisioner must manually configure the device to get initial access setup. Once on the network, the provisioner must check what version of software is approved for the specific asset model and role. Software is then upgraded or downgraded in order to bring it up to standard. Since no device configuration templates are available, the provisioner must rely on their own combination of saved configurations, personal home gown tools or simply copy and modify a configuration that is already in use on another device. Once the device is production ready, it is passed to monitoring via e-mail to be setup in three separate systems to start polling the device. The device is finally passed to operations who accepts or rejects the new device based on manual checklist in a MS Word document.

Future State

A new asset is received by logistics and an RFID or multiple RFIDs are recorded and applied to the asset(s) depending on the asset being modular or not. The purchase order is associated with the asset by logistics, which will identify the appropriate individual or business unit responsible for the asset. The active RFIDs are registered and its location (receiving) information is updated in the ITALM system along with automatically notifying the individual or business unit about the newly discovered asset. The provisioner logs into the ITALM system to assign its final destination and role, which automatically assigns an IP, hostname and associated DNS entry. The CMDB system is also notified that a new asset has been discovered and determines by its hostname, what role it serves and acquires the necessary software version and configuration needed in the CMDB system. When the asset is racked and connected to the network, the RFID location information is updated and sent to the provisioner that the asset is in position. When the asset is connected to the network and powered on, it communicates with the CMDB system, receives its IP address originally assigned, then proceeds to update its software to the CMDB provided standard version, then download a complete copy of its preconfigured configuration from the CMDB. When the process completes, the CMDB system connects to the necessary monitoring systems to provide the new asset information. Finally, the CMDB will perform a series of checks to assess operational readiness and pass the report with any caveats to operations for acceptance. Figure 3 in the appendix shows this end-to-end process flow.

  

Future State Requirements

Many of the requirements to achieve this new state, essentially rely on the aforementioned future states solutions to come together. Additional requirements on top of this are listed below.

Filter Criteria

Discriminating Criteria

á       Automated
Process Checklists

á
Service Status Verifications

á
Configuration Verifications

á
Approved OS Verifications

á
Out of Band Access Verifications

á       Notification
Capabilities

Gap Analysis

Current State Future State Actionable Items
No automated notification when assets arrive Notification to individual or group upon receipt of asset Determine if this is a feature of the new solution or if it can
be custom developed or integrate 3rd party applications
No automated notification when assets are racked Notification to individual or group when asset is racked and
ready for provisioning
Determine if this is a feature of the new solution or if it can
be custom developed or integrate 3rd party applications
Auto-provisioning of assets is hit or miss All assets will receive their role based configuration and OS Determine if this is a feature of the new solution or if it can
be custom developed or integrate 3rd party applications
Manual MS Word operational checklist Automated checklists with pass/fail notifications Determine if this is a feature of the new solution or if it can
be custom developed or integrate 3rd party applications

Recommendations

The creation of a new ITALM system will require several key architectural issues to be addressed. These key issues have been analyzed individually above, with individual recommendations below, but they should all build on each other to bring to light the big picture.

Solving Asset Data Collection and Information Management

The current way asset data and information is collected and managed is not sustainable for the future growth and requires several architectural efficiency improvements. As a first step towards improving asset management, The ISO 55000, 55001 and 55002 standards should be reviewed as a foundational reference architecture in conjunction with TOGAF ADM. The ADM will provide a generic guide to align the architecture vision and ISO standards with the business, data and technology architecture phases (A-D) in order to create an organization-specific architecture for asset management. For an RTLS solution, active or powered Ultra High Frequency RFIDs should be used as the primary collection technology due to the fact that these can transmit up to 100 meters and will actively send their data rather than having to be scanned at close proximity (RapidNFC 2012). ServiceNow© is a Commercial Off The Shelf (COTS) solution that provides ITALM services and can already be leveraged since it is already in use for operational incident management (ServcieNow-AM 2014). Data redundancy and high availability of the ServciceNow© system should be reviewed and adjusted as needed as more critical services are added. Key stakeholders, domain architects and business unit managers who are impacted in one way or another by the asset management process should convene to kickoff this process.

Alternatives Analysis

Other asset management standards were looked at including the British Standards Institute Publically Available Specification 55 (BSI PAS 55). Although this internationally recognized standard was the de facto standard since 2004, the ISO 55000 series superseded the BSI PAS specification in 2014, but still uses many of its principles (Wikipedia 2015). Due to this transition, BSI PAS 55 was not considered. RTLS alternatives such as, NFC or PEID were not chosen based on distance limitations of NFC and PEIDs being more complex and costly in their setup as opposed to RFID. Other COTS ITAM solutions were investigated along with even doing inÐhouse development, but since ServiceNow© already has the needed capabilities along with the ability to be customized, spending additional capital and operational expenditures seems wasteful. 

Solving Configuration Management Processes and Standards

Similar to asset management, CM standards are also well known with many variants. The American National Standards Institute/Electronics Industries Alliance 649B (ANSI/EIA-649B) standard has been around since 1998 and recently updated in 2011. Its maturity and widespread adoption makes it a well suited candidate as a foundation or possibly industry specific reference architecture that can be molded into an organizational-specific CM architecture. The current ServiceNow© implementation also has built-in CMDB capabilities that should be used (ServcieNow-CMDB 2015). As with the asset management solution above, leveraging capabilities and systems that already exist is highly recommended and should be the first course of action rather than other COTS solutions or in-house development. The ITALM and CM efforts should be tightly coupled due to their dependencies on using ServiceNow©.

Alternatives Analysis

The IEEE 828-2012 is a slightly newer CM standard that was adopted in 2012. Even though this was considered initially, the ANSI/EIA standard has been tried and tested and is only a year behind in an update opposed to the IEEE 828 standard. This doesnÕt necessary exclude the IEEE 828 from being consulted and use its best practices in conjunction with the ANSI/EIA standard.

The HP Universal CMDB© is a viable alternative to consider as well and should be investigated at a high level for comparison in the event that ServiceNow© has undiscovered shortcomings that cannot be resolved in a short timeframe. The level of effort around an in-house solution should also be analyzed as a potential alternative.  

Solving The Lack of Inter-system communication and Data Exchange

IPAM, DNS, and monitoring systems all need to have integration into the overall ITALM solution and need to introduce automation to eliminate wasting employee time on simple tasks that should not have to be thought about. The software development team can tackle this today for solution that can be tailored to both the existing SAMDB and future ITALM systems. Additional systems and services that may relate to to the current SAMDB, CMDB and future ITALM system for any given asset, regardless of its life cycle stage, should be investigated. A clear understanding of all the application and service dependencies will be very important to make sure asset life cycle processes flow seamlessly. A SOA solution or more specifically, a Web-Oriented Architecture that extends the SOA strategy and utilizes web-based services should be a priority and even pursued for other processes that potentially suffer from the same levels of inefficiency. As services and capabilities are identified manually or through service discovery, they can be re-used by any larger scoped application that may require them. Moving to an SOA/WOA solution can be a big step that will require senior leadership and business unit involvement throughout the company to determine the level of readiness.

Alternatives Analysis

The use of Application Programming Interfaces (APIs) could be used instead of an SOA solution to facilitate the transfer of data between applications. Although this works and is done today with many applications, it limits re-use and automatic discovery that SOA can provide and must be manually setup between applications as they are needed, which is definitely more time consuming and resource intensive.

Solving The Manual End-to-End Asset Provisioning Process

The high level view of the proposed ITALM solution puts the end-to-end process in perspective. Figure 4 in the appendix shows a visual representation of this solution concept. By instituting solutions to the previous issues, an end-to-end provisioning process solution almost falls into place on its own. The last solution here is the formalization of the process to show how the business objectives are met using the aforementioned IT solutions. Inter-business unit input, cooperation and communication will be needed to solidify the solution, document it, provide training and put the process into production. An alternatives analysis was not performed for this item as this is really an all or nothing change and dependent on the previous solutions to truly implement.

 Tentative Roadmap of Solution

The following roadmap can serve as a guide for how the ITALM/CM process may look like from beginning to end. Most of timelines will follow sequential execution, but this may not always be the case for technical and feasibility reviews of platforms, standards or testing, which may be able run in parallel or even overlap with one another. The estimated worst case scenario of implementation time will be 65 weeks, with 37 being the best case. Figure 5 in the appendix displays a proposed actor/role matrix to help with this as well.

Timeline

Task(s)

Stakeholder(s)

Action(s)

2 weeks

á       Supervisor
approval of initiative

á       VP
Network Engineering

á       Submit
EA report to immediate supervisor for buy-in

4 weeks

á       Cross-organizational
and SLT approval of initiative

á       BU
VPs

á       CIO/CTO

á       CEO

á       Submit
EA report to CIO, CTO, CIO and BU stakeholders that will potentially be
involved in this initiative for buy-in

6 weeks

á       ITALM
Weekly Kickoff Meetings

á       BU
Participation

o   Network Engineering

o   Datacenter

o   Security

o   Program
Management

o   Procurement

á       BU
Stakeholders

o   VPs

o   Managers/Directors

o   Domain
Architects

o   Sr. domain
employees

o   Ex Enterprise
Architects

á       Present
problem to be solved, proposed solution and address gaps

á
Participant input, ideas, changes

á       Individual/Group
task and owner identification

á
Identify scrum of scrum participants

8Ð16 weeks

á       Review
ISO 55000 and ANSI/EIA 649B standards (Scrum of Scrums)

á       SOA
feasibility review

á
Domain Architects

á       Ex
Enterprise Architects

á       ISO/ANSI
Reference Architectures (RAs) need to be reviewed for requirements, guiding
principles and implementation guidelines for ITALM and CM

á       Document
ISO/ANSI RA interpretation and its application to the business as a whole

á       Discuss
and document SOA business and IT strategy

á       Discuss
and document end-to-end ITALM/CM process

4-10 weeks

á       ServiceNow©
ITALM/CM capability review and testing

á       RFID
system vendor capability reviews and testing

á       Identified
task owners

á       Domain
Architects

á       Review
technical and business requirements with vendors and identify any new gaps
that may need to be addressed

á       Perform
vendor Proof of Concept (POC) testing

á       Documentation

2-8 weeks

á       External
application/ service automation with ITALM/CM

á
Identified task owners

á       Identify,
test and implement  solutions to automate DNS, IP address assignment and
monitoring within ITALM process

6-10 weeks

á       RFID
system deployments

á
Identified task owners

á       Global
deployment of new RFID system should be deployed and tested

á       System
should be integrated into a ITALM/CM prototype for user testing

2-4 weeks

á       ITALM/CM
prototype tests

á
Identified task owners

á       Test
initial prototype for functional requirements, bugs and any unforeseen
process  gaps

2-4 weeks

á       Identify
focus groups to begin preliminary user trials

á       Identified
task owners

á       BU
ITALM/CM users

á       Small
focus groups from each BU that will use the ITALM/CM solution should begin
using the system for a small set of new assets

á       The
new ITALM/CM system should also mirror new asset entries to the legacy system
to ensure data consistency in the event the new system fails

3 weeks

á       User
training

á       HR
Training and Development

á       Company-wide
training should be started to ensure users are proficient with the new system

Go Live

á       Implement
new ITALM/CM system

á
Identified task owners

á       About
2 days after training, the system should go live.

á       Data
mirroring from the new to the old system should remain in place for a period
of 2 weeks then shut off and old system decommissioned

 

Closing Thoughts and Next Steps

Implementing a new ITALM/CM system will have a tremendous impact in how operations and engineering groups get their work done; or rather, the system will do work that they no longer need to worry about. Provisioning tasks that took weeks or months to complete, can now be done in hours or days. Manual auditing data center racks to ensure asset records are up to date will be a thing of the past. Software and configurations for all assets will be easily tracked, updated and kept in compliance through audits and even have the option to be automatically remediated. Vendor bugs, vulnerabilities and field notices that can affect the availability of the network and the services that run across it, can now be easily tracked, and correlated to affected systems and remediated via patches, policies changes or code upgrades, that are coordinated and performed from the CMDB system. All of these are possible if management and the business culture are ready to support it. Even without an EA program in place, frameworks, best practices, collaborative and effective communication can still achieve business and IT alignment when needed. That said, in order to continue efforts like this and move the business away from a siloed maturity phase, there needs to be more emphasis on a dedicated team to provide a holistic view of the IT and business landscape. Whether or not this team uses the term “Enterprise Architecture”, the discipline and momentum towards standardized technology and automation that this team could provide, would mean nothing but great things for the business.

          

Appendix

 

Figure 1.

Service Goal Diagram

 Service Goal Diagram

 

Figure 2.

Current Business Core Diagram

Current Business Core Diagram

 

Figure 3.

ITALM/CM Process Flow Diagram

 ITALM/CM Process Flow Diagram 

 

Figure 4.

Solution Concept  Diagram

Solution Concept Diagram

Figure 5.

Actor/Role Matrix

Actor Role Matrix

References

Godinez, Mario, Eberhard Hechler, Klaus Koenig, Steve Lockwood, Martin Oberhofer, and Michael Schroeck. 2010. The Art of Enterprise Information Architecture. Upper Saddle River: IBM Press.

 

IEEE. 2012. IEEE Standard for Configuration Management in Systems and Software Engineering. IEEE Xplore: 1-71. Accessed March 3, 2016. http:dx.doi.org/10.1109/IEEESTD.2012.6170935.

 

ISOa. 2014. ÒAsset management system standards published.Ó ISO News. Accessed March 4, 2016. http://www.iso.org/iso/home/news_index/news_archive/news.htm?refid=Ref1813.

 

ISOb. 2014. ÒEconomic benefits of standards.Ó Accessed March 5, 2016. http://www.iso.org/iso/ebs_case_studies_factsheets.pdf.

 

Mac Neela, Alan. 2013. ÒWhen Does Standardization Make Sense?Ó Alan Mac Neela’s Blog. Forrester. Accessed March 3, 2016. http://blogs.forrester.com/alan_mac_neela/13-01-28-when_does_standardization_make_sense.

 

Ouertani, Mohamed Zied, and Ajith Kumar Parlikad, and Duncan McFarlane. 2008. ÒTowards An Approach To Select An Asset Information Management Strategy.Ó International Journal of Computer Science Applications 5, no. 3b (March): 25-44. Accessed March 4, 2016. https://www.researchgate.net/profile/Ajith_Kumar_Parlikad/publication/26621987_Towards_an_approach_to_Select_an_Asset_Information_Management_Strategy/links/02e7e51a7bc1f0a0b1000000.pdf.

 

RapidNFC. 2013. ÒThe Difference Between NFC and RFID Ð Explained.Ó Accessed March 5, 2016. https://rapidnfc.com/blog/72/the_difference_between_nfc_and_rfid_explained.

 

Ross, Jeanne W., Peter Weill, and David C. Robertson. 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard University Press.

 

ServiceNow-AM. 2014. ÒServiceNow Asset Management.Ó Accessed March 2, 2016. https://www.servicenow.com/content/dam/servicenow/documents/datasheets/ds-asset-20120927.pdf.

 

ServiceNow-CM. 2015. ÒServiceNow Configuration Management DatabaseÓ Accessed March 2, 2016. https://www.servicenow.com/content/dam/servicenow/documents/datasheets/ds-configuration-management.pdf.

 

Sprott, David, and Lawrence Wilkes. 2004. ÒUnderstanding Service-Oriented ArchitectureÓ. CBDI Forum. Accessed March 3, 2016. http://msdn2.microsoft.com/en-us/library/aa480021.aspx.

 

The Open Group. 2013. ÒService Oriented Architecture: SOA Features and Benefits.Ó Accessed March 5, 2016. https://www.opengroup.org/soa/source-book/soa/soa_features.htm.

 

Wikipedia. 2015. ÒISO 55000Ó. WikiMedia Foundation, Inc. Last Modified February 20, 2015. Accessed March 5, 2016. https://en.wikipedia.org/wiki/ISO_55000.

Leave a Reply

Login

Share This