Peter Draney and the art of keeping good software alive

Peter Draney had a way of bringing a software discussion back to the person who signed the cheque. In July 2010, he described an automotive lock maker that had made shipment processing six times faster. Two people had done the modernization work. The next meeting with the finance chief, he suggested, ought to go rather well.

There is a whole career tucked into that little example. A cumbersome job. A small team. A result that can survive a conversation outside the IT department. Draney, the co-founder and former CEO of LANSA, spent decades selling tools for that kind of improvement. The machines changed their names; the customer still needed the shipment to leave.

His story makes an interesting companion to the software industry’s affection for a fresh start. The recurring question in his work was how to give an existing business new capabilities while respecting what it had already built. A blank sheet is attractive. It is also remarkably indifferent to payroll.

A business before the business

Before LANSA came a partnership formed in the mainframe world. In the early 1970s, Draney and Lyndsey Cattermole worked as programmers for Alterego in London. Cattermole returned to Melbourne in 1974. Draney returned to his hometown of Sydney at the end of 1975 to open another Australian office.

They sold mainframe software and developed a training business, specializing in PL/1. In January 1978, they went back to London and negotiated a management buyout of the Australian operation. The business became Aspect. The two future LANSA founders had already acquired experience in both the machinery and the commercial arrangements around it.

LANSA followed in 1987, founded by Draney and Cattermole to sell development tools for IBM’s System/38. The AS/400 arrived the next year. A business built for one generation of computing was immediately required to accommodate another. That sequence would become familiar.

Aspect and LANSA also led to different corporate chapters. KAZ acquired Aspect in 2002. By August 2003, Draney had left his managing director position in KAZ’s technology services business, while remaining a director at the time. LANSA continued as the development-tools business with which his public voice became closely associated.

The arithmetic of two

Read Draney’s December 2008 editorial and an unusual preference emerges: he keeps counting people. At KLM Equipment Services, two developers supported systems for an operation maintaining thousands of pieces of airport ground equipment. Baggage dollies and large loaders made an agreeably solid backdrop to a discussion about programming productivity.

He also highlighted National Envelope, where a project brought together information across 20 locations, four enterprise systems and three databases. Most of the development and JD Edwards integration had been done by one developer, with other programmers assisting on connections to the remaining systems. The journey from concept to pilot took about three months.

These examples describe particular projects. Their significance for a portrait of Draney lies in his choice of evidence. He wanted the reader to compare the scope of the work with the resources available. The appeal was understandable in late 2008, when his opening concern was organizations reducing expenditure.

For a founder of development tools, the customer’s small team made a useful protagonist. It gave a rather abstract promise a human scale. Someone had to maintain those applications the next morning. Someone would answer when a new requirement arrived. Draney’s examples kept that person in the picture.

Good software deserves another screen

By June 2009, his attention was on the awkward borders between computing environments. LANSA was promoting iFusion.net, an approach to combining IBM i and Windows .NET resources. Draney described development teams that had become separated into their own technical worlds, even when their applications served the same business.

One example was Agilysys and its lodging software. The company used Visual LANSA to redevelop its Lodging Management System and offer Microsoft .NET as an alternative to IBM i. A customer executive estimated that LANSA had helped bring the resulting Guest 360 product to market 50 percent faster, saving more than a year.

The estimate belonged to that customer and that redevelopment. Draney’s broader argument was about giving organizations options. An established application could have another destination. A team’s existing knowledge could remain useful as the technical setting changed.

In January 2010, he returned to the machinery beneath that flexibility: the repository, where business rules and validations could be defined for reuse. He explained how Version 12 extended their availability beyond LANSA programs to other software accessing the described data. Rules already written could do more work.

That is a modest-sounding technical arrangement with a recognizable business implication. Every duplicated rule creates another place to make a change. Reuse offers the prospect of fewer repetitions and fewer conflicting versions of the same intention. Draney’s product commentary repeatedly moved between that internal discipline and the visible things customers wanted to add.

The CFO is listening

The July 2010 column supplies the clearest glimpse of his sense of humour. STRATTEC Security Corporation, the automotive lock maker, had chosen an inefficient procedure as its starting point for modernization. Shipment processing became six times faster. Draney admired both the result and its probable reception upstairs.

“Just two guys did this. I bet their CFO is all ears the next time they knock on his door.”Pete Draney · July 2010

There is affection in the joke for the people doing the work. They have an argument for their next budget request, and it involves something that actually happened. His surrounding discussion treated modernization as a decision with costs and returns. The presentation needed a business reason, particularly when an existing application still functioned.

The same column discussed automating exchanges held together by interfaces, paper, email, fax and human effort. That list has the texture of an actual office. The machine may be fast while the work between machines remains slow. For Draney, integration offered a way to remove repeated handling and improve accuracy across those exchanges.

A software founder can describe a future in which everything is elegantly connected. Draney was also interested in the current procedure that consumed too much time. It gave his argument somewhere concrete to begin.

A quarter-century, with more work to do

His 2011 writing resisted the suggestion that small teams were the entire market. CBH, the Australian grain co-operative, had built its core grain-handling system using LANSA. The project’s development team varied from six to 30 people. Draney described a substantial undertaking, alongside the smaller teams he so often featured.

He was also blunt about the difficulty facing developers trained in RPG and traditional 5250 applications when asked to deliver richer interfaces. Projects could fail. Frameworks offered a structure for prototyping and development, reducing the amount of supporting machinery each team needed to assemble itself.

January 2012 brought LANSA’s 25th year and an anniversary editorial directed firmly towards the next release. Draney described continued research and development investment, preparations for Version 13 and an international user conference in Orlando. The birthday arrived with a product schedule attached.

Mobile development occupied a growing part of that schedule. He discussed LongReach, which connected Apple mobile devices with IBM i files, and plans for native mobile application development that would draw on programmers’ existing skills. Once again, a new destination was being paired with something customers already knew.

His stated priorities combined protecting the investment of existing LANSA customers with expanding what the tools could do. The balance matters. A platform vendor asks people to build on its decisions. Each new direction therefore carries an obligation to the people who followed the previous one.

A new owner for a long promise

On December 18, 2018, Idera announced its acquisition of LANSA. By then, the business was described as a low-code rapid application development platform for mobile, web, desktop and cloud developers. LANSA reported use by more than 8,000 organizations in 65 countries at the time, a dated measure of the business Draney had helped build.

LANSA joined Idera’s developer-tools business alongside brands including Embarcadero, Sencha and Froala. The announcement said Draney would continue in a senior leadership position to help develop a growth strategy. His comments stressed ease of use and the speed at which software could deliver customer value.

The language had evolved from fourth-generation development to low-code. The underlying concern remained easy to recognize: businesses needed applications, and the complexity of making and maintaining them had consequences for time, staffing and change.

Draney’s career offers an unusually long view of that concern. A founder has to persuade customers to begin. A development-tools founder also has to give them reasons to continue, years after the first application goes live. His editorials returned to that second responsibility with the persistence of someone whose customers still had work waiting.

The shipment was going to leave, or it was going to sit there. A faster process gave the programmers something useful to show the finance chief. For all the changing terminology around enterprise software, Draney’s little joke still lands on a practical ambition: make the work easier, then let the people who do it take the credit.