This chapter is from the book
This chapter is from the book
This chapter is from the book
7. Framework User Involvement
Problem
How can you make sure that members of the other teams will be able to use your framework when they build their applications?
Context
You have completed a first version of the framework. It’s now the application developers’ turn to use the framework in their applications.
Forces
Other teams depend on your framework in order to complete their applications—that is, to be successful in what they’re doing. They want to know what the framework does and how it works. That’s fair enough; you should let them know.
Empirical studies have shown that most people are willing to reuse software if it fits their needs [Frakes+1995]. You can therefore assume that the other teams are generally willing to use the framework as long as you can convince them that the framework offers the necessary functionality and that using the framework is easier than developing the functionality from scratch.
Moreover, frameworks often trade efficiency for flexibility, at least to some degree [Fayad+1999]. When efficiency is critical, applications built with the framework may need some fine-tuning. They may also have to replace certain generic mechanisms with more concrete and more efficient ones. In any case, users might need help using the framework or even customizing it a bit.
Ultimately, it’s your goal that the other teams use the framework successfully. If they don’t, the failure will be blamed on you, the framework team, rather than on them, the application team.
Solution
Involve the teams that use your framework.
You must show the users how they should use the framework. The users must get an understanding of the framework’s feel, so that they understand what they can and what they cannot expect from the framework and how they can integrate it into their applications.
Possible actions include:
- Run common workshops. Explain the steps that users have to take when they build applications with the framework.
- If possible, provide tools that support the framework’s instantiation process and demonstrate how to use these tools.
- Provide examples of how an application and your framework collaborate.
- If necessary, show the users how to optimize the applications they are building using the framework.
- Prepare tutorials and documentation and make them available early. Make sure the documentation directly addresses the framework users as its Target Readers [R_ing2003] and maintains a Focus On Long-Term Relevance
- [R_ing2003]—things that application developers will need to know in the long term, when the framework team might not be available anymore on a day-to-day basis.
- Combine written documentation and interactive workshops with the application developers to establish an atmosphere in which team members can share information of different kinds and formats—an atmosphere that can be described as an Information Marketplace [R_ing2003].
The drawback is that involving the users a lot costs a lot of time and will probably take place while the framework is still developed further. You must make sure that framework development doesn’t grind to a halt while you’re busy running workshops.
Examples
The Data Access Layer Framework
After the release of the first version of the framework, the framework team had a two-week workshop together with the team that developed the health insurance system. The health insurance team wanted to know what they had let themselves in for—how they could use the framework. The framework team showed them and at the same time had the opportunity to fine-tune the two-dimensional versioning of application data, since it was tested with real-life examples for the first time.
At some point, the framework team learned that the commission system had special efficiency requirements. The commission system team had to define a sophisticated mapping of business objects onto database tables—more sophisticated than could be defined in the framework’s meta information. Both teams discussed a way to extend the data access layer of the application with a special module that implemented the special mapping.
The framework team provided a usage document that explained the necessary steps that application developers had to take to configure the framework and to use it in their specific context. The document was helpful, especially in combination with workshops like the ones just mentioned, in which the application programmers were shown how to do what was written in the document.
The Web Portal Framework
The project managed to integrate the life insurance system and the customer system into the Web portal, despite the portal’s relative complexity. Crucial for this success was the fact that the framework team and the application development team had offices next door to one another and that they were able and willing to collaborate closely. Informal communication was no problem, and communication channels were fast. The framework developers were available all the time to answer questions from the application developers. Actually, the framework developers and the application developers felt they were one team, sharing the common goal of bringing the portal to life.
Discussion
Unlike the collaboration with the Pilot Applications (4), this pattern doesn’t put the emphasis on how the framework team can learn from the framework’s users (although it’s fine if they do). The focus here is to provide a service to the users and help them.
Involving the users and working jointly on their tasks is generally acknowledged as a successful strategy to use to achieve this goal. In particular, this is true of frameworks, due to the additional level of abstraction and the sometimes non-trivial instantiation process [Eckstein1999].
Moreover, listening to the users, running common workshops, and so forth, helps to Build Trust [Rising2000]. Trust is important because the users will view your framework as a third-party component; they will only be successful building their application if the framework works as it is supposed to.
When you explain how to use the framework, using design patterns is often useful, since they describe typical ways in which application programs can be put together [Johnson1997]. If you consider developing a tool that helps users build applications, keep in mind that a complicated mechanism is probably not justified. However, a simple script, perhaps based on object-oriented scripting languages, might save a lot of work [Ousterhout1999].