CURRENT CHALLENGESPROBLEMS FACING THE ORGANIZATION

CURRENT CHALLENGES/PROBLEMS FACING THE ORGANIZATION

Once the solution was specified, the main challenge resided in the successful implementation of the proposed solution. The choice of the implementation environment was a key influencing factor for success. It is the company's policy to outsource IT development efforts as much as possible. The requirements engineering task is done in-house, but system realisation should be done by buying off-the-shelf software or by outsourcing. In addition, coding efforts should be limited by utilising code generators where possible.

Considerable complications resulted from the implementation environment that was chosen by the company: an application development tool that generates Enterprise Bean code, but that is nonetheless not fully object-oriented. In fact, by no means can it conceal its origin in the relational paradigm. Its so-called "objects" actually behave like single rows in a relational table: they are interrelated by means of foreign keys (instead of object identifiers) and lack the concepts of subtyping, inheritance and real behaviour. Moreover, whereas MERODE defines shared participation in business events as the enterprise objects' means of interacting, the tool only supports event notification at the level of inserts, updates and deletes. These are not very suitable for modelling business events: they pertain to the actual changes to rows in the database but do not carry information about which business event induced the change, ignoring the possibility of different underlying semantics, preconditions and constraints. Therefore, whereas an almost perfect mapping existed between concepts from the MERODE based Enterprise Model and the proposed EJB architecture, several of the MERODE model's subtleties were lost when being translated into the design environment.

Furthermore, MERODE advises a "transformation"-based approach to implementation: the transformation is defined by developing code templates that define how specifications have to be transformed into code. The actual coding of an Enterprise Model is then mainly a "fill in the blanks" effort. MERODE provides a number of examples for transformations to purely object-oriented program code. Also a lot of experience exists with transformations to a COBOL+DB2 environment. Transformation with a code-generator had never been done before.

Two additional elements were important in further evolution of the project. The company had explicitly opted for the development method MERODE by asking the MERODE team for assistance in the project. Although the method is in use by several companies and has in this way proven its value, it is not widespread enough to assume that it is known by the programmers of the implementation team. In fact, no members of the implementation team were acknowledged with the chosen modelling approach MERODE. The same was true for the members of the consultancy team of the company providing the implementation environment.

Finally, on the longer term there might be a problem of domain model expertise. Initially, it was agreed that the company would appoint one full-time analyst to actually do the requirements engineering. The university team would advise this person. However, due to shortage on the labour market, the company did not succeed to find a suitable candidate. As a result, the requirements engineering has completely been done by the university team. Consequently, valuable domain model expertise resides outside the company.