Chapter 4 Case Summary
4.2 Case 2: DM Integration
The agency purchased and installed a document management (DM) product from a software company from Australia in 2000. The agency has been using DM since for storing and managing all business related documents, including all kinds of files, e.g. MS Word, Excel and PowerPoint documents. DM system has similar structures as normal file folders, but it provides a full set of document management features such as GUI document security management, document versioning and quick access shortcut including URL links to documents.
Because DM is the central repository of all business documents for the agency, integration requirements have arisen since early stage because users wanted to link records in business systems such as Permissions and Land Register to documents stored in DM. Access to DM using document shortcut links from within business
external provider, looking into and modifying its source code would not be possible. The integration of DM with other in-house business applications has encountered many challenges. Various approaches have been adopted for fulfilling integration requirements in different stages.
4.2.2 Consideration for Research Questions
Document management systems are common in large organizations, such as the agency. They are essential tools for manage large amount of business documents. There are large selections of document management software in the IT industry, as they can be found in popular web sites, such as Wikipedia (http://en.wikipedia.org). Many document management systems attempt to integrate document management directly into other applications. Such integration is commonly available for office suites and e-mail or collaboration/groupware software.
DM is one of the essential tools that the agency’s users use in a day-to-day base. For any organization that deals with a lot of documents, some form of document
management is necessary. It is inevitable that the document management system in the agency to interact with other business systems, such as to share data and to maintain connections. Integration of DM and other business systems has long been necessary and desirable in the agency. The investigation of the case will help to find out and reveal challenges and solutions for such system integrations in a NZ government agency.
As DM is a third party product without any access to its source code, the integration of DM with other department business applications has created a lot of challenges. These challenges can be common for integration for existing systems, which were developed separately or supplied by different vendors. For most third party software, no inside design or source code may be available for any integration projects. The challenges and experiences arising from the DM integration in the agency would not only benefit the agency, but would be very useful for other government agencies, as such
integrations were found quite common. As the case document revealed, the Public Trust had a very similar integration using DM at the time the agency was developing its own one.
The DM integration project has been through a few stages and it was developed within the agency entirely. The XML web service was designed and developed to overcome issues that caused by incompatible software system. The case study would reveal the full details of these issues and provide explanations why and how XML web service became involved. Most XML applications had been introduced as part of the XML web service application for the DM integration in the later stages of the project. The case study will compare the approaches and results of using the only DM library components without XML and the approach of adopting the XML web service. There might be good reasons for both adopting and not adopting XML in the DM integration project depending on the business requirements and application designs, i.e. for simple document creation on the client side, no XML would be necessary, but for server queries, adoption of XML web service would be a better solution. The project had various business requirements and was a good example for investigating the research questions.
The DM integration project has developed a few new components, including the COM+ applications and XML web service. The agency users in a day-to-day base use those DM integration functions as part of the business application for many years now. The case study would find out how successful the solutions are by discussing with users, investigating the databases and performing testing on the systems.
Since the DM integration project has been developed within the agency entirely, the case study has a rich source of knowledge for answering the research question. There are a large number of documents, system design and even source code for the DM integration application. All these will help the research to identify reasons for the solution being successful or not.
4.2.3 Summary of Case Findings
(Please refer to the appendix section for detail of findings and preliminary analysis)
1) DM integration would be regarded as integration of common functions and interfaces. Document management systems would be common for large
organizations including government agencies, so would be their integrations with other business systems. The integration requirements arose very early in 2002 soon after the DM implementation in the agency and at the same time Permissions system was in development. It was an important part of the Permissions system right from the beginning, as the user requirements document and Permissions user guide have shown. As the trainer commented, users were impressed with the integration feature. A large amount of document relevant data has been created in the database from the integration.
2) Integration with third party software would present extra challenges and require more skills and effort. Knowledge of the product only could be accumulated after large amount of effort had been spent. It had been a long learning curve from the initial phase when ‘quick-and-dirty’ design was adopted because of the lack of development time, to the current status after many rounds of software upgrade and changes. The integration system had been through a lot of changes as reflected in the system design and source code.
3) The DM integration project was also a long running one consisting multiple phases. Not every part of the integration requires XML, but more and more XML applications had been adopted as the DM software and other business have evolved over years. As using XML web service is part of the best practice for passing data between application, and XML web service is deigned for machine-to-machine interaction including integration. XML web service was the key for the integration to overcome the incompatible .Net version problem and improve the flexibility of the integration component.
4) The XML web service would be one of the critical success factors for the project. The complexity of the integration and extra work had been caused by different version of software, especially the client side DM installations. It had illustrated that without flexibility such as those from XML web service, it can be difficult for maintaining the integration over a long period of time and for different systems. On the other hand, the use of XML web service for resolving the different .Net version problem and the subsequent quick integration with Land Register had illustrated the benefits of XML. The XML web service would be well placed for more future integration, as it was stated in the design document.
Special characteristics of DM integration:
1) For old fashion client-server systems like DM, which is also a Windows COM based applications, XML could hardly be used. On the client side, its library DME.exe only takes pre-defined parameters; they are all of simple data type. No complex data type like XML document would be used. Using XML web service to execute certain task such as creating document would be impossible, as the
software was designed on some strict rules, such as only accepts the Widows network credential from the current thread, as explained by the vendor in the teleconference session.
2) Integration with third party software such as DM can be very challenging, as there may be little support or documentations. DM is one of the document management software packages that do not have a large client base for sharing issues and solutions; neither does the vendor provide technical support promptly. The
software vendor only has limited capacity, as from the email document, one of the reasons for being late to get back to the agency’s development team was there was no technical staff available at the time.
Current status of DM integration:
1) The DM integration has become core part of the business systems. Documents describing potential integration requirements for other business systems including AMIS were found during the research.
2) The XML web service for communicating to the DM server would be enhanced or extended for better performance or functionality. It would be modified to directly query the DM backend database, as the current query through the library
component would be very slow as it was noticed in testing. The web service would also be extended to include functions for creating new document, so the complicate client side process will be avoided.