Is programming dead?
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 organizations 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.
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, catalyzed by other standardization 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 modeling language to describe the innards of applications, known as the Unified Modeling 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 standardize. 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 modeling 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' modeling 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. Some software tools companies were already ahead of what the OMG is trying to paint as 'new and improved'. Relative newcomer Quovadx, for example, has taken to new levels the concepts of using models as a starting point for code generation, to a point where there becomes less and less need to write code at all. Admittedly most of Quovadx’s examples are specific to certain sectors, for example healthcare and financial services, but it begs the obvious question--how close are we to missing out on the code altogether?
The answer is: very close indeed, if the latest offerings from Select Business Solutions are to be believed. SBS, once the main competitor to Rational Rose in the UK, has combined the concepts of MDA with those of design patterns – saying, essentially, that every structure you can think of in code has been written before and can be specified and reused in modeling terms. By selecting said design patterns and using them as input to the code generators, it should be possible to automate the production of the vast majority of code, if not all of it. SBS is not the only company to be thinking this way. However, it is one of the first to achieve it in practice.
Once again, it is easy to make glib statements and any such claim should be tested carefully. Perhaps the question is not whether SBS or Quovadx, Rational or Borland have succeeded in this instance but rather the fact that they are drawing us inexorably towards a situation where the majority of code is generated. There will be complaints about inefficiency, which is tantamount to saying that there will always be a need for experts developing high-throughput code. For the rest, however, assuming this falls within tolerances, it is worth a shot.
Also, the generated code can incorporate things that the programmers wouldn’t necessarily consider or even know about. As its software division encompasses both software development and enterprise management, IBM has a distinct advantage here: for example, it is looking at how standardized event logging can be built into code generators, as support for its autonomic computing initiatives.
Meanwhile, we should consider all of this in the context of the major application vendors, all of whom have their work cut out developing various types of functionality that can be integrated into applications. In addition, there are the independent solution vendors working on vertical solutions aimed at specific geographies and markets. All of these can benefit from the integration-centric view of MDA, where models act as the glue between pre-fabricated components and services bought in from the specialists.
No programmers should be put out of a job by MDA, as there will always be new and interesting things to develop. However, MDA suggests one last and quite seismic shift. In the future, if the models are king, the onus on programming will move outside the business and into the IT vendor marketplace. This would be no bad thing: insurance companies can get on and deal with insurance and pharmaceutical companies can work on new drugs, rather than using up half their budgets redeveloping old code or trying to work out what the new stuff should look like.
The agreement on MDA as an approach is still to be proven--through its adoption and acceptance by the businesses that decide to use it. It would appear, however, that it is only a matter of time.
biography
A leading, user-facing analyst house known for its focus on the 'big picture', Quocirca is made up of a small, elite team of experts in technology and its business implications: Clive Longbottom, Mark Boulding, Dale Vile, Jon Collins and Bob Tarzey. Their series of columns for silicon.com seek to demystify the latest jargon and business thinking. For a full summary of the consultancy's activities see www.quocirca.com, or reach the company's founding directors by emailing quocirca@silicon.com.