The Case for IT Asset Engineering, Presented to the 15th Annual IAITAM ACE

By Steven Ligon

Steven R. Ligon, Ph.D.; Brian S. Wallace

This paper addresses the need for Systems Engineering focused on the issues falling between IT Asset Management and IT Service Management, identify touch points between the engineering discipline as represented in the Systems Engineering “Vee” and the products necessary to deliver superior service and comprehensive management of IT Assets in any organization.

At a recent discussion about the Software Asset Management (SAM) discipline one member observed “Many see the job of the Software Asset Manager as principally clerical, tracking the inventory of the organization, with little or no technical expertise required.” But we have found that if the SAM office is to truly save money, they need to have the technical expertise to counter those who demand the latest shiny object and the financial acumen to understand the short and long term benefits and costs of an acquisition versus the value of maintaining or de-provisioning applications currently in use.

It is our contention that application of good Systems Engineering practices can and do increase the value of the SAM office to the organization.

So what is Systems Engineering? At the root level, it is a process for producing integrated systems (International Council of Systems Engineers (INCOSE) Definition). It does this by ensuring the product being put together will in the end meet the objectives of the business or government office.

There are two other definitions essential to this discussion, IT Asset Management (ITAM) and IT Service Management (ITSM). According to the International Association of IT Asset Managers (IAITAM), ITAM is a set of best practices “maximizing benefits while minimizing risk concerning all IT assets in the organization. And according to IT Service Information Library (ITIL), ITSM is a set of specialized organizational capabilities providing value in the form of IT services.

Our proposition is that what we label “IT Asset Engineering” is Systems Engineering focused on interfacing ITAM and ITSM, thereby adding value to both disciplines. For while IT Asset Managers need to focus on the cost/benefit value of acquiring/maintaining assets, and IT Service Managers focus on delivering the most cost effective service, IT Asset Engineers bring systems engineering skills coupled with the financial management expertise to best determine the feasibility of the new acquisition, the total cost of ownership (TCO), validate return on investment (ROI) assumptions, and the engineering exactness to establish quantitative measures of effectiveness.

The System Engineering “Vee”

If you go on line and google “Systems Engineering “Vee” Diagram”, you get over 152,000 responses. While you will be relieved to know I am not going to show you all of them, it is a tribute to the heuristic that it is applied to so many disciplines, both in and out of engineering. Figure 1 is an amalgamation of several Systems Engineering “Vees” which we will use to illustrate touch points for IT Asset Engineering in Software, Hardware and Mobile Asset Management.

The universe in which It Asset Managers work we’ll call the Regional Architecture. This is the organization’s IT architecture which demonstrates all the moving parts and how they work together. It is important to establish this first to ensure that we understand the constraints in which we work. From examination of this architecture, certain gaps, absences and excesses appear from time to time raising the question, “How can we do this better?” And trying to answer that question begins the journey that we all undertake to deliver the most efficient infrastructure for the least cost to our organizations.

Figure 1: The Systems Engineering “Vee”

So, is bettering this capability feasible? What are the possible solutions? In this investigation, we evolve a concept of how this new or improved capability will work (aka Concept of Operations). Next, we begin to identify what the system MUST do — its requirements — and derive system requirements to classify what is critical and what is just “nice to have”. The “Vee’s” evolution is to derive high level designs from System Requirements, then detailed designs and only then, beginning to develop. While many engineers like to forego all these steps and rush to development in the first meeting, we know that such practice wastes lots of time and expense. Knowing where you are headed is always a good idea prior to backing out of your driveway.

As we move up the right side of the “Vee”, development builds from the components to the integrated system, testing occurs first at the sub system, and then we validate those sub systems. At some point we start validating the system against the overall requirements, continuing to test as the system moves to the operational floor. At this point we validate that we are meeting the concept of operations.
Once the system is deployed, we progress into the operations and maintenance phase, and bugs collected along the way are exterminated, at least that is the concept. Changes and upgrades are integrated through the system lifecycle, and eventually the system is retired or replaced.

Today there are many exciting concepts: DevOps, Agile, SAFe Agile, etc.; but these are beyond the scope of this paper. For this paper, the authors accept that a variation of the left side of the “Vee” naturally occurs in good development, the differences being in the size of the development effort being undertaken. Again, for this paper, we will use this Vee to illustrate where IT Asset Engineers can interface with the process, increasing the value of IT Asset Management to the organization.
A couple other observations; first, the left side of the “Vee” decomposes the system down to its component parts, the right side builds the components into the desired IT solution.

Secondly, as illustrated in Figure 2 the stages down the left side inform the parallel stages on the right. So, detailed design provides the test plans for the unit or device testing, or in software development, the code tests. The High-Level design provides the test plan for the Sub system validation, while the System Requirements inform those involved in system verification and deployment planning on what fits where. Lastly the concept of operations is the litmus test for system success.

Figure 2: Decomposition, Composition, and Validation

Software Asset Engineering

First, we’ll look at Software Asset Engineering. We consider ourselves Software Asset Engineers. Our team looked at what we were doing for our federal Agency’s SAM office and overlaid our activities on this “Vee” to see where we could contribute most value to those building the intelligence systems that we use, analyzing the intelligence we gain, and purveying their findings.

When we had finished this analysis, we were surprised to see that we interfaced with almost every step of the “Vee”. Just imagine, if you could deliver value for your organization at each step of the IT lifecycle, how much easier it would be to establish your value added, gain champions, and really make a difference. Now let’s look at these steps.

Figure 3: The Software Asset Management “Vee”

As we mentioned, in the Regional Architecture phase, your approved software catalog is a major constraint. Especially in our domain where we have numerous security checks prior to moving into operations, compounded with sometimes lengthy acquisition chains, it is always easier, more expeditious, and predictable to use software that is already approved for use in the organization. As the SAM organization however, you need to be in tune with what is happening technology wise. This is where your Software Asset Engineer comes in, examining what is happening in the software business, grappling with moving to the cloud, and interfacing with project managers early in their cycle to allow expansion of the product catalog in advance of the need, an imperative with Agile and DevOps development models of product building.

If the SAM office can keep the product catalog up to date with the requirements of products that are being requested, and aggregate those requirements into acquisition bundles, the savings begin to grow because the developers know there is probably a product sufficient to build their systems and that those products can be provisioned rapidly when needed.

When Software Asset Engineers are plugged into the projects as Subject Matter Experts, they can recommend feasible alternatives to the project leads during the design phase. In practice this is not always doable, especially in the Agile world, but in large systems, the Software Asset Engineer can be the one to gently guide from the proverbial sports car to a more practical solution.

Software Asset Engineers review programmatic CONOPS to keep abreast of what applications might be needed in the future, then research where new capabilities are being developed, and to enter discussions with other programs on what capabilities already exist within the organization that can be leveraged at lower cost. For example, one program developing a “new” capability may in fact be duplicating a capability that already exists. Or a part of the organization, unaware of what is going on elsewhere, is pursuing a software solution that will put two similar tools into your inventory. Again, aggregating requirements from ongoing projects can focus the software asset managers on a bulk acquisition with sufficient anticipation to achieve contract award before the need. This also can avoid wasteful duplication of purchases when Software Asset Engineers identify these situations and work with Asset Managers and developers so the organization orders exactly what it requires. A good example of this was a recent case where we identified a new software requirement that was in fact already being provisioned by a license server with low usage. The spare capacity easily accommodated the requirements of the requesting organization and saved the Agency thousands of dollars.

Software Asset Engineering reviews Requests for Change when standing up new systems, and change requests for modifying existing systems in order to identify software requirements. It is quite common for developers to fall into the trap of thinking that the hardware comes with the software already installed, erroneously believing that software in the inventory has been there so long that there must be something newer (and usually costlier), “better” and faster out there, or picking a well-known software tool that delivers no additional capability beyond what the organization’s current software holdings already offer. For project managers trying to stay on schedule and within budget, knowledge of alternatives that cost less or that are already on the shelf can guide the solutions towards a more cost-effective solution.

As system requirements begin to flow into high-level design, the distribution of those requirements to different sub systems will become apparent and often reveal unanticipated software asset needs that were not originally identified. This is where a thorough knowledge of the technical capabilities of the software in the product catalog becomes extremely valuable to the project team, and increasing that linkage will prove valuable and a means of cutting expenses by not introducing new, duplicative functioning software into the inventory by steering the project to reuse software on the shelf, and taking advantage of bulk buy contracts already in place.

Additionally, these cost avoidance actions add value to the SAM office in general, and highlight the reality the SAM office is more than just an office to order and count the software inventory. As you already know, the SAM office can always use more allies.

As detailed design gets underway, SAM is working on ensuring the developers have identified the right version of the required software, that the program understands the impacts of change (cost and schedule), licensing alternatives to drive down costs are available, and most importantly, THEY ARE GETTING THE RIGHT PART NUMBER for the required software.

At the Agency we serve, during the development and fielding of new systems and tools, Software Asset Engineering is liaising with the Infrastructure and Application Service Providers to ensure the right product is installed in the correct domain for the developer and Program to use.

The next two levels of testing and subsystem validation are not generally interfaced with the SAM office with a couple of notable exceptions:

  1. If we are bringing a software asset management tool into SAM’s software suite, then we could easily turn the entire “Vee” red! SAM engineers were integrally involved in surveying the environment, identifying the CONOPS for our license & compliance tool, establishing integration requirements and license constraints, negotiating the acquisition of the COTS product, and testing and validating the subsystems against the stated requirements. In the case of a home-grown software request workflow tracking tool, being developed using agile methodologies, Software Asset Engineers have been constantly involved in not just the capability definition/collection/ vetting/ validation/ prioritization, but all sprint testing and release validations along the way.
  2. The second area where Software Asset Engineers become involved is when the testing process is interrupted by licensing issues which burden the project with constraints that are not surmountable. In those cases, software asset engineers document the technical hurdles imposed by the constraints and providing that to the managers and contract negotiators to gain resolution in consultation with the product vendors.

When systems are deployed, SAM works with vendor changes, software maintenance contracts and the like. Software Asset Engineers ensure the software product catalog is kept reasonably up to date, and that the suite of SAM tools is current and capable of providing the requesting organizations with the software they require.

Software Asset Engineers do however monitor the processes and have been integral in the setup of the base processes for the office and for subsequent reengineering of the processes as new tools have been brought on line. Currently we are involved in evaluating software moving to the Intelligence Community’s Commercial Cloud System (C2S) and GovCloud private domains. Initially, prior to Software Asset Engineering’s integration into the process, it was thought that migration to the cloud would be a simple “lift and shift” of the data center applications into the cloud. However, our engineers were quick to establish the legal license and technical constraints on some of the applications such as highlighting the different entitlements to work on premise as opposed to in the cloud. These exceptions have required in some instances, negotiations with vendors, re-pricing existing contracts, altering product in the inventory, and in some cases contract termination. However, Software Asset Engineering activities have helped avoid potentially catastrophic transitions while mitigating potential Intellectual Property violations. Through small modifications, these transitions are now taking place, and Software Asset Engineering is beginning to have a greater impact.

Throughout the lifecycle, Software Asset Engineering is involved in evaluating the changes that are being made with respect to the overall inventory of the Agency. Additionally, as application contracts come up for renewal, software asset engineering may be involved in determining if there is adequate use of the tools to justify continuation of the contracts, or if the Service-level Agreements of the vendors need modification. Recommendations to decrease or increase inventory, or even modify portfolios are made by the Software Asset Engineers.

Software Asset Engineers routinely take measures of the request-acquisition-provisioning cycle by identifying bottlenecks. This effort results in actions that provide efficiencies by tweaking the current processes and workflows. Additional metrics can identify software that is routinely slow to provision, external actors that impede processes, and many other process improvements.

The harvesting and disposition of licenses from retiring systems is accomplished by the software and hardware Asset Managers working as a team. Software Asset Managers know license constraints that impact the reuse of software such as when inventory adjustments can be made, the cost of maintenance reinstatement, and the volume of requests for the software becoming available from the retiring equipment. Ideally, they know the applications that are on the equipment being retired.

Hardware Asset Managers know the cost impact of maintaining aging systems, the capability and capacity constraints of these systems, and the rising demands for newer and alternative equipment in the organization.

As identified earlier in the briefing, Software Asset Engineering sits in the middle of the interface between ITIL and ITAM, building confidence and positive collaboration between both service and asset management camps. Without the cooperation between these service and asset managers, the task of accurately tracking and harvesting software from the retiring systems and related equipment becomes exponentially more complicated. Software Asset Engineering, with its balance of technical understanding and software license constraints is ideally situated to provide that interface. Figure 4 illustrates the contribution of Software Asset Engineering to an organization building systems.

Figure 4: Software Engineering Contributions to the Organization

Hardware Asset Engineering

From a Hardware Asset Manager perspective, we can say many of the same things as we did about Software Asset Managers. Figure 5 highlights where Hardware Asset Engineering applies to this section.
An approved hardware catalog should usually bound change considerations so long as mission business needs are met. That capability analysis will point out gaps which can be met with a feasibility analysis during feasibility/Concept Exploitation. Much like Software Asset Managers, Hardware Asset Managers should be reviewing CONOPS generated from the previous stage to get ahead of where things are headed. Certainly, in our Agency, the movement to the C2S cloud has trumpeted to our hardware asset managers that heavy investment in a new data center may not be the best investment at the current time.

But unlike the Software Asset Manager, Hardware Asset Managers are usually involved in the Unit/Device Testing, Subsystem validation, System Integration, and System Validation much more that their software counterparts as they provide hardware to facilitate integration with networks and clouds. So for the purposes of this discussion, we will focus on various aspects of Hardware Asset Management distinct from Software Asset Engineering, and illustrate where the touch points are along the “Vee”.

Figure 5: Hardware Asset Engineering Contributions

When we address hardware asset engineering, we interface with every level of the “Vee”. To begin, let’s visit the last part of the “Vee” that was just addressed from the hardware point of view; retirement, replacement, or re-purposing of the hardware after the software is re-captured.

Examination of the company’s workforce computer requirements and hardware at this point presents an opportunity to possibly re-purpose some systems to support alternative company functions. If the hardware is determined to not provide continuing support to the organization, then the process of proper disposal starts here. Valuable training received from CMAM, CITAD, and CHAMP certifications should be applied to the proper disposal of equipment and possible cash flow from the process. Proper handling of the hardware that is no longer able to support the mission of the organization is important not just to see some monetary return but to avoid possible unexpected and large negative monetary ramifications if proper and legal disposal is not executed. Special attention may be required if the organizations has leased equipment. The conditions of the leased equipment are specified and need to be followed so long as the hardware is not mistakenly re-cycled.

Hardware and Software asset management are undeniably connected and are required to work together to provide the customer with a device that can deliver the required need for that individual in the organization. After the CONOPs is reviewed next step on the “Vee” is system requirements, a realistic view of what level of hardware is needed to support the software system requirements is important to ensure the equipment delivered to the user in the organization will be an aid in the performance of the user’s job.

Here we can revisit the need to resist the temptation to immediately go to a newer, faster or “shinier” hardware without a realistic requirement that would justify the change. In a past, we purchased a laptop that had a much higher cost that the current company baseline for an executive because it was smaller and would fit in a purse.

Preference should not be the sole determinate of hardware asset purchases. Justification of the hardware should come from a collective organizational decision. Because of this connectedness, software can and will affect, if not drive, hardware requirements, especially in consideration of moving from a server based data center to a cloud structure with its unique structures of management.

Successful Hardware Asset Management and Hardware Asset Engineering need to be proactive, trying to stay ahead of the game instead of just reacting. While initial application of asset management tends to be more reactionary as it gets established, over time Hardware Asset Engineers can add great value to the organization helping it get ahead of the game by identifying organizational and technology trends.

For Example, Mr. Wallace once managed and provided all IT for a company that owned four small cruise ships. Understanding both the harsh environment of the sea and the hardware required for safety of navigation and ships operations provided his company with some unique perspectives. Special considerations were made when establishing the refresh cycle of hardware in harsh or remote settings where repairs and maintenance are more difficult. He noticed the way that one piece of hardware was regularly used by multiple personnel increasing wear as opposed to other equipment used by only one person and thereby instituted a cycle where the former hardware was refreshed at a more frequent (2 Years) rate that the latter. This significantly decreased the amount of hardware issues while the ships were at sea far away from any repair facility. Additionally, loading software upgrades on newer hardware was faster and the software operated more efficiently on newer hardware. This was vitally important given the time-constrained situation of a planned ship dry-dock. The newer hardware loaded updates and software faster (software driving hardware) which facilitated completing all the needed changes and updates while the ships were in the yards. Risk was lowered and performance was improved by tailoring refresh cycles to the environment the hardware used in.

Too often, lack of coordination between hardware and software management results in inadequate hardware capabilities to support newly stated software functionality requirements. Some of us have experienced hardware that is barely able to run an upgraded operating system. New software can also drive the need for more storage, memory, or graphic demands. Yet Total Cost of Ownership (TCO) and Return on Investment (ROI) generally will not support overbuying hardware capability and support. Collaboration with the software design and hardware requirements through the High-Level and Detailed Design phases can avoid these situations and facilitate successful realization of the organization’s goals. This also applies beyond the initial standup of the system and includes updating of the network, system and the software that interface with that system. Making sure the hardware has all the needed interfaces, memory, storage, processor and video resources are a good start toward meeting the planned software requirements.

Hardware Asset Engineers can also influence hardware selection during system and detailed design. Convincing a user of their “needs” vs their “wants” can be a difficult, especially when dealing with some C-Level Positions (e.g., CFO, CIO, CEO). Yet it is much easier to do so when in the design of a system when hardware asset managers can demonstrate lower cost alternatives that will meet the stated requirements for the system. The bottom line is that communications is a constant and ongoing requirement throughout the process, especially when those decisions will affect a user. Effective communication will also increase the level of cooperation during hardware changes. Interestingly, while financially changing out hardware may seem costlier, that is not necessarily the case. And when considering change, users are generally more averse to software than hardware change. A careful balance needs to be maintained in managing change in the IT environment.

Industry best practice suggests that maintenance costs can be drastically reduced by simplifying the hardware mix and down-selecting to fewer standards in the hardware asset catalog. This requires the use of the left side of the Vee to assess what the standards should be, and then modifying the hardware asset catalog to support that. It is important to try to limit the amount of workstation and hardware standards to simplify the ability of the organization to manage, supply, track, and operate.

Then there is the matter of tracking hardware that is in the system. Configuration Management Databases (CMDBs) must be selected that automate wherever possible the tagging, installation, removal, and disposition of hardware assets. Successful implementation of an appropriate tagging system is an important part of the asset management process as equipment is received and as the system standards are established. Many models of acquisition and maintenance are available, but key to any model’s implementation is selecting the best software tool that tracks both software and hardware asset status. Hardware Asset Managers can aid in ensuring that business as well as service needs are met in implementing that CMDB. All asset management tools need some level of customization, manual configuration to align COTs assumptions with operational reality, and will not provide an immediate source of complete software and hardware information until they have a good reach into your organization’s hardware network or networks and can discover the software installed on them. Implementation of these tools (CMDBs, IT Asset Repositories) take time to collect information on the organization’s full array of assets. Our current organization has multiple networks and locations that make full discovery of the software and hardware difficult. With proper management of expectations among the staff and attention to the configuration of the tools, trust in your Asset Management toolkit and the data in those tools, and the accuracy of the data collection by those tools will increase. This will bring a commensurate increase in the credibility and importance of Asset Management in the organization.

As asset inventory are correctly tracked through tools, increased accountability will be realized by the organization. Part of the success of a tool is the depth of discovery that can be realized. Rewards yielded from increasing inventory control are the reduction of risk, improved accountability and ability to improve the organization’s performance by ensuring the right users have the right equipment to yield the best results for the organization.

In the small cruise ship company, having the hardware information readily available increased Mr. Wallace’s ability to troubleshoot hardware issues from St. Louis on a ship in Ushuaia Argentina. In a larger organization tagging of assets greatly increases the success of Inventory Control. Another way to reduce risk is not to rely on one specific vendor. When purchasing computer equipment, usually have two trusted vendors with warehouses on each coast of the US so if there was an emergency request that had to be there “tomorrow”, a warehouse in California could overnight something to St. Louis after the east coast warehouses closed for the day.

Mobile Asset Engineering

The tendency to think the devices you use at your desk are “yours” is a real temptation and is increased if that device is mobile and not tethered to your organization’s workspace, especially for BYOD. Effective communication, education of the policies, and company requirements of the one to whom the mobile device is issued is paramount in starting the effective management of mobile asset device management.

The use of a mobile asset outside the organization’s network increases the risk exponentially when returning to the workplace with those mobile devices. Unless the mobile device is a flip phone that cannot text or access the internet there will be exposure to outside networks and influences. In the case of a smart phone or a tablet the ability to load software that is not part of the base installed software, can and probably will directly affect the core operation of the companies’ mobile device.

Mobility also causes reassigning helpdesk services away from a centralized IT department and places more of the responsibility on the end user. And of course, we need to keep the companies’ information on that mobile device secure. Tracking the potential loss of a mobile device also requires the possession of an ability to wipe that device to protect the data on that device from falling into the wrong hands. Handling the mobile device properly involves integration of CMAM, CSAM and CHAMP training.

One of the challenges of asset ID tagging is the shrinking size of some of the devices. The temptation to dispose of the smaller devices improperly is stronger as compared to a larger desktop device or a server unit. Making the customer feel like an integral part of the mobile asset support reinforces the participation of the customer in the policies and responsibilities defined earlier. Some mobile devices set aside for off-network data gathering functions such as field surveys that simply deliver that information to the organization and not necessarily intended for multi-function use may increase the temptation for improper disposal in order to get a more modern device. For example, in the cruise ship industry, it was not uncommon to have older hand held devices “accidentally” fall overboard. While the old was totally adequate for the mission, the desire for a newer device seemed to justify the loss in the mind of the users.

Mobile assets will always bring an increased risk by their very nature. Another increased consideration of mobile assets is keeping the data secure whether it is at rest or being accessed. A realistic view of the abilities of the mobile devices and their true benefits to the organization is an important consideration and requires constant monitoring. One of the tools that can be used is Mobile Device Management (MDM).

So, what can Mobile Asset Engineering contribute? Mobile Asset Engineers can process the analyses of alternatives to address the preceding problems as well as others that mobile devices present. Figure 6 illustrates where Mobile Asset Engineering touch points are aligned on the “Vee”.

One of the more complicated models that is in the workplace today is Bring Your Own Devices (BYOD). If user education and communication was important before, then the importance increases exponentially regarding a BYOD policy. Among the organizational policies needs to be a mobile device policy that directs the mobile user to a mobile app store that is set up to offer the mobile device user the approved apps that can be downloaded to the organizational or the BYOD device used for organizational business. This can avoid the downloading of dangerous apps on a company mobile device. Periodic recall of the organizations mobile assets to the office allows the verification of policy adherence and inventory update. Mobile Asset Engineers can decipher the technical requirements for the Hardware Asset Manager to enable more thorough policies.

Figure 6: Mobile Asset Engineering Touch Points

Managing hardware that is not the organization’s is yet another complication of Mobile Asset Management and Mobile Asset Engineering. Software owned by the organization installed on a user-owned mobile device is one of the complicating factors in this consideration. Mobile device management options are available to aid in both BYOD and organization-owned mobile devices. Considerations of what costs of the operation of the mobile devices must be well established by clear communications and policies. Storage of organization information on BYOD devices will be yet another policy that must be clearly defined regarding the user’s BYOD device. Financial savings can be realized with user provided devices, and the larger the workforce the larger the savings.. One of the most important ways to safeguard your mobile devices and BYOD is to use a Mobile Device Manager (MDM) to monitor and even remotely wipe the device is it is lost or stolen. The security of the information on the mobile device is very important. Mobile Asset Engineers can assist in bridging the divide between the service and asset managers in bringing new devices into the organizational structure.

Two of the most important factors in efficiently considering Mobile assets are ROI and TCO. Mobile Asset Engineers can assist in gathering and analyzing usage costs and values from the workforce, ensuring accurate TCO and ROI data knowledge needed to make decisions that will ultimately produce cost savings. Careful trade analysis is required in measuring the potential benefits from introducing mobile devices (increased ability to work form distant locations, decreased office requirements, etc.) with the total costs (ISPs, security, insurance, etc.).


In this paper, we have provided numerous illustrations on how IT Asset Engineering, by providing a “more technical” view of IT Asset Management, can add significant advantages. Ensuring earlier detection of IT Asset requirements can save costs by reducing duplication and maximizing use. Filtering requirements from “desirements” reduces churn in hardware and software acquisitions and dispositions. Tracking projects across the organization enables aggregation of requirements and facilitating “bulk purchases” to leverage volume discounts. Refining measurement of processes and increases accuracy in TCO and ROI calculations with better understanding of Technical costs.

We believe that all of these argue in favor of establishing IT Asset Engineering in the asset management office of your organization.

About the Author

Steven Ligon is the Senior Systems Engineer for Intelligence Consulting Enterprise Solutions, Inc.