To design, deploy, manage and govern software in the enterprise is something I have many years of experience in, and from different corporations, so I intend to do a series of articles in this area, starting with this one.

Software is an element that is critical to business and often difficult for IT to get a grip on. To manage software through its lifecycle is a complex process, and the larger the organization and the portfolio of applications get, the greater the challenges.

Challenges include:

  • Software is brought into the company without any involvement from IT, who would otherwise ensure it fits the existing IT environment and standards.
  • Software is brought into the company without any Enterprise Architecture governance, who would ensure it fits target architecture and business strategy from a non-silo perspective.
  • Uncontrolled and unmanaged software becomes business critical long beyond the vendor has withdrawn its support, thus putting business at risk.
  • Uncontrolled and unmanaged software is not updated with latest security patches, causing security vulnerabilities for the whole company.
  • Different and competing software is used for similar purposes causing diversity in the IS/IT environment and disabling cross-business collaboration.
  • Lack of insight and control of what is installed and used causing license incompliance and risking expensive vendor penalties.
  • Local purchases at higher cost than necessary due to not utilizing enterprise license agreements, or simply because there are none.
  • Client image is deployed containing numerous software products of particular versions, but not maintained up-to-date once deployed – causing massive version diversity.
  • Version diversity in client platform causing complexity in global apps deployment and cross-business collaboration.

Some corporations allow their users to download and install software themselves, causing or aggravating the issues above. Other corporations have revoked local administrator rights for users in order to address and control above, but are then facing the challenge that business request more flexibility and faster response-time to change requests – including new software products and versions as these need to be packaged and distributed centrally. This includes any software that is deployed on all clients, updated frequently by vendors and required for business apps to work – and while updating these it’s difficult to assess the impact it will have on other business apps.

These and many other challenges can be addressed though. The following picture illustrates areas I see being involved in getting a grip on software in your enterprise, followed by a summary of suggested approaches for each area to address the issues above. It’s likely this will involve several parts of your organization, which is why it’s key to have a software governance capability that steer all other areas holistically in the same strategic direction. Such governance capability would normally fit in the strategic / planning part of your IS/IT organization (such as an Enterprise Architecture capability) while the other areas may sit in other parts of your IS/IT organization.

The following approaches can start and progress in many of the areas above simultaneously, so does not necessarily have to be in the order listed below. Besides, some areas you could split up or merge, or you can probably find new ones to add. Consider this a skeleton to help you identify, scope and govern relevant areas in your organization.

  • Client Image & Layers – rather than deploying a fat desktop client image that is difficult to update with newer software versions once it’s deployed, it can be split up into different layers where you keep the core as thin and static as possible and then keep everything that is updated frequently and required on all clients in a dynamic layer.
  • Dynamic and Proactive Updates – this is enabled by the client layers above; the dynamic layer enables you to update components like .NET Framework, Java Runtime, Flash, Shockwave, Adobe Reader, etc individually and dynamically when needed – or preferably even before it’s needed and thus being proactive to business demands.
  • Software Standards – a good start is to standardize all the software that is included in the client image, both the core and dynamic layer, and then work your way through the top-used software across your company. Perhaps it’s not feasible to cover 100% of your application portfolio with software standards, so look at where you are and where you want to be; perhaps it’s 20/80 today and you want to achieve 80/20.
  • Application Rationalization – it’s by having software standards you enable rationalization of the application portfolio. Rather than using a wide range of software products and applications that do similar things, you standardize on one or a few candidates that meet all or most requirements, and then decommission the other apps. Not only will this cut cost and complexity, it will also improve cross-business collaboration and result in synergies in support and training, amongst many other areas.
  • Application Inventory/Repository – you need to know what apps you have in your environment to be able to identify opportunities for rationalization and standardization, and preferably you should also map your applications to business processes and dependences (including required dynamic layer components) to understand their business criticality and impact of change.
  • Software Usability Optimization – this is partly about standardizing software based on business usage and capability, rather than focusing on technical features and products, but also about making sure the software is configured for best User Experience.
  • Standards Life Cycle Management – once you have standards in place they need to be managed through its life cycles, from evaluation to retirement. Changing the roadmap of a standard needs to take many aspects into account, such as licensing cost, user training, data migration, business impact, strategic fit, target architecture, etc.
  • Stakeholder Management – you will never achieve business alignment and gain buy-in to your software standards and roadmaps without proper stakeholder management; make sure decisions are signed off by representatives from each business area who have the proper mandate to do so. Once a standard is signed-off, everything in conflict should be considered an exception, preferably going through proper approval process.
  • Standards Review & Refresh Process – business demands change and new software products and versions are released frequently, hence you need to continuously review and update your standards and roadmaps, and also have them deployed accordingly. Again, a success criteria for this is having proper stakeholder management in place. You also need to be able to do some pre-assessment of impacts and benefits of moving from one product or version to another (partly by using Application Inventory data mentioned above).
  • Software Catalogue / Provisioning Tool – no point in having standards if users do not know what they are and cannot request what you promote. Make sure your users can easily browse and search amongst your standards to find the piece of software that will meet their particular need at lowest possible cost. Standards should be provisioned in precedence to anything else, but it’s wise to also show pre-packaged not-yet standardized software in the same catalogue so that this will be their second choice and only as a third and last resort they will request something new to be packaged and brought into the environment.
  • Software Request Process – once users have found the desired software in the software catalogue or provisioning tool it should be easy for them to simply click request to trigger the purchasing and distribution process. Perhaps you already have existing processes to hook into, and all that is needed is for the request to trigger an email with proper details to the Helpdesk. The request should include user name, computer name, cost center, approving manager, etc – and most of this could be fetched automatically from your existing repositories/directories.
  • Software Purchasing Process – if you have provisioned software smartly in the software catalogue, then users will first and foremost choose software of which you have spare licenses in the pool, or that is free of charge or even embedded in the OS / client image already. In the case a new license need to be purchased it should go through proper approval and purchasing process, and according to existing policies and license agreements.
  • Enterprise License Agreements – as part of creating software standards and rationalizing the application portfolio you convert licenses that are spread across the local business areas into global license agreements in negotiation with the vendors. Preferably any global software standard should have some sort of enterprise-wide license agreement, no matter if the license is funded locally, centrally or perhaps paid centrally and charged back to the business. You will need to keep track of your license agreements in some sort of repository and make sure they are utilized in the purchasing process and managed as part of software standards life cycle management.
  • Software Packaging Process – if the user cannot find adequate software in the catalogue, neither standard nor already packaged non-standard software, the third option is to request a new piece of software to be brought into the environment – and if it’s client-side software then it should normally be packaged and distributed via automated tools. The packaging request form should include all necessary details enabling the request to be properly reviewed and processed, such as business purpose, business owner, technical owner, configuration requirements, and dependencies to other apps (in particular dynamic layer components to enable impact assessment of changing versions in this layer). If the user submits a request that matches existing software then that software can even be suggested automatically to minimize number of faulty/unnecessary packaging requests.
  • Software Packaging Gatekeeper – the gatekeeper reviews and approves all software packaging requests to ensure validity of business purpose as well as compliance to business code of conduct, EA/SAM principles, Security policies, IS/IT strategies, etc. The gatekeeper also promotes existing standards that can potentially fulfill and replace the request, and captures opportunities for new standards and roadmap updates. The gatekeeper role can be distributed/delegated to standards owners and/or facilitated by authorized requestors rather than only being operated by full-time employee(s) centrally.
  • Software Packaging Principles – these are to set standards and consistency in the way software is packaged for centralized and automated distribution, in order to ensure it results in best security, usability and compliance to company code of conduct and other policies. Packaging principles are high-level requirements to packaging technical standards, no matter if the service is in-house or outsourced/offshore (useful if you want to leave the control of detailed packaging standards and tools to the outsourcing/offshoring partner). The principles would normally supersede any installation/configuration instructions provided by the requestor, unless approved exception.
  • Software Asset Management – SAM policies and procedures provides guidance on how to manage software as an asset throughout its lifecycle to maintain software inventory, track asset use/reuse/retirement and ensure license compliance – amongst other things. The ITIL V3 Guide to Software Asset Management contains useful best practices in this area, including content suggestions for creating a SAM business case which in turn could include justifications for other areas above.
  • Enterprise Architecture Principles – Enterprise Architecture is the governance body steering IS/IT activities aligned with business strategy and target architecture. You should make sure your EA principles are defined and established in a way that helps you govern all areas above in the same strategic direction. SAM policies, Software Standards, Packaging Principles, etc should all adhere to and further build on the EA principles.

There’s a wide range of tools that can help manage and achieve above, and in some cases it may make sense to develop in-house solutions for some parts. I will not make any recommendations on tools in this article since what tool is right for your organization depends on what your existing environment, requirements and circumstances look like. Also, your strategy and/or progress in outsourcing or moving into the cloud (if any) will also have an impact on what is the proper tool for your organization as well as how and in what direction to govern and manage above.

I will drill down into a few of the areas above in coming articles, and when available, the headings above will be linked to each of its relevant article. All of the approaches above have been successfully implemented in one or more enterprises, so it’s based on real-world experience rather than theory only.  If you aim to step-up in software governance in your organization and would like help doing so, feel free to contact us.