Effective Application Lifecycle Management (ALM)
Production companies use ERP as process automation software. In software industry, we should use ALM software to manage software processes. Let’s dig into how successful we are at that point. Sometimes ALM term is interchangeably used with Software Development Lifecycle (SDLC) but I think ALM is a broader term which is not limited to only development. I give you an example from ERP world. If ALM is ERP of software companies, SDLC is only manufacturing part of ERP (Shop Floor Management). ERP enables companies not only manage manufacturing but also sales, purchases, marketing, materials, supply-chain, customers, stocks and products. Product lifecycle Management (PLM) has also similar features with ALM in terms of scope. PLM is just a part of ERP systems. My last example is Software Factory or Software Product Lines methodology which is inspired from manufacturing factories and their process management. There are many similarities between production-manufacturing processes and software processes which are beyond this blog entry scope.
Do we really use effective tools for ALM today? Are there really qualified applications for software automation? As every ERP vendor built their own tool-set, we ended up this end. Finding a satisfactory ALM suite is really hard or impossible. Every software house should not build its own toolset which requires lots of resources. On the other hand, there is no single ALM toolset to manage all processes. Using different tools for different processes has many difficulties and problems. “Software Engineering” remains only in our processes but couldn’t be automated good enough as it is desired with ALM tools.
Let’s try to capture what are the problems of today’s ALM tooling:
1- Software process management tools are not integrated: We need an “Integrated Application Management” suite like production-manufacturing companies needed years ago and ERP had emerged. Integrated Development Environment had emerged for similar requirement. But today’s requirement is much wider. Application lifecycle begins from idea into project then to modeling. It continues with development, release, deployment, maintenance and configuration (SCM). What we have today is separate products for every phase. There are many efforts to integrate with IDE adding for example requirement-bug management but has problems and limited. I think we need a mature end-to-end ALM product defining process borders and close to technologies that the applications are running.
2- Existing tools are not mature (or not existing): Existing tools are not mature and not functional well enough to gain widespread usage and popularity. There are many creeping technology waves causing re-write and disallowing advancement in true direction. Luckily we see some build tools emerged recently but no release management at the moment. Reaching to the SCM area is still a long way to go.
3- ALM is thought separate from DLM (Data Lifecycle Management): Many enterprise applications are data-intensive. DLM is left to Database Administrators (DBA) and its importance is neglected. What is the relation between DLM and ALM? Every software release includes database structure changes, data transformation operations. Application run-time behavior is adjusted with some parameters. It is a common conflict that occurs between DBAs and developers about data modeling (Application versus DBMS requirements). Especially in data-centric applications, DLM should be considered earlier in software process (this is also generally an afterthought like security). Data archiving is a branch of DLM and closely related with application design.
4- Framework and Tool Islands/Silos Floating In Enterprise Sea: As enterprise ALM needs are not met by a unified solution, granularity increases and causes complexity and management dilemma. Most of readers should have experienced many integration and management problems of their frameworks when trying to use with Data Modeling Tools, Code Generators, Built Tools, Test Tools, Deployment Models and Profiling Tools etc.
5- ALM should not be a documentation tool: Adding another burden on developers is not true for the sake of quality without real benefit. ALM is not only the drawing of requirements, models, object interactions, execution with UML. ALM should provide requirement traceability that each requirement should be easily related with release plans, release notes etc. Data Models should produce database configuration scripts. Application Generators should be used for every part of software with appropriate framework API’s. Otherwise ALM tools will not be effective.
Since ALM is a broad term, let’s try to define borders and how ALM tools can be in these areas:
1- Project Management: Software projects should be tracked with this tool. This is used for entire lifecycle of projects from development to implementation. Project resources can be managed with this tool (Time/Budget/Scope).
2- Requirement Management: Once project and product requirement specification (SRS) is documented then these requirements should be loaded this tool for future traceability. Requirement planning and priority assignment is done here. New requirements may emerge as the software is taken into use.
3- Modeling: Project or product is defined and modeled in software design specification (SDS), this information is used to model application. For DB applications, this is the data model and behavior of applications (functions).
4- Development: Editing/Debugging/Profiling/Testing environment for software development. This is commonly an IDE.
5- Testing: Some tools for quality team. Any type of tests should be supported (Not only unit test but also integration and stress tests must be included). Automated test is final point to reach.
6- Release Management: After tests are completed with acceptable results, application is ready to package. Package and Deployment tools are needed for version and change management.
7- Documentation: Shipped applications should be documented with tools. One example tool is JavaDoc. Packaging tools should support document inclusion into packages such as help documents, release notes etc.
8- Deployment (Configuration Management): Application should be easily deployed to the target system without pain. Upgrade or new system installation should be done to the running system with acceptable or zero down-time with automated tools. For example it is error-prone to apply database table changes manually.
9- Runtime Management: Applications run-time should be easily managed. Application processes, threads, memory usage and connections should be manageable (start-stop-terminate-kill-allocate-deallocate).
10- Performance Management: Performance is one of the biggest problems of enterprise applications since these applications are composed of many related tables. Java memory management is another performance hot-spot. Tools should help us to find bottleneck without compromising system availability.
11- Bug Management: As the system goes alive, users find many bugs. Sometimes, bugs are reported only in system logs. These are all captured and should be managed and corresponded with new software fix releases. This must be corresponded with quality management.
12- Data Management: Application data requires maintenance like erroneous data correction. Each application data correction may need different procedures. Some data can’t be changed after some status. Another topic is master data (MDM) may need to be replicated across systems to provide consistency of data.
Today, we don’t see a complete ALM suite that solution set spans all of these areas. Middleware companies mostly provide development-oriented tools. ERP vendors’ software platforms are not generic enough to use out of ERP packages (ERP Lock-in). If we intend to build a “Software Factory”, we should have as much as automation that manufacturing factories have today. With ever-changing software technologies and trends, this is really a difficult goal.