The initiative started small, with few people and gradually involved more people and product groups. However, from the very beginning, real projects were involved as users of the (incomplete) platform, and the architects of all involved product groups were responsible for the architecture. This enforced commitment between the different product groups. Development of the software community at company level is an essential element to promote reuse on the long term.

The initial ideas of producing a medical middleware platform emerged in 1997. In 1998, the common architecture was determined, and the production of the first software components was started. In 2001 the first version of the platform was released, and used by the first product lines. After that, the number of product lines that use the platform has increased.

From the start in 1998, shared architecture meetings were organized. Architects from different development groups discussed the options and problems of moving towards a shared platform for all.  In the mean time, business commitment for initiating the reuse program for system lines was obtained. The department directors appointed a program manager for the platform development.

The only way to perform the transition to a widespread use of the platform was to start with a small basis and extent it in an evolutionary way. The product groups should stay in business during the transition, and revolutionary approaches were not feasible. The architecture and components are based upon existing software in the products, and transformed into platform components on a piece-by-piece basis.

From the start, the different product groups have their own pace in adopting new technology.  The components in the platform are as orthogonal as possible from each other. This eases the transition since product groups can initially select only the platform functionality that they really need.

The reference architecture is based upon Components, Connectors, and Semantics (CCS). Components are the reusable units of the architecture, to be selected, configured and used by the platform users. The connectors are the interfaces which are much more stable than the components themself. All users connect to the platform components through the interfaces. The semantics are captured in information models, which improve the stability of the interfaces. The information models are used to interchange data over the interfaces. Therefore, the data semantics do not reflect themselves in the interfaces and thus these interfaces can be designed to deal with generic data access functions only. In particular, data access is abstracted in a uniform way, independent of whether it resides on the network, a database, a file, or other media.

< Previous page . . 1 2 3 4 . . Next page >