The previous blog introduced the IM/IT Inventory. In this blog, I am going to take my first stab at how the applications are potentially mapped to the Inventory as indicated in the diagram below.
The above graphic attempts to overlay commonly found software on to a matrix asking two questions: what knowledge is necessary to make changes to the application; and how purpose built application is this application. The underlying matrix was introduced in the previous blog, Inventorying IM/IT in the Grey Zone.
Visiting the Land of Systems
At the bottom-left are systems that are the most general purpose and easy for the user to make configuration changes to. A great example are the office productivity suites such as Microsoft Office. Diametrically opposed are Bespoke Applications that an organization has purposed built. The application in this case may exists only in the organization and may or may not have been written in either a language or manner making system changes easy.
An IM/IT Inventory Sweet Spot
The red box overlaying the model is what should be included in an IM/IT Inventory. The green braces is the grey zone discussed in the previous blog, whether to include or not these ‘applications’.
Substance Over Presentation
Even though an application is seemingly outside of the Red Box, let substance dictate its inclusion in an IM/IT Inventory. If the critical spreadsheet or Microsoft Word mail merge routine disappears tomorrow – and this impedes the business – include this system.
Revisiting in the Times of AI
This blog was originally written in 2014. At that time, AI was an emerging concept. Fast forward to time of writing the update, 2026. Organizations are on the cusp of having AI generated applications springing up everywhere. As these systems take on critical business functions, knowing they exist becomes even more paramount.
As always send me your comments.
As a proviso to the discussion, it appears that you are discounting inventory for the purposes of licensing and/or synergies/counter-synergies caused by a dynamic commodity software deployment. The last thing you want any organization to have to deal with are legal implications from copyright infringements, or even worse, having an inconsistent deployment of tools that cause a fundamental breakdown of work process (i.e. random deployment of the commodity desktop tools triggering constant conversion & compliance issues between differing products/versions).
LikeLike