In the beginning, there were programmers. They wrote software and, mostly, people found it was good. Then the platform changed, so they wrote it again. And again and again. Software was rewritten through changes of operating systems, databases and architectures. Sometimes there were even improvements on the time before but often it was little more than a port.
This is being a little glib. All those changes were part and parcel of the technological evolution we have experienced over the past thirty years, punctuated from time to time by leaps in understanding that gave us client/server applications, say, or the commercial potential of the web.
Functionality such as shopping baskets wasn't even a twinkle in the eyes of the first programmers. The fact remains, however, that much functionality that exists today has changed very little over the decades. Payroll is still payroll. Customer records are still customer records. Insurance policies remain insurance policies and so on. There remains scope for improvement but certain business logic exists as it should and is likely to continue to exist for some time to come. And why not, if it works.
Given this continuity, in programming circles, the quest has long been to make things so such functionality could be used again, either in other applications or on other platforms. It was not to be – apart from some exceptional cases where code has been reused, most organisations have decided it was more cost effective to rewrite. There are libraries - and there have been since the beginning - but these have rarely stretched all the way to the heart of the business logic.
Reusable applications coming?
Perhaps things are finally getting there, for a number of reasons. The first, most press-worthy reason is web services, the generic term for a set of standards for how application software elements talk to each other. Web services wouldn't exist without all the work that's gone into the development of application architectures that take most of the work out of the software plumbing – Enterprise Java (J2EE) and Microsoft's .Net architecture. One gave rise to the other, catalysed by other standardisation efforts such as the adoption of XML and the acceptance of programming, design and analysis patterns that dictate common structures and where they should best be used.
The second reason, which is also inextricably linked into the application architecture work, is the unification of standards for describing what applications look like. The whole world has settled on a single modelling language to describe the innards of applications, known as the Unified Modelling Language (UML). The standard is now at 2.0, which means that it covers the vast majority of requirements. It's not perfect but it is certainly comprehensive.
All of these things together do not make reusable applications but they help. There is another knock-on effect: now the standards are virtually complete and universally accepted, the standards bodies themselves (such as the Object Management Group) have had to set their sights on new things to standardise. What they have come up with is rather intriguing. Essentially, having agreed the tools and techniques to be used, they have turned their attention to the process, defining what they call model driven architecture, or MDA.
The goal of MDA is quite straightforward: to enable applications to be specified entirely in modelling terms, which are platform independent, rather than in code, which varies depending on the target architecture. From the OMG's perspective this is largely a boon for application integrators, who spend (nay, waste) time converting perfectly good code to work on different systems. As it is defined, MDA enables such lower level programming to be automated by code generators, freeing up time to be spent on the more interesting stuff – the business logic.
Code generators are nothing new. Fourth-generation languages using code generators followed 3GL's (such as C, Pascal and FORTRAN) as sure as night followed day. Later, software tools such as software through pictures started a fashion in using models to represent code, continued into the land of UML by companies such as Togethersoft (now part of Borland). Indeed Borland's and IBM's Rational's as well as other companies' modelling tools have very quickly jumped on the MDA bandwagon. Fair enough – to an extent, they were doing it already.
There are a number of advantages to the MDA approach, not least that the design specification can never again be out of date, as it is the only thing that is changed. It also takes the onus well and truly away from the code and gives it to the design. One of the greatest flaws of the IT industry is the habit of implementing a solution before it has been specified or designed – if construction projects were treated in this way, we'd all be living in shacks.
This is not saying that there is a place for programming. Rather, that code-centric initiatives offer a carte blanche to less scrupulous development shops. In engineering, architects exist for a reason, which is perfectly applicable to software.
Analyst Jon Collins is with Quocirca, a business analyst firm based in Europe.
Join Discussion