|
The National Programme appears to be facing significant technical issues in delivering the NHS Care Record Service. Application development has been delayed beyond scheduled delivery dates. When services are delivered, these appear struck by performance, security and persistence problems as soon as applications are scaled to anywhere near production volumes. Although some degree of secrecy surrounds the National Programme architecture, likely areas of technical challenge can be identified from what is known of the different architectures implemented within each cluster data centre. While each of these issues has known solutions, they require specific solutions and determined strategies to address. These challenges are likely to include:
-
Service Delivery: The selection of a Web Services paradigm as the SOA delivery mechanism creates issues with database connects, asynchronicity, and large volume service availability. At volume, Web services can introduce additional issues of complexity, memory management, record-locking and data consistency. With complex data models persisted into a relational architecture, entailing many joins, the overhead on the systems architecture can be significant. Web services can also add considerably to service development complexity: one recent estimation was that employing Web services as the SOA architecture for an industry-standard database entailed the use of an additional 11 languages or protocols in the development cycle.
-
Systems Environment: Some of the clusters appear to be based on industry standard systems environment designed for the mid-scale, without the expected availability or transaction monitoring capabilities of large-scale mission-critical environments. This appears to have made large scale virtualisation essential in all clusters. The selected environments do not feature in the highest performance database or transactional platforms as judged by the TPC-C and TPC-H benchmarks.
-
Codebase Environment: The choice of a managed codebase environment presents special challenges for optimised large scale application development. Although managed codebase environments promise greater efficiencies in programming productivity, large-scale service developments in managed codebases require especial optimisation. In particular, a common language runtime can add significant indeterminancy which can significantly affect performance and volume handling. Another issue, almost certainly confronted in the NWWM PACS implementation, is the issue of managing the migration of integration and API interfaces between different generations of the same codebase.
-
Virtualisaton: The choice of virtualisation, especially P2V in the northern clusters, is likely to entail a certain amount of processor overhead (approx 10%) but have a significantly greater impact on I/O volumes.
-
Database Architecture: In most cases the selected database architectures have not achieved the expected transactional volumes as judged by the TPC-C or TPC-H benchmarks. The selection of both relational architectures, and mid-scale, non-transaction optimised platforms, both gives rise to concern. The close coupling relationship in many cases of database architecture with systems environment can contribute to further instability and impaired overall service availability.
Implementing a complex data model, such as a healthcare data model, into a relational architecture can entail a large number of joins. These can place a heavy overhead on I/O, memory and processor performance.
-
Relationship between Codebase and Data Architecture: in particular the choice of object managed codebase environment together with relational databases is a significant development issue, and can also impact on performance, giving rise to challenges in object-relational mapping and the O/R Impedance Mismatch problem.
In all these areas, CfH has made choices that align it squarely with the main growth areas in commercial enterprise computing. This appears rational from a procurement perspective: such alignment looks to yield the greatest supplier choice and ongoing investment, and the maximum freedom from technology obsolescence. However, it does not acknowledge that this growth area is situated in mid-scale and departmental systems. It must be questioned to what degree large scale transactional solutions designed for the production volumes expected from each cluster can be based on the technologies currently selected in some clusters.
Research note originally prepared by William Payne
for Silicon Bridge Research in March 2007
|
|
