IT Directions« A simple way to evaluate open source | Main | Gaining control over large-scale software development »
March 30, 2006March of the IDEs
This blog entry is the first in a new series. In the next few postings I will be looking at enterprise software development practices in general, with the aim of setting into context various current movements from a management viewpoint. In particular, I will be discussing the relationship of application programming (whose state-of-the-art is evolving rapidly at the moment) to other modern approaches (in particular, SOA and BPM), and showing how the use of all 3 approaches can be properly synchronized within the enterprise.
If you have a say in how software development (by which I include the implementation of SOA services or BPM processes) - is carried out in an organization, or organizations, these next entries will provide you with important guidance. The IT industry is now in a state of ferment similar to that of the 1980s, when object-oriented programming started to gain widespread traction - yet the variety of techniques and tools currently available makes it far harder now than it was then to understand what "best practices" consist of, particularly from the standpoint of a CIO or enterprise architect.
Why is this? In a nutshell, because the choice of software development tools is now bewildering. In the 1980s, a reasonably sophisticated software development tool was Emacs, whose macro support made it a quicker way of creating and testing programs than a vanilla text editor. 2 decades later, people are still using text editors with macros (and some are still using Emacs), but only the diehards work without the support of a vastly more complex "IDE" (Integrated Development Environment). A typical IDE provides templates, offers wizards, generates code/documentation, automates compilation/testing, supports deployment to a range of platforms, synchronizes the work of a team, and so on - a range of features that once you have used them, makes the idea of going back to text editing alone seem rather quaint.
So what's the problem? From the sound of it, everything is hunky dory. Unfortunately not. Many organizations are sinking into a morass of unstructured practices that can only lead to meltdown in the end. Just when everyone thought it was safe to go back in the water after replacing hundreds of User-Developed Applications (e.g., departmental Access databases and Excel spreadsheets) with more or less centralized ERP systems, integrating their legacy mainframe applications via EAI, and fixing the millennium bug, a new danger is on the horizon - what you might call system overload. In the same way that Access and Excel made it possible for departments to spawn their own mini-systems all over the place, so the new generation of powerful software development tools is making it possible for the same people to do it all over again - but this time the products of their effort are vastly more complex, and integrated more tightly into back office automation. They will be a lot harder to harmonize or get rid of than the databases and spreadsheets ever were.
Broadly speaking, there are 3 classes of software development activity going on at the moment in the enterprise:
- Developing self-contained systems, whether as standalone applications or as customizations to third party packages.
- Creating building-block components to be exposed as services via SOA tools.
- Defining end-to-end business processes to be executed via a workflow/BPM engine.
In each case, new principles and practices are emerging, yet these approaches offer no straightforward means of taking a helicopter view - of integrating your work either with the other types of development activity, or with other projects in the same enterprise.
Considering first the programming of self-contained systems, I have discussed in previous entries how by far the bulk of enterprise technology is still implemented via packages (with or without customization) and custom applications. And programmers working on such systems have the benefit of lots of new and powerful techniques to play with, all of which are accessible in a simple way courtesy of their IDEs - pattern-based design, test-first coding, aspect-orientation, model-driven architecture (MDA), inversion-of-control containers, and so on. Yet all these techniques are aimed at single system development - in themselves they provide no means of synchronizing programming work across a large organization, and in some cases (MDA, for example) they actually make it harder.
SOA and BPM vendors may respond to this by claiming that their technique is, in fact, the route to solving just this problem - "buy our toolset and all your integration problems will go away". However, examine the writing of experts in either field and you will be recommended to start small (even if you think big). Third wave BPM was presented as something of an inverse to the big bang approach of 1990s BPR, in which companies were urged to implement wholesale radical change, and the use of small-scale pilots in SOA is encouraged by thought leaders. A helicopter view may be advisable, but in the absence of any more formal means to acquire one than the diverse best practice kitbags of numerous consultancies, it is probably safest to dip a toe into the water rather than dive straight in and bet your business on wholesale transformation via SOA or BPM.
The heart of the matter is that computer science has, until recently, made no real inroads into the problems of large-scale human collaboration. When I first started an MSc Computation course at Oxford University, I was handed a pamphlet containing "THE MATHEMATICS OF PROGRAMMING" - An Inaugural Lecture delivered before the University of Oxford on 77 October 1985 by C. A. R. HOARE, Professor of Computation. In this short lecture, Hoare captured something of the academic spirit of the time in his summary of the principles of the Institute of which he had just become head:
- Computers are mathematical machines.
- Computer programs are mathematical expressions.
- A programming language is a mathematical theory.
- Programming is a mathematical activity.
Hoare went on to say:
These are general philosophical and moral principles, and I hold them to be self-evident - which is just as well, because all the actual evidence is against them. Nothing is really as I have described it, neither computers nor programs nor programming languages nor even programmers.
...
Our present failure to recognize and use mathematics as the basis for a discipline of programming has a number of notorious consequences. They are the same consequences as would result from a similar neglect of mathematics in the drawing of maps, marine navigation, bridge building, air traffic control, or the exploration of space. In the older branches of science and engineering, the relevant physical and mathematical knowledge is embodied in a number of equations, formulae and laws, many of which are simple enough to be taught to children at school. The practising scientist or engineer will be intimately familiar with these laws, and will use them explicitly or even instinctively to find solutions to otherwise intractable problems.
As a result of these concerns, since 1985 we have made more or less progress towards a mathematical understanding of how computer systems operate, and some of the lessons learnt have been applied to business technology. But there is little recognition either inside or outside academia of the need to formalize the principles via which people collaborate to create business systems - and it takes only a smattering of common sense to appreciate that this is just as important.
TAKE AWAY
Consider the various streams of human activity concerned with package installation/customization, system development, SOA or BPM within the organization(s) you are concerned with.
- Are these streams of activity carried out in a integrated fashion?
- Do all involved know of each other, and interact in a systematic, constructive way to ensure that consistency is maintained?
- Are there effective controls in place to ensure that the different parties are working together to transition business operations towards fulfilment of tactical and strategic organizational goals?
If so, well done - you're certainly one of the few. If not, stay tuned to this blog.
Posted by keithhb in
Business Process Management
• Management
• Service-Orientated Architecture
|
Digg This|
Add to del.icio.us
