While the open source Linux operating system has made substantial headway on mainframe platforms, open source asset discovery tools seem less likely to make the jump to big iron. Efforts such as the Eclipse Foundation's MoDisco model discovery software project have promise, but the ranks of open source discovery tools are thin.
Open source tools have use for things like developing user interfaces, BPMN and forward engineering, but the reverse engineering capabilities tend to be more of a challenge, according to Denzil Wasson, CTO of Everware-CBDI, a technology consulting company.
Quite simply, there is so much specificity to particular domains that few open source tools can really deliver what you need, he says. “There are a lot of capabilities available in terms of reverse engineering static structures to determine things like whether it is hierarchical or file based, but the compiler in legacy systems can do that anyway,” he says.
Thus, notes Wasson, it is important to look beyond tools if you want to make your discovery and modernization efforts more agile. The methods that underlie tools and projects are in effect more important.
“If you engage in a modernization project and have as a goal not just a modernized service but also the capturing [of] underlying knowledge, you can do so in [modeling] format," said Wasson, pointing to the Object Management Group Model Driven Architecture (MDA) format as a prime example.
"Then, the next time you need to update, it is simply evolution not modernization,” he explains.
In order to achieve that quickly, the agility and SOA have to intersect. In Wasson’s view, the key is to do this with “quick hits.” He says you have to avoid excessive analysis and take more of a “meet in the middle approach,” where you develop a general idea of what you want as an end state and what capabilities exist in the existing code. “If you create an agile approach and then start to iterate, you can evolve quickly,” he says.
Likewise, too often, according to Wasson, people start with a service and then try to find requirements that fit it. That can create obstacles to progress and lead to "analysis-paralysis," he says.
"However, if you are applying good service design approaches the service will be able to evolve later as new requirements come up,” Wasson says.
“There is always a tension when trying to define these enterprise level services; you can tend to get into design-by-committee where nothing gets done,” he says. Instead, you should look at what you have in terms of existing code, and if it isn’t good enough, look at the cost of modernizing it or not using it at all. “That approach provides leverage that can lead to compromise,” he says.
And, he adds, the people most interested in the future of a particular service will probably fund the iteration so it becomes a self-fulfilling prophecy – you consult the people with the need and the money, and that gives you the capability to evolve. “You end up with a critical mass of satisfied customers who can then help you advocate for using a service as it is – which is usually more successful than the top down approach of excessive analysis and trying to make everyone happy,” he adds.
This was first published in April 2011