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……………………………………………………………………………………………………………….. i

The Problem……………………………………………………………………………………………………………………….. 2

The Vision………………………………………………………………………………………………………………………….. 3

Current Architecture Issues……………………………………………………………………………………………………… 5

Issue 1: Asset Data Collection and Information Management…………………………………………………. 5

Issue 2: Configuration Management Processes and Standards………………………………………………… 6

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

Issue 4: Manual End-to-End Asset Provisioning Process…………………………………………………………. 6

Implementation and Issue Analysis…………………………………………………………………………………………….. 6

Issue 1: Asset Data Collection and Information Management…………………………………………………. 6

Business Context……………………………………………………………………………………………………….. 6

Current State…………………………………………………………………………………………………………….. 7

Future State……………………………………………………………………………………………………………… 8

Future State Requirements………………………………………………………………………………………….. 8

Gap Analysis……………………………………………………………………………………………………………… 9

Issue 2: Configuration Management Processes and Standards………………………………………………… 9

Business Context……………………………………………………………………………………………………….. 9

Current State…………………………………………………………………………………………………………… 10

Future State……………………………………………………………………………………………………………. 11

Gap Analysis……………………………………………………………………………………………………………. 12

Future State Requirements………………………………………………………………………………………… 13

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

Business Context……………………………………………………………………………………………………… 13

Current State…………………………………………………………………………………………………………… 14

Future State……………………………………………………………………………………………………………. 15

Future State Requirements………………………………………………………………………………………… 15

Gap Analysis……………………………………………………………………………………………………………. 16

Issue 4: Manual End-to-End Asset Provisioning Process……………………………………………………….. 16

Business Context……………………………………………………………………………………………………… 16

Current State…………………………………………………………………………………………………………… 17

Future State……………………………………………………………………………………………………………. 18

Future State Requirements…………………………………………………………………………………….. 19

Gap Analysis……………………………………………………………………………………………………………. 19

Recommendations……………………………………………………………………………………………………………. 20

Solving Asset Data Collection and Information Management……………………………………………….. 20

Alternatives Analysis…………………………………………………………………………………………….. 21

Solving Configuration Management Processes and Standards……………………………………………….. 21

Alternatives Analysis…………………………………………………………………………………………….. 22

Solving The Lack of Inter-system communication and Data
Exchange……………………………………… 22

Alternatives Analysis…………………………………………………………………………………………….. 23

Solving The Manual End-to-End Asset Provisioning Process………………………………………………….. 23

Tentative Roadmap of Solution………………………………………………………………………………………………… 23

Closing Thoughts and Next Steps………………………………………………………………………………………………. 25

Appendix………………………………………………………………………………………………………………………. 27

References……………………………………………………………………………………………………………………. 32

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

á
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 maintenances 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