Aldon is a leading provider of Application Lifecycle Management (ALM) solutions. The company claims to bring the benefits of process-driven application change management to IT as it accelerates the delivery of mission-critical business applications.

International Developer spoke to Aldon Technology Strategist Daniel Magid and Aldon President and COO, Matt Scholl, for the inside track on the company’s view of the ALM marketplace as we now move to a world where we consider ALM for services-based web application structures.

International Developer: The Aldon Community Manager module is your newest offering. You say that it moves the company from straight ALM upward to a more granular level of awareness so that you can assess the whole range of devices within a company’s total technology deployment. How does this work in practice?

Daniel Magid (Aldon Technology Strategist): Actually, our Aldon Community Manager module has been available for several years. However, our latest release represents a new leap forward. Since we first delivered Aldon Community Manager, our customers have been using it to manage and automate the workflow processes involved in responding to user requests for software changes. Many of them realised that they could use the same workflow automation for any kind of request that was made of IT. Our customers have begun to use Aldon Community Manager to deal with network issues and hardware problems as well as software requests. Consequently, our latest release incorporates a Configuration Management Database (CMDB) which provides a single, accurate source of real-time information about the entire IT infrastructure. With the centralised view on that data and its interdependencies, the CMDB automatically reports on what will happen to the business if any component changes. When it comes to security auditing, change management, process re-engineering, and compliance, a CMDB will eliminate costly downtime.

International Developer: It’s often said that ALM providers face special challenges when customers store data in proprietary formats as it makes configuration management harder. How does this manifest itself and how do you get around this problem?

Daniel Magid: Generally, ALM systems assume that the basic unit of checkout is a file. They are typically adept at copying standard files in and out of their repositories and tracking changes made to those files. The process gets more complicated if the unit of checkout is something other than a file. This occurs when the software development tool or the application the customer is running is built using proprietary technology. In those cases, the unit of checkout might be a defined group of files that must be moved together or it might even be a set of data records in a file that describe the system behaviour or the user interface. In order to manage a proprietary environment, the ALM system must understand the relationship of the files or records that make up the unit of checkout so that it can ensure those artefacts move together. Fortunately, ALM providers often expose those artefacts through standard tools like Eclipse or Microsoft’s Source Code Control specification so that the ALM suppliers can provide access to those items.