Frustrated developers want to use more advanced programming technologies – which for the most part means more advanced programming languages – to write software, but they can't, because:
(Most advanced programming "technologies" are represented by particular languages, however there are other technologies, in particular the use of Domain-Specific Languages, where the advanced technology is not so much to use a particular programming language, but rather to create one customised for the particular programming task. Despite this subtle distinction, most of the time in this article I will consider "advance programming technology" and "advanced programming language" to be somewhat interchangeable concepts.)
If more advanced programming technologies could be adopted, the benefits would include:
There is a conflict here between benefit and risk. Eventually, the conflict will be resolved in favour of the benefits of using advanced programming technologies. Eventually the other developers will come to understand the new technologies, the old programs written in older programming languages will be upgraded (or abandoned), the new programming languages will be proven in use by early adopters and even large organisations will start to use them.
After all, we do now have Java (and its sibling C#), which is more "advanced" than the mainstream programming languages that preceded it.
But it would be good if we could find a way to gain the benefits of advanced programming technologies sooner rather than later.
Given the conflict between benefit and risk, there are two ways to resolve it:
Option 1 accounts for most of the advanced programming technology "success stories" that we read about. Typically, a problem is identified which is so difficult that it can only be reasonably solved used more advanced programming technologies. The advanced programming technology is used to solve the problem, and this leads to profit. However, option 1 is intrinsically entrepreneurial, with all that that entails. That is, you have to quit your day job, hack away in your bedroom while living off your savings, etc.
This article is not about Option 1. It is about Option 2. Option 2 is an option that can be applied within the "Enterprise". The "Enterprise" is a place where technology choices are made conservatively, but, a lot of money has already been invested in existing applications and data. If a way can found to use more advanced programming technologies to enhance those applications or make better use of the data, without creating additional risk, then the possibility exists for the programmer to use advanced programming technologies to provide benefits to the Enterprise, and get paid by the hour, either as an employee or as a consultant.
The concept of APTROW is based on the following observation:
Here are some of the specific ways that read-only applications are less risky:
Of course the benefits of read-only applications are also limited – after all, if you want to change something, you can't. But we will see that this is not necessarily as much of a problem as might be expected.
So, the proposal is: use advanced programming technologies to write read-only applications to read Enterprise data. Use advanced programming technologies to experiment with different ways of viewing and analysing the same data.
Because of their power and expressiveness, advanced programming languages can be used to tackle programming problems involving more complex data.
Ironically, some of the most complex Enterprise data is the Enterprise applications themselves, written in those "non-advanced" programming languages. Mostly these applications have source code which is only "read" and "written" using generic programming tools i.e. text editors, compilers and IDE's. These generic tools rarely take account of in-house frameworks, libraries or programming idioms.
Much of the difficulty for new programmers understanding Enterprise application source code is stuff like: "Oh my god, in order to get this data from here to appear there on the screen they poked it into this global variable conditionally depending on this status flag on this parent object as configured by this element in this XML file (Oh my god!)".
But using sufficiently advanced programming languages and technologies, it may be surprisingly easy to construct viewing applications which allow even new programmers to understand how different parts of an Enterprise application fit together, and which allow them to navigate along the various quirky Enterprise programming idioms, especially the ones that have been adopted as "Enterprise Standards".
In the Enterprise, no application is an island. However "standalone" your application may seem to be, someone will want to integrate it somehow with some other application, even if they have to manually cut and paste to make that happen.
With read-only applications, a very easy integration mechanism has already been invented, which is, give every "thing" (or object) that the application can view its own address. Technically we call this address a URI (or URL, depending on the implementation details).
A ready-made client application exists which supports the viewing of objects with addresses and linking to other objects via their addresses: it's called a web-browser.
So, adding the concept of Enterprise URI's to the concept of using advanced programming technologies to develop read-only applications, the final APTROW proposal is:
(How to best define Enterprise URI's is a subject worthy of its own white paper, so I will not go into any further details here, except for the next section on edit URI's.)
I mentioned before that the lack of write capability in read-only applications might be a problem. As it happens, a system of Enterprise object URI's gives us a straightforward solution to the integration of read-only applications and read/write applications. Suppose, for example, that
is a URI representing the identity of a particular customer (here "bon" stands for a hypothetical URI scheme "Business Object Name").
Then the URI
can be one representing an intention to edit that same customer's details.
To achieve integration, we just need to implement the bon-edit URI scheme in the browser to redirect to a suitable application, which may or may not be a web application.
There are various details which may complicate this integration, i.e.:
Nevertheless, the potential exists for navigation between read-only applications and read/write applications to be relatively painless, especially for new read/write applications which can be written to support the Enterprise URI scheme.
(The read/write applications will of course continue to be written in time-tested, Enterprise-approved, lowest common denominator "unadvanced" programming languages.)
The benefits of URI-based integration are not just from relationships between different business objects, such as customers and orders. There is also the ability to navigate across application source artefacts and the data processed by the applications.
Consider the following business objects:
Ideally it would be possible for an Enterprise user of APTROW applications to view all these objects and to freely navigate from one to the other.
My guess is that in most Enterprises this is not happening, and different applications provide access to different objects, with limited navigation in some cases:
So there you have it. APTROW – a methodology for introducing advanced programming technologies into the Enterprise. It is a methodology, as opposed to say a framework or a library, and it doesn't even specify any particular programming language or other technology, although no doubt there will be opportunity to write generic libraries or frameworks in various advanced programming libraries to support the APTROW methodology.
