The ALM-Community looks at improving various aspects of ALM (Application Lifecycle Management).
Description:
Application Lifecycle Management is a sub-section of ITIL, which specifies how to manage Services (aka Service Management). When a business have a need that can be satisfied with an IT service, an analyst will analyse the business processes and identify the IT services the business user would need to produce the outcomes of the process. These IT Services are implemented by systems, containing one or more applications. ALM described the end-to-end process from the inception of the application all the way to the commissioning and the data retention afterwards.
As mentioned above, it all starts with a business need. Theoretically speaking, we shouldn’t be thinking about applications at that stage. Practice is however very different. In most cases, the IT service provider will get involved in building the business case to build an application to solve a the need as the Business Stakeholders already defined a solution to their need. So even though the business case theoretically should not be part of ALM, in practice, it often is.
Cross Competency:
Most IT competencies (BA, Test, Development, Operations, etc) are involved in the maintenance throughout the lifecycle of applications. One of the responsibilities of the Business Analyst (BA) is to gathers the requirements. If there are upgrades to be made however, we also need to get those requirements. Hence the BA involvement there. Even when decommissioning, the BA would be involved to discuss the archiving of the data for instance. The same applies for the other competencies. The ALM-Community recognises this and invites all competencies to join and help solve the cross-competency challenges.
Meeting goals:
The ALM-Community and it’s sub communities meet on regular basis to:
- · Catch-up with other professionals.
- · Experts in their field will present their knowledge, allowing for discussion afterwards.
- · Discuss and find solutions for cross competency challenges.
- · Encourage break-out teams to develop artefacts to share solutions to the issues.
Distributed collaboration
The ALM-Community consists of multiple, geo-distributed ALM-Communities with sub-communities. To allow efficient collaboration, an infrastructure has been put in place by which participants can share ideas, documents, track progress, communicate, etc. The structure used resembles the collaboration approach that the Carnegie Melon
Even though every company is different with each their own challenges, but there are also many overlaps. By focussing on the overlaps, patterns start to emerge. These patterns allow the community to provide an ever growing set of processes that are similar across organisations. Any organisation can download those processes and jumpstart/boost their process improvements.
Organisational Customisation
Any processes that are specific to my company can be overridden, while leaving the stream of updates from the ALM-Community intact. The updates for the overridden processes will obviously cease for the time that they are overridden. The overriding of standards is a conscious decision and should be respected.
So, if for instance the procurement process is different for my company, I can change it in my local repository. Every update from the global ALM-Community to the procurement process will cause a prompt when applying the updates. But updates to for instance the Requirements templates (not overridden) will still come through as those haven’t been customised.
The infrastructure even allows for my company to suggest my changes to be adopted by the global ALM-Community. All I have to do is commit my changes and have my local repository send out a notification to the global ALM-Community.
