Intalio as a complete development environment?

Virgil Green, a contributor to the Intalio forum posed a question which approaches my own reason for studying Intalio

I've been considering BMPS in general and Intalio specifically as a development platform. I'm wondering if I'm expecting too much from this technology. I'd like to replace a complete software system including Contract Management, Claim Management, Invoicing, Letter Generation, etc.

My question is (rather broadly) whether the combination of Intalio Community edition (or any higher level edition), a database for which there are adapters, and a reporting tool such as BIRT provide sufficient tools to develop a complete enterprise system.

Business rules? Are they covered/enforceable in Intalio? User Inquiry and Data Entry? Are XForms enough? Am I expecting too much or should I continue to think of this software as middleware for moving data between other systems that handle those functions?

At present the answer is probably that you are asking too much of Intalio alone and that you are being very ambitious. However, the underlying ideas of Intalio and its open-source, and standards basis mean that there is likely to be a way of working with Intalio as a core to deliver a reasonable enterprise architecture.

I think it is a good idea to consider BPMS as the centre of an execution platform. Intalio then provides a good implementation of the BPEL engine and a corresponding designer. Because BPMS does not work well without people somewhere in the end to end operation, there is an element of human workflow required to complete the picture. Intalio adds to the BPMS a web application that implements the human workflow using a standard form expression BPEL4People. This is the TEMPO component. The Intalio Designer integrates this for you automatically. If you are happy to express your workflow with the BPEL4People constructs, and there are plenty of for and against arguments, that covers your business processes very well.

Either side of the business process management system you will require technology components that interact with people (the human interface) and services (the IT systems components for you Contract Management, Claim Management etc.).

Let us consider the services first. My observation of organisations which are not unduly tied into technology (a retailer or small manufacturer rather than a national Telco) is that when you manage the Business Process independently of the business services, the both the services and the business process implementations will become much simpler than if they are combined in say a customer management suite.

Intalio itself does not provide much in the way of application development of the kind you might find in IBM's Websphere or Microsoft Visual Studio. However, once the business processes are managed there may be little left to worry about other than the persistence layer of simple create, read, update and delete of data (CRUD). Of course there are a number of development tools that would work alongside Intalio to deliver the services components.

The user interface components of Intalio are designed for the workflow alone. This will not be sufficient for a complete software solution for many organisations. Although Intalio makes use of a generic user interface product (ORBEON ) which itself is a server implementation of the XFORMS standard, the method of development of user interface in Intalio does not allow the full capabilities of either to be used.

• There is no direct control over the presentation within the designer. The view of the form is defined by CSS , but the CSS scripting has to be unpacked from the Intalio distribution and modified independently of the forms designer component.
• The form input and output messages are defined automatically from the form components (widgets) which precludes the use of standard schemas common in business and government circles (for example the XNAL standard used for names and addresses).
• Fundamental XFORMS presentation controls are not available within the designer (for example, Appearance, which is used by XFORMS implementations to decide how the input/output should be presented)
• There is no control over XFORMS submission. Submission is limited to the messages to TEMPO.

However, the presentation layer of the architecture can be readily replaced with anything else that can communicate with SOAP (doc-literal) messaging. A commercial organisation might even consider using Microsoft Office as the presentation layer. Organisations with an architectural bias to Open Source and standards might still choose XFORMS but with a different development tool.

Whether Intalio is sufficient to develop for the enterprise will ultimately depend on the complexity of that enterprise. There will be plenty of businesses that perform their functions within Microsoft Office and Access environments. Intalio and a database would be a step up from that. MySQL and JDBC seems to fit well with Intalio. There are some samples of providing data access services through MySQL in Intalio.

At first glance, BIRT for reporting looks a good companion for Intalio in the development area as it is also based on the Eclipse development platform. However, the Intalio distribution seems a bit hostile to other Eclipse plug-ins. This may be resolved as Intalio matures.

Explicitly calling a business rules engine within the BPMS seems to be a reasonable approach and is readily achieved in Intalio provided the BRE provides a web service interface. Intalio provides a sample implementation with OpenLexicon.

Intalio could not be classed as a general development environment in its current incarnation but it is certainly capable of becoming one.

Health Information Privacy

IT managers often fail to do their best work in delivering security to the information within the health sector but they certainly do better than the health managers themselves.
A recent audit of the Wellington region's health service revealed patient records being stored in public corridors with no controls on access

The audit [Telarc] underlines that the organisation is bordering on dysfunctional. It records grave failings, such as leaving patient records in public corridors where anybody passing can take a peek,.... Dominion Post 8 Nov 2007

There are plenty of things that can be done technically to meet the required standards of privacy but if the underlying organisation has an irresponsible attitude to security we will see ill-considered technical 'solutions' that compound the problem.

As Blindside comments on one mobile health care device

Let’s see. Wireless transmission of sensitive information–yeah, we’ll get to that right after we take care of those pesky ergonomic and battery life issues. And preventing hacking and malware to ensure that the information is accurate? Hmm. Let’s put that on the list of things to do after we make sure it doesn’t add to the weight of the tablet device

I suspect that the subject of healthcare privacy needs a shake up from top to bottom. A few questions ...

• Is it clear what the customer (that's us, not the health managers) wants?
• What 'need' do these 'wants' reflect?
• Do the legislation and ethical requirements reflect this underlying need?
• Is there suitable compliance and enforcement of the legislation and ethical requirements?
• Should we get anaesthetists and paediatric cancer specialists before worrying about privacy and security?

When we have a good answer to those, we may be able to evaluate the technical questions about encrypting data at point of entry; securing information over wifi; ensuring that laptops and tablet devices are not attractive to thieves of information, identity or property (because they certainly will be available to all of those).