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.