Lightweight Methodologies for New Interfaces
- Two Constrasting Existing Approaches
- The 1,000 Lines of Code Rule
- Analyzing the Problem: Task/Message Flow
- Team and Phasing Structure
- A Range of Methodologies
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Pick up any book on a design methodology, and chances are good that it will cover only new application development. The underlying assumption is that the project starts from gathering requirements and ends with a standalone IT application. But most projects these days aren't like that; there are few green field sites left. Most reasonably large projects have at least some element of integration with one or more existing applications. In this article, I will work through a systems integration example, examine some of the issues with existing methodologies, and present an alternative.
The problem that I will discuss is putting a Web interface on an existing order-entry system. I am not interested in one-to-one conversion of the old green-screen forms to a Web form equivalent; I want a new Web interface that works like a proper Web system. In particular, I'll assume that the marketing guys want the customers to register as members before they can order anything.
Two Contrasting Existing Approaches
If I were an extreme UML modeler, I would start this project by building a UML model. Immediately, I face a problem: How should I represent the existing system in the UML model? I don't want to reverse-engineer a complete UML model out of the existing system because that would be a great deal of effort for little gain. I would like a UML model of the pieces that I need for integration.
All I really know about the existing system is how the interface works, so my minimal model is to express the existing system as a single component. However, because the existing interface manages session state, it stands to reason that I also should model the state transitions. But I can't do this without an object (only objects have state). Moreover, I can't represent collaboration between the new Web application and the old system without identifying objects in the old system (collaboration is only between objects). So, I find myself doing some object modeling in the existing system, whether I like it or not. (Perhaps I'll cheat and define one big object for the whole of the existing system.)
Having derived the model for the existing system, I need a model for the new application, and now I face a new problem: What are the objects in the new model? Several candidates spring to mind: the HTML page generator, the whole Web application, or maybe the sessions. But the purpose of modeling is to have a 10,000-foot view of the design, to understand the structure without being lost in the detail. With a good model, I can examine the options in more detail, fully aware of the large-scale structure and rules that I must support, whatever the implementation is. The beauty of object analysis is that it helps align objects in the problem domain with objects in the solution domain. But objects such as HTML page generators are deep in the undergrowth (the 10-foot design view) and are all firmly in the solution domain, not in the problem domain. The model not only fails to give a large-scale view, but it also is in danger of becoming a program in diagrams.
If I were an extreme programmer, creating a program early would be my aim—and, unlike programming in diagrams, I can execute my program, test it in units, and test it in assembly. I probably would address the technical challenges of this problem by implementing an "architectural spike" (the extreme programming equivalent of a proof-of-concept study). I would address other architectural issues by ad-hoc team design. One striking difference compared to the UML modeling approach is the willingness of extreme programmers to refactor (rewrite the code without changing the functionality) when the design is found to be deficient (which it will be).
But I am not at all sure that following all extreme programming practices is feasible for this application. Extreme programming practices demand that the user be available all the time. The users here are wide ranging—they include the customers themselves, the business managers for the order-entry system, marketing personnel, the network administrators, the security administrators, and IT operations for the existing system. Not all these users will be available, and one person cannot represent such a diverse group. In addition, a tenet of extreme programming is to move people around, but this implies that all the team members have a uniform skills base. An integration project relies on many specialists. That said, the extreme programming idea of pair programming is very attractive and will help protect the organization from a key individual leaving.