The headaches of centralised data

The UK government's woes concerning the potential loss of personal data has received a lot of publicity in recent months. It calls into question the whole strategy adopted by governments to build ever larger centralised databases containing more and more integrated data from multiple applications such as passports, social security, driving licences and health service. An insurmountable security nightmare arises from developing such databases. Just who can you trust absolutely to control access to such universal data sources?

Here's a radical thought - instead of centralising the data and building multiple applications around the same centralised database, why not build applications that can safely access multiple data sources, allowing departmental control of the more localised data sources with full version control and audit of all data access. Interestingly when we built xProcess, the data architecture we adopted lends itself to just such an approach. We've since named the framework XAPPA (eXtensible APPlication Architecture) and its continued development promises much in terms of rapid, model-driven application development for distributed systems.

Key benefits include:

• Lets multiple “centres” manage the data they own and freely link to data owned by other centres.
• Each centre manages access and audit
• All data versioned
• All access auditable
• Every change recorded
• Uses industry standard protocols for versioning
• Uses XML files (optionally encrypted)
• Transfer objects support Web2 applications and tools
• Applications built with MDA/DSM
• Applications can share data sources.

Frameworks like XAPPA may yet provide the means for both the integration and distributed management of data that future personal data systems will need. While all data storage and retrieval systems suffer from the risk of penetration, distributed systems at least limit the risk of total data penetration, which is the doomsday scenario few seem to realise is only too likely with conventional database approaches.

Document-driven processes

Many processes are driven by documents. Documents are the resulting artifacts from tasks of the process, as well as being the inputs or informing artifacts for subsequent tasks. Examples of such processes range from drug administration, planning applications, legal processes of many kinds and financial control. Since many of these processes are also subject to regulatory control and audits it makes sense to define and monitor them within an environment like xProcess, which not only provides feedback on the forecasts and targets for task completion, but also can handle the version control of the document templates, and the documents themselves.

Modelling these processes requires understanding of what the key documents are, their format (which can be captured as document templates) and the transformation work which takes place through the process (which can be captured as task patterns). The quality control to be executed at each stage can be captured as gateways.

Here's a simple example.