This chapter is from the book
This chapter is from the book
This chapter is from the book
4. Pilot Applications
Problem
How can you detail the requirements for your framework?
Context
Work on the framework has begun. You’re in the process of defining the framework’s functionality. At the same time, some application development teams have already kicked off, while others perhaps haven’t started yet.
Forces
There is some functionality that several of the applications-to-be will have in common. They will use it in slightly different ways, but they will share a set of common abstractions. However, none of these applications have been built so far.
You’re locked in some kind of chicken-and-egg problem: The framework team needs to know quite a bit about the applications to be able to define the framework’s functionality, while the application development teams rely on the framework to build the applications. It’s hard to come up with the requirements for the framework in such a context.
Still, you have to find the right abstractions for your framework.
What makes things even more difficult is that different application development teams will place many, possibly conflicting, requirements on your framework. You’ll have to prioritize those requirements in order to achieve a consistent framework design. If you try to please everybody, the framework will become very complex and might ultimately become a failure.
Solution
Discuss the framework’s functionality with several pilot applications that are going to use the framework.
The pilot applications will use the first versions of the framework as soon as they are released. This may well include versions that feature only a partial functionality or that are otherwise still constrained in their usage. In a way, the pilot application developers act as beta testers and provide valuable feedback to the framework team.
In most cases, two pilot applications are appropriate. One pilot application alone might not be representative, and perhaps you cannot say whether a required function is crucial or just nice to have. On the other hand, three or more pilots might simply become difficult to handle. Two pilot applications still seem manageable, and it’s unlikely that important requirements go unnoticed.
Keep in mind the following when choosing pilot applications:
- The pilot applications must be fairly typical of others that might use the framework.
- The pilot applications should be significant, so that the framework team keeps in close touch with some of the framework’s premier users.
- The pilot applications must be applications that are being built relatively early in the time frame of the overall project.
Collaborating with the teams who work on the pilot applications will increase the knowledge exchange in both directions; you’ll get feedback on how good your framework is, and the other teams will learn how to use it. Pilot applications will also force you to adopt a policy of early delivery, which is a well-established strategy for project risk reduction [Cockburn1998].
Unfortunately, pilot users can get the impression that they’re doing your work when they use the framework at a very early stage, when its functionality is still incomplete and has a few bugs. Be aware of this, and make clear to the pilot users that in return they have the chance to influence the system they’ll have to use.
Examples
The Data Access Layer Framework
Among the new systems, the health insurance system was a very typical one. The framework team had many discussions with the team that built this system. These discussions particularly helped shape the understanding of two-dimensional versioning of application data—versioning that makes a difference between when a change becomes effective and when it becomes known. It’s a subtle topic, and it was quite significant for the requirements analysis and for the framework design in the earliest stage of the project.
The framework didn’t feel on safe ground, though, until they got into detailed discussions with the team who built the new customer system. The new customer system had slightly different requirements on application data versioning. Both systems complemented each other well as far as architectural requirements were concerned.
The Web Portal Framework
The life insurance system and customer system served as pilot applications for the Web portal framework. This was clearly a good choice, since these applications were typical for the portal’s usage. For instance, a typical use case is that of a bank assistant who looks up a customer in the customer system and recommends certain life insurance products to back up a bank credit. This typical use case involves exactly the two applications that were chosen as pilot applications. The framework designers received a lot of input from collaborating with the application developers.
Discussion
Collaborating with the pilot users is a kind of Framework User Involvement (7), but it’s actually more than that. Involving the framework users has the primary goal of achieving a better understanding of the framework among the users once the framework is released, whereas the knowledge exchange with the pilot users is bi-directional.
Prototyping is a strategy generally approved of in the literature on reusable software. Brian Foote and William Opdyke recommend to Prototype A First-Pass Design [Foote+1995] when the goal is to design software that is usable today and reusable tomorrow, as is certainly the case with frameworks that are developed with large-scale reuse in mind.
The importance of feedback from users is generally acknowledged. In his generative development-process pattern language, Jim Coplien stresses that it is important to Engage Customers [Coplien1995], in particular, for quality assurance, mainly during the analysis stage of a project but also during the design and implementation stages. Along similar lines, speaking of customer interaction, Linda Rising emphasizes that It’s a Relationship Not a Sale [Rising2000]. Speaking openly with customers—the framework users in this case—will give you valuable feedback about your product.
The pilot applications are not only useful for finding out the requirements for the framework; they also form the precondition for setting up Pilot-Based Tests (6).