D5.1c Technology selection

Introduction

This document describes the results of the technology selection activity in the RENAISSANCE project. In many projects, the selection of technologies is informal, implicit and embedded in other activities. Our key objective in making the activity separate and explicit was to establish, early in the project, a shared vision of the technologies which should be deployed to support the overall aims of the project.

More specifically, making technology selection an explicit activity has the following advantages:

1. It supports the application-driven philosophy of the project. The technologies selected can all be clearly aligned with application requirements. We avoid the common problem of initial technology development which we later find is out of line with the application requirements.
2. It helps us to identify and focus on the key technologies and tools which should be integrated into the RENAISSANCE method. These technologies may be selected on the basis of identified technical need or on emerging market trends. This reduces the integration problems which often occur when technology selection or development is part of the development work of the project.
3. It provides a basis for shared technology understanding. While all partners had specialised knowledge of some technologies, there were no partners who knew about all relevant technologies. The activity provided easily understood technology information which allowed partners to assess the relevance of technologies to their own work.

The activity has achieved its objectives and we have selected a set of technologies and tools which are of direct relevance to the applications used in the RENAISSANCE project and which have significant market potential. We are confident that these are a firm technical foundation for the RENAISSANCE method.

How to read this document

The document is structured into 3 logical parts (5 chapters in all):

1. An introductory part (this chapter and Chapter 2) which introduces the work, summarises the technologies of interest and relates it to the application requirements.
2. Technology descriptions (Chapters 3 and 4) where we briefly describe the key technologies and tools which are of relevance to the RENAISSANCE method.
3. A glossary (Chapter 5) where we define terminology relevant to the RENAISSANCE method. This will serve as a project reference and will reduce communication problems in the next phases of the project.

We recommend that all readers should read this chapter and the summary of technologies and application requirements in Chapter 2. The material in Chapters 3 and 4 may be read more selectively, depending on the technologies and tools which are of most relevance to your work. Chapter 5 is for consultation and reference only.

Technology selection - key questions

To summarise our conclusions and to help readers understand the rationale for the results presented in the rest of the document, we have identified a list of key questions which relate to the activity. We present these questions and our answers to these questions here.

What are the technologies and tools which will be described in this document.

Technologies

Middleware, Componentware, Internet technology, Distributed object technology, Object-oriented development, System modelling (architecture and data), RAD/4GLs, Evolution management (including document management), Process support

Tools

CORBA, JDK, JOE, NEO, Uniface, SQLWindows, Magic, SeerHPS, System Architect, ProMod, Bachman Analyst, OORAM, MS project, Perform, REFINE.

How have the application requirements influenced the technology selection?

The application requirements have driven the selection of technologies. We have made an in-depth study of the specific application needs and used this to select particular technologies and, where appropriate, associated tools which should be incorporated in the RENAISSANCE method (see 1.1.5 which describes the process we used). The tables in Chapter 2 illustrate this by showing how specific requirements are linked to required technology support.

What are the principal motivations underlying our tool selection?

The principal motivation was practicality. Either:

The tool should already be in use by application providers. This meant that there would be no subsequent problems of tool purchase and that there already existed some expertise in the use of the tool. For example, Debis already use SQLWindows for rapid application development.

Application providers are considering the purchase and installation of the tool because of the capabilities that it provides. For example, Telesoft are considering the use of the SeerHPS system.

We have not included any tools in the list which fall outside these categories. All of the tools selected are currently available from established vendors and run on PC or Unix systems.

While we have identified specific tools, we see them as members of a class of tools and we anticipate that, in the RENAISSANCE method, these specific tools could be replaced by other similar tools (e.g. SQLWindows could be replaced by Visual Basic). We anticipate that we will choose a subset of the identified tools for demonstration in the RENAISSANCE method. We will also demonstrate how tools may be interchanged for other systems with comparable functionality.

How do the results here relate to WP3 and WP4?

Table 1 shows how the technologies selected are associated with activities in workpackages 3 and 4. Note that there is an overlap between tools and technologies and some tools/technologies are relevant to more than one activity.

There are, of course, other tools which are used by application providers (e.g. WinCap for reverse engineering). Although reverse engineering is an essential activity for many evolution projects, we have focused on tools here which are specifically relevant to the technical areas of RENAISSANCE. However, we recognise that related tools may be incorporated into the RENAISSANCE method.

Obviously Web browsers such as Netscape are also significant but these are so well known that we did not feel it necessary to include a separate description of them.

What process was used in this task?

We identified three key activities and set up a process to support these activities:

1. Technology awareness We needed to make all project partners aware of the technologies which might be deployed to support evolution and re-engineering.
2. Application relevance We needed to ensure that the selected technologies were directly relevant to the requirements of the application providers in the RENAISSANCE project
3. Information integration We needed to integrate the results of the previous activities and present them in an understandable way.

Technology awareness was supported by producing a set of technology briefing reports where we described a range of relevant technologies in a standard way which highlighted their relevance to RENAISSANCE. Each technology partner was responsible for producing some of these reports.

Application linking was supported by identifying 3 key partnerships between application and technology providers (Debis/SINTEF/Lancaster, CSH/CGInn, INTECS/ENG/TS). These teams worked together to identify the critical requirements and technologies for the trial applications.

Information integration was supported by identifying the presentation style based on cross-reference tables linking the applications and the technologies (presented in Chapter 2) and by planning this deliverable to present an overall picture of the work.

What has been done to involve tool vendors?

Tool vendor involvement is planned to start in the next phase of the project but, obviously, identifying tools and exploring their capabilities has meant that we have already had some preliminary contacts with tool vendors. We have discussed the RENAISSANCE project with the following vendors who have already expressed interest in possible participation:

• Select, Cheltenham, UK (CASE tools)
• Taskon A/S, Oslo, Norway (OO development, CASE tools)
• Compuware, Amsterdam, The Netherlands(Uniface 4GL)
• Alur, Clichy, France (WinCap, Reverse engineering)

We have also made initial contacts with more than 20 other tool vendors and have distributed information about RENAISSANCE to them. These include the vendors of most of the tools which we have described in this document where it seemed that these vendors were likely to be interested in reengineering. Further contacts with tool vendors are currently being planned.

What have been the major problems encountered?

The major difficulty which we have encountered is the heterogeneity of the technologies and the tools used by the application partners. When we started in the task, we hoped that there would be some overlap between the different tools and technologies used in different applications so these would be the obvious choices for inclusion in the RENAISSANCE method.

We discovered in our investigations with application providers was that there was a very significant overlap in terms of the technologies and tool types which were used. However, this was not true for specific tools where every application partner was interested in using different tool. We must respect their commercial judgements in this respect and we therefore decided that it was impractical to base the RENAISSANCE method on a limited and specific set of tools.

Of course, this places a critical requirement on the development of the RENAISSANCE method. The techniques used cannot depend on any specific tool or set of tools. While this is limiting in some respects as it means we cannot take advantage of particularly useful tool facilities, it means that the overall marketability of the method will be enhanced.

What are the key growth technologies which will be important for future exploitation?

We believe that there are four related technologies whose use will develop significantly in future:

1. Intranet as organisations migrate centralised systems with character-based user interfaces to distributed, server-based systems accessed through the graphical interfaces provided by Web browsers.
2. RAD/4GLs as applications written in COBOL and other third-generation languages evolve away from mainframe-based systems to client-server systems based on Unix or Windows/NT servers and PC clients.
3. Componentware as organisations are driven by the need to conform to standards and to reduce systems development risk and costs in replacing parts of legacy systems.
4. Distributed object technology as organisation re-organise their system architectures from centralised to client-server and exploit the availability of componentware.

Because of their potential market significance and the possibilities of future commercial exploitation we will ensure that these technologies are taken into account in the development of the RENAISSANCE method.

Are there unresolved technology questions?

There are a number of technical questions which remain unanswered but which we feel are important and which we will consider in the next phase of the project. These have not been considered because they are not of immediate relevance to the applications which will be the RENAISSANCE testbeds.

However, from the leverage that the RENAISSANCE project has already provided, we have had discussions with other organisations regarding re-engineering projects and the following issues have emerged:

1. To what extent must we consider the server operating system in the development of the method? It is clear that the majority of servers will normally be based on Unix or Windows/NT - we must ensure that our work is applicable to both of these alternatives.
2. How can we support the increasing demand for end-user programming based on re-engineered applications? As servers are created by encapsulating legacy systems, there is the potential for end-users to collect raw data from these servers and develop their own simple applications using tools such as Excel and Visual Basic.
3. How will the introduction of Internet terminals (e.g. Sun's Javastation) influence the requirements for legacy system reengineering? This is particularly important for legacy systems as the cost of migrating character-based user interfaces to GUIs is likely to be much cheaper for Intranet terminals than for PCs.

What lessons have we learned from this activity?

1. RAD and 4GL technologies are seen as very important by all application providers. This is true whether or not the legacy systems are written in old 4GLs or in 3GLs such as COBOL. While we will consider 3GL to 3GL reengineering, the work in this task has confirmed our initial impression that an emphasis on the use of 4GLs for reengineering is the right approach to adopt.
2. Application developers are not interested in a method which is based on specific or proprietary tools. They wish to have a 'plug and play' approach where they can deploy familiar tools for method support. When considering method support, therefore, we must select a representative set of technologies and tools and base the method around this representative set. Because of the similarity of tools, we must ensure it is relatively easy for users to replace a tool in this set with another of the same type.
3. While it is critically important that the project should remain application driven, it is also important that we take accelerating market trends into account. If we do not do so, we may end up in an exploitation backwater and limit the scope of future use of the RENAISSANCE method.

   The most clearly emerging market trend is the use of Intranets to support organisational information systems and the consequent reengineering of legacy system. We are convinced that we must consider and assess the impact of Intranet technologies for reengineering because of the market interest in these technologies and their potential for user interface reengineering. This implies that we must ensure that our portfolio of testbed applications is sufficiently diverse to provide coverage in this area.

   However, it is not clear at the moment which specific tools and technologies in this area will emerge as market leaders. For example, Microsoft have recently introduced ActiveX as a competitor to Java and it is not clear if these technologies will co-exist or if one or the other will become dominant.

4. Important benefits can be attained by combining technologies (e.g. componentware + Intranet + distributed object technology). Therefore, we must be careful to ensure good communications between the activities in WP3 and WP4.1 so that we can identify and capitalise on important synergies which emerge. A critical issue here is how 4GL technologies can be integrated with other technologies? We suspect that we will have to address this on a case-by-case basis for the 4GLs used in RENAISSANCE as there are no standards which these languages conform to.
5. Users are obviously interested in object-oriented techniques and methodologies and there is an increasing market in this area. Current OO tool suppliers (e.g. Select and Cadre Technologies) see the reengineering market as significant and wish to expand into this area. There is an opportunity here for the RENAISSANCE project to make a significant impact as there is currently no methodological support for OO reengineering.
6. The publicity given to business process reengineering and the use of workflow technologies has meant that more and more organisations are aware of the notion of 'process' and the need for targeted process support. The implication of this for 'selling' the RENAISSANCE method is that we should not adopt an approach which is 'technology-centric' but which emphasises the opportunities it provides for reengineering existing maintenance processes.