We worked with different customers in order to set up properly an efficient and working ICC (Integration Competency Center).
Within an ICC is fundamental to set up a proper delivery process. It becomes even more important if the factory working model is going to be applied. Below there is a delivery process implemented in one of our customers in order to have the ICC working properly.
1. Sit with the stakeholders. The ICC members (mainly the integration architect and in some cases also the domain manager) sit together to have clear ideas on what the project wants to achieve. The discussions are about business requirements and end-to-end system involvement.
2. Analyze possible solutions. The integration architect collects all the details and tries to draw a high level picture with the systems involved and the effort required to do this. In case the ideas and the requirements are not clear it might be useful to iterate the steps number one and number two.
3. Submit a quote for a technical solution. The integration architect finalizes the high level picture of the system involved and define the effort to build it. Together with the domain manager generates a quote to submit at the project, in order to get the approval on it.
4. Get approval from the project. The quote, with a high level picture of the final technical solution, is submitted to the project. The project can either accept or reject it. In case of rejection it can lead to an iteration phase where the doubts and the scope are better clarified. It can happen that some functionalities are not required or can be bypassed using similar existing services. In this last case the process comes back to step number two and the process proceeds further. It can also happen that the project doesn’t have enough budget to implement the solution, so in that case the flow doesn’t proceed anymore and the project will be charged only for the initial effort to cover the integration’s architect and domain’s manager costs.
5. Make a delivery plan based on the resource’s availability. When the ICC quote has been approved, the domain manager checks the resource’s availability and propose a delivery plan to the project. In case the project has different expectations then it has to check with the domain manager whether or not the whished date can be met. At the end the delivery plan has to be approved in order to move forward.
6. High level design. This document describes more in details the technical solution architecture implemented within the boundary of the ICC. This document describes:
- the communication flow between the systems involved in ICC
- the integration flows that meet the functional requirements
- a match with the use cases described in the end-to-end design
- any note that can help the technical design to apply a specific design pattern/solution
This document adheres to the “The ICC architecture guidelines” set within the ICC. Before to be issued as final version has to be reviewed by a peer architect. Subsequently a “hand-over” session is organized with the designer(s) that will take part in the technical design. This phase is important to guarantee a common understanding of what will be implemented.
7. Design phase. In this phase a technical design is produced for each system/adapter involved in the project’s scope. The outcome of this phase is a technical description of the adapter behavior with a technical design pattern. The technical design is written following “The ICC design guidelines” and before deliver it to the next step/team a peer review is required. When the final document is ready, it will be planned a “hand-over” session with the development and the testing team. The hand-over session will explain the content of the technical design (i.e. made by a service’s description, interface, process diagram and schemas). This session is important to have an idea of what has to be done and start the preparation of the test plan.
In some circumstances it’s also beneficial to have a “hand-over” session with the stakeholders external to the ICC that will consume the services exposed. In this way it’s still possible to adjust the design before start the development phase.
8. Development phase. The development step is performed in adherence to “The ICC development guidelines”. At the end of this phase a peer review is foreseen and a unit test report has to be filled up. In the development phase are built also stubs for the back-end systems, in order to supply a dummy response and simulate the behavior of the back-end application.
9. Testing phase. During this phase a test plan is executed, in order to verify the code behavior against the functional requirements. This test represent a system test phase where the back-end behavior is simulated using stubs. In case there are bugs, those are reported either to the developers’ team or to the designers’ team. At the end of this phase a report is filled up with results of the testing and the sample messages used to call the systems. In case there are some known issues those are highlighted as well.
10. Packaging and delivery. The final step is to deliver the package with all the things/artifacts related to the project, like:
- Software package (e.g. archives, scripts…)
- Release note
- Technical documentation with the component’s description behavior
- Test case report and sample messages used
11. After care and defect management. The aim of this step is to support the delivered package during the integration test phase and the acceptance test phase, till the package reaches the production environment. During this phase, any defect, raised against the ICC team, has to be analyzed and in case it’s an ICC bug than it has to fixed. The defect can be either rejected or accepted and fixed in a proper way. If the bug is recognized, either as a design or development bug, then the process starts again from the specific team either the designer or the development team. All the steps are re-executed till the delivery of the solution, using a bug fix release.
