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 |
|
|
|
|
|
|
|
|
|
|
Gap Analysis
| Current State | Future State | Actionable Items |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Future State Requirements
| Filter Criteria | Discriminating Criteria |
|
|
|
|
|
|
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 |
|
|
|
|
|
Gap Analysis
| Current State | Future State | Actionable Items |
|
|
|
|
|
|
|
|
|
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 |
|
|
|
Gap Analysis
| Current State | Future State | Actionable Items |
|
|
|
|
|
|
|
|
|
|
|
|
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 |
|
|
|
| 4 weeks |
|
|
|
| 6 weeks |
|
|
|
| 8-16 weeks |
|
|
|
| 4-10 weeks |
|
|
|
| 2-8 weeks |
|
|
|
| 6-10 weeks |
|
|
|
| 2-4 weeks |
|
|
|
| 2-4 weeks |
|
|
|
| 3 weeks |
|
|
|
| Go Live |
|
|
|
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
Figure 2.
Current Business Core Diagram
Figure 3.
ITALM/CM Process Flow Diagram
Figure 4.
Solution Concept Diagram
Figure 5.
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. www.dx.doi.org/10.1109/IEEESTD.2012.6170935.
ISOa. 2014. ÒAsset management system standards published.Ó ISO News. Accessed March 4, 2016. www.iso.org/iso/home/news_index/news_archive/news.htm?refid=Ref1813.
ISOb. 2014. ÒEconomic benefits of standards.Ó Accessed March 5, 2016. 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. www.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. 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. www.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. www.servicenow.com/content/dam/servicenow/documents/datasheets/ds-asset-20120927.pdf.
ServiceNow-CM. 2015. ÒServiceNow Configuration Management DatabaseÓ Accessed March 2, 2016. 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. www.msdn2.microsoft.com/en-us/library/aa480021.aspx.
The Open Group. 2013. ÒService Oriented Architecture: SOA Features and Benefits.Ó Accessed March 5, 2016. 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. www.en.wikipedia.org/wiki/ISO_55000.
