The Misunderstood Middle  
by John Tibbetts and Barbara Bernstein  

InformationWeek, May 26, 1997  


Why does the area between UI client and database server still swallow so many programmer hours? We've got a theory. 

 
     So many advances and so little progress! The application backlog persists despite formidable help from visual builders and object toolkits at the front end, database managers and transaction monitors at the back. Somehow innovation and automation hit a wall as they approach the middles of transactional business applications. In that vast, uncharted area between user-interface client and database server, developers still hand code applications on a case-by-case basis, much as they did in 3270 days.  
     We have wondered for years why this middle ground is so recalcitrant, and we’re ready to propose a theory.  
     It seems to us that the industry has never been clear about what happens over this stretch of an application. In the classic three-block system diagram, the area between "User Interface" and "Data Access" is usually labeled "Business Logic." But is that right? Business rules and procedures—what level manager can approve a salary increase, how widely-spaced trains on the same track need to be—are only a small part of what happens here. 
     Far more code is devoted to "application co-ordination," gluing together the back end and the front end so that they can interact. It’s a hard job because the two ends are so semantically mismatched. User input enters the system as tiny "atoms" of information— characters, fields, possibly pages--while the back end deals with large, complex data "molecules." Programmers spend their days individually mapping hundreds of small fields to their proper place in the large data structure that the back end can understand, evaluate, and store. Even a simple transactional application has at its center a warren of hard-wired, hand-built, application-specific connections that are time-consuming to construct and difficult to change. 
     After writing hundreds of these applications, we noticed that we were programming the same sorts of connections over and over. All transactional apps-- NewHire, DebitAcct, TransferInventory, or ScheduleShipment--share a set of generic co-ordination behaviors. Couldn't these be factored out, abstracted, and turned into a reusable component?  
     We envision a component called a "Proposal" that would fit between any user interface and any back end and handle the coordination between them. Basically, the Proposal would provide an intelligent framework that would let the programmer assign each UI field (or button-click, or menu choice, or whatever) to a certain level in a hierarchy. Then it would use this hierarchy to structure the transactional request automatically, with every bit of user input properly positioned.  
     In a Proposal-based system, the programmer’s job would become less like handicrafts and more like filling in the blanks. He or she would have a roadmap for a whole stretch of development that is now ad hoc, idiosyncratic and unpredictable. Development would speeds up dramatically.  
     And the resulting applications would be easier to use, because the reusable Proposal object could contains a lot of behavior that’s just too hard to implement when you’re doing each application from scratch: the ability to form transactional requests off-line, to work on a transaction collaboratively, to use Workflow, to swap in a new front end like a Web browser, to append annotations and keep versions. 
     As always, reuse is the key to faster and more accurate development. Thinking along Proposal lines can bring reuse to that tangled application middle that has swallowed so many millions of programmer-hours.  
 
Return to Kinexis Home Page