|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Growth went in several directions simultaneously. The architecture had to be finished to include more core functionality of the domain. Other development groups have to become involved, both as users and as engineers, the latter as members of the architect's network and software community. Existing functionality within other products has to be migrated to the platform. In addition, 3rd party software was selected to be included in the platform as well. Presently more than 10 product groups use the platform. Growing the architecture and the functionality of the platform implied the inclusion of many interfaces and components. Often they included existing functionality, in many cases improvements of existing software and even new software. Care is taken that during the whole evolution of the platform it consists of live components and interfaces, i.e. after first component or interface release there is always a working version available, which can be used by anyone who needs it. No component is released, if it cannot be used with the other components in the platform. The data models were always growing including the requirements of the new functionality that have to be provided. In addition, the data models have to be living. For each model element, there are components using it. This property, of live components, interfaces and data models, is crucial to be able to build and test software upon a basis of already existing, and tested software. There is a continuous activity to update the roadmap and plan the platform activities, to get an optimum benefit of the platform development for its increasing group of users. Each customer has its own roadmaps, which involve planning when and what to use of the platform. No one is forced to use the complete platform. Every group is able to decide the pace of the evolutionary introduction of the platform within it own developments. The business model of the platform development does not aim to make the maximal profit for the platform group. The product groups together fund the software development of the platform. They get the platform software much cheaper than if they would have developed it themselves. Although the platform software is more generic than what they need, it is also of better quality, since it is tested within many distinct software product lines. We have seen a rapid decrease in problem reports from product groups after release of platform components. We see that the platform components are build with about 1.6 times as many people as was necessary what the product groups themselves would have used. Since there are several product groups using the platform, each of them has to pay only a small part of this 1.6 factor. The platform development group is the one that is responsible for outsourcing software. This single contact point with external software suppliers eases the burden of getting this software according to the architectural standards defined by the platform. < Previous page . . 1 2 3 4 . . Next page > |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||