Table of contents for Live from Intalio User Conference 2008
Greg Olsen from Coghead presented how they are using Intalio’s BPMS. Greg is a believer in “small BPM” – something to extend and enhance something else. Greg’s experience led him to conclude that some basic database/process capabilities could be very useful to non-developers. Coghead was a platform as a service play from the beginning and always intended to include a BPEL engine. Intalio is now part of Coghead’s offering. They focus on “situational applications” – lots of departmental/office-centric applications that are around the edge of the mainstream applications that run the whole business. Historically these have used Access or Filemaker or perhaps ASP .Net. SMBs are also in need of these applications – 50M businesses do not have any servers so this is the only kind of application they can build.
Coghead has a web-based interface with forms, data management, integration, application management and process/business logic management all integrated and designed to be accessible to more users. VARs and ISVs are a key target market. They target the millions of power users and independent web developers who are more technical than end users and less than SI/programmers. Coghead aims to be both easy to use and supporting of business logic/process. More than a web database (Quickbase, Zoho) and easier to use than more complete things like PHP, Force.com.
Greg then showed a demo. Coghead has all the usual web-based CRUD database application capabilities. in addition, though, you can edit the standard actions. For instance, the Update operation can be replaced and the original process definition is displayed so it can be edited. Thus the update operation on an order could check to see if there was not enough stock on hand and then behave differently than if there was – sending an alert for example. Loops and other simple BPEL components can be added and are then executed using BPEL. The same capability can be used to add custom actions.
Coghead’s use of the BPEL engine is pretty deep. Anytime an overridden CRUD or custom action is called this is passed over to the BPEL engine. Below that is the base database action layer. Their BPEL implementation is pretty unusual – they have 200,000 processes v a more typical 10 and less than 100 concurrent users of an instance where 100,000 might be more typical. Way more processes, way fewer concurrent processes because the processes being built are simple and quick.
Key elements then are:
- Small number of primitives to keep it simple
- Data-centric because people understand “stuff” behaviors better than process
- Application structure as visible as possible