Balance the Stakeholders
10 Oct 2003Introduction
A software project typically contains a number of stakeholders with conflicting interests. We will have a look at the stakeholders that are normally involved in a software project, the relationships between them and the impact on the project result.
Stakeholders
The characteristics of a stakeholder are: (1) a goal, the stakeholder wants benefits from the project. A (2) limit. There are bounds to what is possible.
- The customer. This is the most important stakeholder he is the raison d'être of the project. The customer can be an other company, but it can also be a division within the same company. Its goal: get software with lots features or functionality in it that are useful for the business. The limit is determined by the budget.
- The hardware vendor. The goal is to sell as much hardware as possible. It includes computers, network infrastructure, and storage.
- The software vendor. The goal is to sell as much software as possible. It includes database software, user management software, application servers.
- The functional analysts. The goal is to document as much of the business's functionality is possible.
- The architects and developers. The goal is to create an application, and to realize as much functionality as possible.
Balance
The technical team is in a unique position that it creates the software that will be used by the customer, the team will be held responsible for the end product. On the other hand, the technical team is dependent on the other stakeholders for creating the application. I suggest that the architects should be involved early in the project in order to enforce the limit on the stakeholders and to assure that the application is built.
It is a common mistake to serialize the development process. Often the selection of hardware and software is already being done before the functional analysis starts. The analysis should be a description of the "things" that could be implemented in software, and not a description of how it will be implemented. The models that are created during the analysis phase are considered to be a design ready for implementation. The developers are expected to turn this into a working application.
The architects should assist the customer throughout the complete project, it is a mistake to limit their role to steer the development. The architects have the technical expertise to help the customer to evaluate the hardware and software solutions. The architects should help the customer to buy enough hardware and software for the project to be a success, no more, no less.
The functional team and the architects will have to work together to bring the project to a good end. The functional team can create data models and use cases or other procedure like descriptions in order to tell the store of the business. It is their task to describe what the customer wants. These models should never be used as an application architecture because the analysis describes the "what" and not the "how". The problem is that if the functional team crosses this border the project is in danger. The functional team will not develop the software so in the end they will not be responsible for the software construction. So it is very easy for them to create models that are not 100% exact or that are not very realistic. In fact the more features the functional team describes the happier the customer.
The architects should prevent this situation. Throughout the analysis, the architects should make clear that the functional models are fine for telling a story, but that they will have to be synthesized into an application architecture that will be the blueprint for the application. There is a world of difference between the functional story and the technical plan. Before the functional team makes its promises to the customer, they should be evaluated by the architects. The architects enforce a limit to the functional team.
There are a number of techniques to do this. First of all, the architects have the knowledge to translate the requirements into a real solution. There are always multiple solutions to structure an application, all solutions have to be evaluated before making a final decision. The final decision can be postponed it does not have to be taken before development starts. After the solutions are documented, they can be tested by implementing a number of prototypes or spikes. The architects will be able to pinpoint the parts in a solution that have high risk. It is these parts that should be prototyped and tested. In the end, the analysis made by the functional team has to be balanced with a number of solutions and eventually some prototypes.
The choice of hardware depends on the characteristics of the application. The hardware vendor will be able to make a good estimate, they are experts in calculating the capacity that is needed. The architects should check these calculations using the solutions they have in mind. The prototypes can be used to see which hardware configuration satisfies which solutions. The result is a number of hardware/solution tuples.
Exactly the same thing can be told about the software vendors. The result is a number of software products that help in realizing the solutions. Some solutions will become more or less feasible because there is or isn't any supporting software that can be bought.
Finally one of the proposed solutions will be chosen, and the architects will create it together with the development team. The architects will be balanced by the fact that they will have to deliver a working application to the customer.
The architect should not be the same person as the project manager. In fact I did not mention the project manager as a stakeholder on purpose. It is the ultimate goal of the project manager to make sure that the stakeholders are balanced by the architects.
The Process
The balancing act is a continuous one. It is a mistake to see the project as a serial process of functional analysis, architecture and implementation. In the very beginning of the project there will be such an iteration to get started, but multiple iterations should occur. The first iteration should outline the project, and should enable the architects to make the first design decisions and to create the first blueprints. These first products should be reviewed while more and more information becomes available, the architects can steer in which area more information is needed at a certain point in time. Prototypes can eliminate some of the solutions, can provide the experience to think out new strategies. The first phase of the project partly analysis, partly architecture, partly development (of prototypes), its goal is to have a limited number of blueprints, and to make clear what functionality can be implemented given a limited budget.
After this phase, a number of sub projects can be defined, each with its own goal and time line. The sub projects should be created in the context of the total architecture. The functional team will have to gather the details for each subproject, the architects will put more detail in the blueprints, and the development team can realize them. The experience on one subproject should be fed back into the following sub projects. In fact the iterative cycle of analysis, prototype, development is applied in a recursive way.
Conclusion
The architects should assist the customer throughout the project, the customer should use the architects to guard the technical feasibility of the project.