It is a truism to say that organizations, in particular governments, are relying more and more on technology to operate and deliver services. In a 2014 blog, IM/IT Inventory, I explored the concept of what assets should an organization actively manage and track. The following graphic was introduced as part of a larger concept known as the IM/IT Lifecycle.
To Include or Not to Include – that is the Catalog?
The purpose of the blog series was to try to answer the question, which bit of technology should be included, or not, in things like an inventory of applications. The conclusion was pretty much, if it has value – include it – and if it will take a material amount of effort to recreate it, definitely include it.
Alas there is a definitional challenge when it comes to building application catalogs, namely WHAT IS an application? Some definitions available include:
- ITIL – Application: Software that provides functions which are required by an IT service. Each application may be part of more than one IT service. An application runs on one or more servers or clients. See also application management; application portfolio. (Axelos.com; glossary, accessed 2018-01-27).
- COBIT – Application: A computer program or set of programs that performs the processing of records for a specific function. Scope Notes: Contrasts with systems programs, such as an operating system or network control program, and with utility programs, such as copy or sort. (www.isaca.org; glossary, accessed 2018-01-27).
- Techopedia – Application software is a program or group of programs designed for end users. These programs are divided into two classes: system software and application software. While system software consists of low-level programs that interact with computers at a basic level, application software resides above system software and includes applications such as database programs, word processors and spreadsheets. Application software may be grouped along with system software or published alone. Application software may simply be referred to as an application. (www.techopedia.org, accessed 2018-01-27).
Why Ownership Matters
All 3 definitions try to get their arms around the question, how long is a piece of string. Unfortunately the string is only going to get longer as applications pop up on smart phones, are meshed with AI or are used by an organization but inhabit the cloud. Nevertheless, the definition is important because no matter where/how/who etc. the application is run – an organization must still keep internal accountability for its creation, maintenance, usage, information management and ultimate disposal.
Accountability is important because if service is increasingly delivered by technical means (including robots, AI, cloud and the Borg) then human accountability for its proper functioning and adherence to business objectives becomes more, not less, important.
Another important reason to define an application is to provide ownership both technical and business. This concept will become both more difficult and more important as applications become completely embedded in business processes and wink in/out of existence because of an accelerated development time frame.
But is ‘IT’ Spoken For?
One of the challenges of trying to assign ownership is that busy business users don’t want to be bothered with having to own technical resources such as a flux capacitor or an anti-matter chamber (these exist, right?). They want to focus on their widget production system without being bothered with tech-esse. However, all the technical bits need to be ‘owned’ by someone for no other reason than to ask: ‘can we turn it off‘? To assist with this, I am proposing a 3 tier ownership structure.
|1. Strategic. Technology in this group is often at the system level meaning that it is composed of 2 or more applications. A strategic system is often long-lived and may directly or indirectly support multiple areas of the organization and product lines.||The most senior person in an organization that relies on the technology for their immediate accountability. Resist the urge to give everything to the President/CEO – this is the day-to-day senior owner, e.g. the VP of Operations.
The owner may sometimes be known as the information controller. I like this as it focuses on the value of a system (information) rather than the means of a system (technical).
|2. Tactical Application. A bit of software that may support one or more business/technical needs. Each tactical application has a single or a few outputs it produces. It may exist on its own and/or it may be part of a larger system.||Because most entries in an organization’s application catalog fall into this category, it is not surprising that most owners are middle level managers.
The biggest challenge in this category is what is in or out. See the above blog for some thoughts on this.
|3. System/Operations. A bit of software that the techies are primarily aware of… until it does not work of course. This includes ITIL system programs but may include utilities that business users rely on to operate a tactical application.||Although these applications support a business user, their owners are the technical folks. In this way, the technical areas provide a service to the business/ tactical applications.||
Like most things in life there are definite grey areas between the above 3. This is where professional judgement comes to assign a bit of code to the right category and therefore to the correct accountable person. In doing the assignment, I would suggest that an organization use the following rubric in assigning ownership.
- Start High – Work Low: there is an inclination to make all technical things belong to the techies. Therefore, all systems start with being owned by the highest possible level until they are pushed down based on the following guidelines.
- Who Gets to Change or Turn IT Off: this guideline is the contrary to the above, who gets to make changes to the bit of software. Ideally this should be pushed down as low as possible. When in doubt, who is responsible to to turn the dang thing off when the application has outlived its usefulness.
- The User/Customer, Disenfranchised and the Veto: Because the first two purposely try to move ownership either up or down an organization, the last consideration is consider the outcome.
- Who is nearest to the user/customer of the bit of software and therefore can make the best determination whether or not cinnamon red on a burnt orange background is a good colour scheme for web page. Move ownership down when this factor is important.
- Who are the internals and externals who are affected but are disconnected from the decision-making choice; these may be users or a few degrees separated from the user. Move ownership up when this factor is important.
- Who has a veto either explicitly or implicitly? What are the internal and external politics of the bit of software? If there are few such considerations, move ownership down; if there are many such considerations, move the software up.
- The Times are a Changin’: Use professional judgement to make a determination and then plan to periodically or ad hoc return to the decision. Hopefully ownership generally moves down as a system matures and becomes stable – a change in the environment may require it to go up for a bit..
Conclusion and Other Ownership Constructs
The above takes a bit of a traditional view of ownership and purposely avoids such knotty issues as open source software or software as a service. My expectations is that an organization with lots of applications to document (in particular governments) should spend time on these assets and then turn their attention to the more esoteric. If an organization really does not own any applications then this discussion is a bit mute and academic anyway.
Let me know if the above model is useful and how you would improve it!