Section 17.2. Implementation


17.2. Implementation

In this section, we describe the key implementation details of the Intelligent Finance project, including the service implementation concept, service repository, and project management.

17.2.1. XML SERVICES

Because of the extremely tight schedule and the high integration requirements of the multi-channel architecture, it was decided early on in the project that existing EAI blueprints and middleware technology would not be suitable for this project, due to their long and complex implementation cycles.

XML had just emerged as a new and flexible toolkit that enabled high productivity and provided very good ad-hoc integration features. It was therefore decided to use XML as the lingua franca within the technical architecture. However, although the great flexibility of XML provided a huge benefit over more stringent integration technologies such as CORBA, this flexibility also represented a problem in many respects. Especially in an environment where requirements are changing on a daily basis, it is often tricky to strike a good balance between flexibility and strictness.

Approximately 250 different service request types exist in this system. A way was needed to leverage the XML technology to model the behavior of the Intelligent Finance banking engine, which was at the heart of the system architecture. WSDL and SOAP were new standards at the time, but the architecture team decided to adopt them to specify the interfaces of the banking engine anyway. The often-problematic experience with distributed object systems that the architecture team had made in many previous projects naturally led to the adoption of a Service-Oriented Architecture. Even if the term was not defined at the time, the underlying concepts were applied in the design of the bank.

17.2.2. SERVICE REPOSITORY

Intelligent Finance uses the CCC Harvest source control system as the central service repository for all service definitions used by the project. All services are defined as XML Schema definitions and WSDL definitions.

The service repository and the service definitions in it are managed by a technical architect who holds the role of XML Tsar (this role is described in more detail in the following project management section). The XML Tsar works with the different development streams as well as the business side to develop and maintain the service definitions.

The content of the service repository is used by the IF.com build manager to generate type-safe APIs and stubs for a variety of different programming languages, including Java, C++, and VB (see Figure 17-5). These stubs enable client- and server-side programmers to write service components and access them in a transparent way. These stubs are managed in separate repositories together with the actual source code of the application. One can debate whether it makes sense to actually manage the generated code in a repository because one should be able to regenerate the stubs at a later point in time. However, there is a danger that the exact version of the compiler used for the particular build in question might not be available any more, and therefore there is a danger that one would not be able to reconstruct an older version of a build. For this reason, it was decided to include the generated code in the source code repository.

Figure 17-5. IF.com service repository.


17.2.3. PROJECT MANAGEMENT

The huge scale and extremely ambitious schedule of this project put significant pressure on project managers. Starting from scratch, the Intelligent Finance management team had to build the entire Intelligent Finance organization, including HR, sales, marketing, legal, IT development and operations staff, call center staff and management, and the banking back-office. In parallel, every piece of infrastructure had to be put in place from scratch, including offices for the development team, plus the acquisition of two new buildings for the call center and banking operations. In addition, communications infrastructure had to be put in place, including telephony and IP networks.

17.2.3.1 Design in Action

The IT implementation project was probably the most critical and most complex piece of the puzzle. The basis for the IT implementation project was the Design in Action plan (DIA). The DIA was created in about eight weeks, providing a detailed outline for addressing the key challenges of the project. The DIA included the blueprint for the multi-channel architecture of the bank, the banking engine with the balance netting features, and the backend integration. The DIA also provided a delivery program, including mobilization plans, training plans, and an outline of the required systems infrastructure.

The implementation of the mobilization plan took about three months, at the end of which 500 technical staff were brought on-site to the new development center, plus a large number of on-site technicians from IT systems suppliers.

17.2.3.2 Work Streams and IT Steering Committee

A cornerstone of the project management strategy was the division of the project into 23 different work streams, including banking engine, architecture, service design, DB design, workflow, mainframe integration, Web design, call center, and so forth. This structure helped to reduce some of the hugely complex dependencies between the different tasks that had to be executed in parallel.

An IT steering committee was responsible for coordinating the work of the different work streams. The steering committee consisted of the managers from the different work streams plus members from the business side and the architecture team.

17.2.3.3 Architecture Board

The architecture board consisted of six senior IT architects who were responsible for the overall design of the new bank. This included the system hardware and software infrastructure, the design of the XML service middleware, the service contracts themselves, the database design, the integration with the backend systems, control, and event flow, and so on.

17.2.3.4 The XML Tsar and His XML Tsardom

While the IT steering committee was a great management tool for coordinating the work of the 23 work steams on the project level, an essential piece was missing from the beginning. As it turned out, the people in each work stream initially had only vague ideas about how they would integrate their own functionality with the functionality provided or required by the other work streams on the technical level. Although XML was set as the default way for describing interactions and data exchange between the components from the different work streams, there was a clear lack of communication and coordination of the interfaces between the different sub-systems.

As we mentioned before, in order to address this problem, the architecture board decided to create the role of XML Tsar. This person was given the responsibility of coordinating the development of the technical interfaces between the components implemented by the different work streams.

The XML Tsar assembled technical representatives from each work stream in his XML Tsardom, including representatives from open account, service request, workflow, call center, IVR, FundsTransfer, and document management.

The XML Tsar and his team met on a weekly basis to discuss and define the evolution of the XML-based service definitions, that is, the XML Schemas and WSDL definitions. The most important goal was to stabilize the development process and to reduce friction losses due to unstable interface specifications.

Each work stream actually sent two members to the weekly meetings, an XML designer and a build engineer. The XML designer was responsible for the coordination of the XML specifications. The XML build engineer was responsible for taking the newly released XML specifications and using the WSDL compiler to generate corresponding stubs, which would be used in his team. Given the huge diversity of technical staffranging from Web designers and junior programmers to senior EJB and mainframe developersit was essential to include the role of XML build engineer in the concept of XML Tsardom to ensure consistency amongst the different programmers. In fact, the majority of developers in the project was never aware of the underlying XML-based service infrastructurethey stayed in their particular programming language environment, using the stubs to provide service components to other work streams or to call into components provided by other work streams.

As would be expected, the impact of changes to the XML service definitions on the internal release cycle of the project was quite significantespecially in the late phases of the development, even small changes could have severe effects on the unit integration and test schedule. The XML Tsar therefore also closely cooperated with the IT steering committee and the project's release managers.

An interesting aspect of the structure of the XML Tsardom was that it enabled communication between key technical people from different work streams for the first time. The managers of the different work streams who met in the IT steering committee meetings tended to discuss topics related to the overall status of the project. On the other hand, the technical people who met in the XML Tsardom meetings had a very different perspective, which focused more on the technical details of the interfaces, and for most of them, the XML Tsardom quickly became the most important platform for communicating with members from the other work streams on the technical level. This helped significantly to reduce friction losses due to inconsistencies between the service interfaces of the different sub-systems.



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net