High-productivity Software Development

I’m seeing quite a lot of high-productivity business software development solutions these days, usually presented as PaaS (Platform as a Service, which includes services for developing and deploying applications); as opposed to IaaS (Infrastructure as a Service which just provides virtualised servers, storage and networks, and the operating systems that make them work; on which you can then run conventional development tools); or even conventional software (see the NIST Cloud service definitions here). I think these distinctions are blurring anyway; the real issue is whether you want your developers to be thinking mainly about the difficulty of getting the code to work or mostly about the problems with getting the business outcomes to work. I note that there are also tools intended to make cross-platform mathematical and high-performance computing more productive, such as Rogue Wave, but I’m not really considering them here, although they do have business applications.

High productivity business software development, in my context,  involves modelling the business outcomes you desire. in a visually-oriented GUI; and the system then generates code or runs an interpreter to make them happen—a declarative approach (where you simply declare what you want to happen, the business logic rather than the control flow). This contrasts with ‘third generation’ procedural approaches (COBOL, C++, Java; some more productive than others) where you spend most of your time designing procedures for how the code is going to work and comparatively little time on deciding what it is supposed to be doing for the business. Both approaches work; but the declarative approach is more efficient because it uses a higher level of automation; although it can (depending on implementation) sometimes be less flexible. In both cases, documenting the business reasons for the outcomes being needed are also important, but they are easier to find and verify when they are linked to a visual business model rather than to program code.

There are a whole range of High Productivity business development solutions these days and as I said when comparing Force.com (now called Salesforce1) and OutSystems Platform, they are mostly all ‘fit for purpose’; it’s simply a matter of deciding exactly what purpose each is fit for and whether it matches your specific needs (which also implies that you have a clear idea of what your needs are, which isn’t always the case).

It is quite clear that all the high productivity development concept has matured and that 20th century concerns about lock-in, for instance, shouldn’t be a concern any more (see my analysis, in connection with Mendix, here). There are a lot of variations on the theme, ranging from tools designed for ease-of-use by non-specialist business end-users, but which may need them to resort to low-productivity procedural code when things get complicated; to  tools that are seamlessly and wholly declarative, based on a business model, regardless of business complexity (again, see my comparison of Force.com and OutSystems platform, here). Then there are tools that have been around for ages and aren’t yet supplied as PaaS, but which still have loyal customers and are now attracting new ones, such as Uniface. And there are comparatively new tools attracting increasing respect, such as Mendix and, perhaps, WaveMaker. And there are plenty of others, although I’m not really talking about high productivity coding tools such as Embarcadero RAD Studio here.

What distinguishes a high-productivity business-software development environment from something like a spreadsheet then, that end-users once thought would deliver business outcomes more efficiently than the procedural systems used by the IT group? Well, one differentiator is the business model, that abstracts the business process from the code; and which can be verified for completeness and consistency (a Visio picture isn’t a verifiable model, by the way). ‘Productive’ (in the short term) spreadsheet development generated a legacy of error-prone un-maintainable systems—and a spreadsheet governance industry—and we don’t want any more of that.

‘High productivity’ has to be assessed in terms of the productivity of the provision of business outcomes, over the whole life-cycle of an automated business system as it changes in response to changes in the business. Simple spreadsheets solving simple business problems stack up quite well, but don’t do much; complex spreadsheet systems, dealing with complex business systems, very quickly become very unproductive and hard to maintain. So spreadsheets are out-of-scope; but I’m also wondering whether rule-based systems such as IBM’s Operational Decision Management (ODM) count as high-productivity business software development (there’s a rather technical overview here)—I don’t see why not.

So, I’m thinking of looking at proper (enterprise-strength) high productivity development tools again. At what the scope of these should be, and at how they are stacking up in comparison to each other—I think they just might be the future of business systems development.