Every software project I have worked on always started with some form of conflict and complicated interactions. This usually resolved itself through the use of a definition regarding roles and responsibilities. That definition kept people on the same page and helped everyone to understand who was doing what.
Now depending on when you happened to look at my job title over the last 13 years, you may have seen one of the following:
Enterprise Application Developer
This means only that I moved from one department to another, however, the physical tasks I employed were the same. My output may have had a different installer/wrapper/output, however, it was the same. I designed, developed, tested and deployed an application into our environment.
When it was time to define the characteristic (metadata) of an application, we needed to start with definitions. Not only what an "Application" is but what "Software" is and how (if) it differs from each other and from an "Operating System".
This is vitally important because no matter who you talk to, they will have a difference of opinion in this area. Let me give you an example that we are currently dealing with. We are implementing a CMDB (Configuration Management Database) for our Service and Support organization. As our application data is pumped into that solution we had to decide whether it is an application or software. The CMDB definitions basically stated that software was the core items used to build a hosting platform whereas an application is the code hosted on that platform. A very specific definition for their very specific implementation.
Our definition was much more simple.
If it's coded, if you develop it, it is a software application simply referred to as an "Application". This can be developed internally or purchased. An application is not an operating system.
That means that everything running on our environment, that is loaded on top of an operating system, is an application and needs to be inventories. That also means if it is a web-based solution, with software code, hosted within a web-hosting solution, however, it is still an application.
We did draw a very discreet line in that we did not want to inventory certain things. Those are items that are "configured" inside of other applications. Item such as:
Web sites without dynamic content, hosted within a dynamic web solution such as Microsoft Sharepoint or created with Microsoft Frontpage or another WYSIWYG client.
Templates configured for an application.
Hosting Platforms (configuration of hardware and application software)
To put forth some simple rules, that people can evaluate their "Application" before attempting to add it for evaluation, we came up wtih some simple rules. It has to meet all of these with a yes response.
Installed on Intel (or contracted) hardware?
Initially used by more than one person (or application) at Intel?
Does this have (or has it ever had) a development/support team?
Does this have (or has it ever had) a development/release process?
This minimizes the possibility that we inventory applications that are sitting in a box, not installed on the environment. It also means that items we paid for, installed, licensed and such, are included. Whether on a server or on a client, we need to know about them so that we can work towards the simplification of our inventory.
Next I will cover how we have gone about gathering this data. Some approaches work well while others don't. Additionally, before you start gathering data you must have a solid review, maintenance and data quality processes in place or the data will be of no use for future analysis.
Have you undergone a similiar process? Are you struggling with doing this inside your company? Have questions? Let us know.