- 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
Analyzing the Problem: Task/Message Flow
So what is a task/message flow? An example is illustrated in Figure 1.
){kind=link}
Figure 1 A task/message flow for the original application.
If you know UML, you will recognize that the diagramming conventions are very similar to a UML sequence diagram (but it is about applications, not objects). Time flows down the page, and the diagram shows messages being sent from the user on the left side of the page to the application in the middle of the diagram. The little circles represent the state of the order form object that the application creates and updates. The black circle represents object creation; the orange circle represents object update. I also use a white circle to represent objects being read, and a black circle with a white circle around it to represent object deletion. From the information expressed in a task/message flow, it is usually possible to figure out what session state needs to be held.
Figure 2 illustrates the proposed solution to the Web order-entry project, also expressed in a task/message flow diagram.
){kind=link}
Figure 2 Web solution task/message flow.
The dotted rectangles in this example indicate tasks. There are two tasks: a "become a member task" and a "make an order" task. The two tasks can be separated in time and are not linked by the system, except that the membership data is used in the order-entry process. The square with a Q in it represents a queue to another system—in this case, it could be the manufacturing system.
Of course, there are other ways of implementing a Web order-entry system. This is an example solution, not the only solution. However, this decision is crucial to the implementation. The advantage of using a task/message diagram is that it provides a technique for discussing the alternatives before going further in the implementation.
The problem set out in this article is to make the new interface a front end to the old system. By comparing Figures 1 and 2, we can see the extent of the problem. For instance, the old application has no notion of membership, and billing details can't be entered outside the context of entering an order. The simplest solution is to hang on to the membership data in the Web server and pass it to the back end only later. This, too, can be illustrated using a task/message diagram, as shown in Figure 3.
){kind=link}
Figure 3 Proposed solution.
The gray rectangles represent computers (the rectangle on the right represents the computer running the original order-entry application). Again there are many other options. For instance, you could do all the old application calls from the last "complete" action.
The primary purpose of the task/message flow is to show the structure of the solution. The secondary purpose is to allow us to analyze the solution.
At least seven aspects of the application need analysis:
- Ease of implementation
- Scalability and performance
- End-to-end data integrity
- Security
- System management
- Flexibility analysis
- Future positioning
Typically, I don't do the analysis phase until we have chosen the technology (usually people are so eager to choose the technology that I can't get their attention until it's done). In some cases, there might be several technology options for analysis, as well as even several alternative task/message flows. The purpose of the analysis is threefold:
- Identify cost and risk factors that might lead the project to be refocused or even cancelled
- Critique and correct the task/message flow
- List additional factors that must be handled by the implementation
I will now describe each of the analysis tasks in more detail.
Ease of implementation is largely about whether the IT organization has the skills and resources to do the task. Whether there are existing components that can be reused in this project also comes into play.
Scalability and performance start with an analysis of the task/message flow to determine how many messages need to be sent at each point and how many transactions are processed. As a separate exercise, the data volumes need to be calculated. With this information, you can make a first estimate of the systems required and also can identify at least some of the potential bottlenecks. For actual sizing, it is always best to make the sizing estimate by projecting from similar systems of similar complexity rather than trying to calculate it from first principles.
End-to-end data integrity also starts from the task/message flow. Trace through the flow, step by step. At every point, ask, "What happens if there is a failure?" This is the key analysis step for critiquing the task/message flow, and it normally gives rise to a long list of points for the programmer to consider.
Security analysis starts from asking who needs to use the system. In a system-integration project, the existing systems will have their own security mechanisms. Suppose that you are integrating System A with System B. The question then becomes, how should users of System A be represented on System B? Broadly speaking, you can propagate the user information from System A to System B, or you can represent all users of System A as a single user to System B. These issues need to be sorted out early.
System management has many of the same concerns. The analysis done on performance, data integrity, and security will have given rise to a list of possible problematic scenarios. The question for system management is how to trap the key events early, report them accurately, and possibly fix them automatically. For instance, there should be monitors for every potential performance bottleneck.
The last two analysis points look to the future. Flexibility analysis involves thinking about how the system might need to change after the initial release. The technique is to brainstorm possible future extensions to the application. In this example, I would expect this analysis to consider whether the back-end interface is appropriate for other new interfaces, such as orders taken from a call center or from a mobile phone. They should also consider what would happen if the application was extended to other kinds of product. Note: I do not recommend trying to anticipate any future changes in the code, but I do recommend seeing whether there are structural impediments in the design to possible future change.
The final point is to consider the IT organization's long-term architecture goals. If IT strategy is for J2EE but the project calls for a .NET implementation, then perhaps the technology choice should be reconsidered. Alternatively, if the reasons for .NET are good ones, then perhaps the long-term strategy should be questioned. The second issue to address in this section of the analysis is whether this project could be used as an opportunity to move along on some long-term infrastructure plan. Of course, the impact on time scales and budget must be taken into account.