Sawada-san and I met over this blog. His comments were followed by an invitation to meet in Tokyo, during which I realized the full extent of his technical expertise and his exceptional business acumen, both honed over many years working for IBM. We joined forces, and he helped launch Intalio in Japan, making all the introductions that later on turned into business relationships. Most importantly, he was instrumental in helping Intalio make the move to Cloud Computing, which is driving most of our growth today.

Japan is a fascinating country, but one where doing business can be fairly challenging for an American or a European, of which I am both. This is where Sawada-san excelled. He would patiently explain to me and other Intalio managers how business is done here, why certain traditions must be followed in a certain way, and most importantly, why patience would be the mother of all virtues. We listened, and success quickly followed. Sawada-san was a great mentor.

Over the years, a friendship developed. He exposed me to various styles of Japanese cuisine, all of which he enjoyed very much. His wife Chikako-san introduced me to the art of the tea ceremony, also known as sado. His son Noriaki-san guided me through Tokyo’s most interesting neighborhoods, especially Daikanyama, where we dreamed of setting up Intalio’s offices one day. And when time would come for me to fly back home, he would always give me a bag full of these famous Tokyo Banana cakes, to the delight of my wife and daughter.

Today, Sawada-san left us on this Earth. And while I do not know where he is going next, I know that his memory will remain with us forever. On behalf of all Intalio’s employees, I would like to give our deepest sympathy to his wife, Chikako-san, his son Noriaki-san, and his daughter Yumi-san. For my part, I will simply remember the last minutes of Akira Kurosawa’s final film, Madadayo. As Uchida-san’s life is about to end, he remembers his youth, playing a hide-and-seek game with other children in an open field. And as children ask Uchida-san if he is ready (“Mou ii kai?”), he simply answers “Mada dayo!” (“Not yet!”). We are never ready for events like this one, and I wish that I could have told Sawada-san how much I loved him before he passed away. But life goes on, and he shall rest in peace now.

Mada dayo!

Here is what the Mark I gives you:

We’re now working on the Mark II model, which will break the Petabyte barrier.

It looks like we hit a chord…

Meet us at the Four Seasons Hotel Silicon Valley at 10AM PST.

Please RSVP.

The concept for a Business Operating Platform is close not only to the product developed by Cordys, but also Oracle’s Fusion Middleware and SAP’s NetWeaver. This should not come as a surprise: after all, Cordys was started by Jan Baan, founder of the company that developed the Baan ERP. Baan, Oracle, and SAP have developed the three most successful ERP systems in the world, and as such know a thing or two about enterprise architecture. Originally, all three ERP systems were built on top of an Operating System, a standards-based Relational Database Management System (RDBMS), and a proprietary Application Server. Today, next-generation enterprise applications should be built on top of a Business Operating Platform, which components will be discussed in this article.

In order to better understand what makes a Business Operating Platform, let’s take a look at what makes a modern Operating System such as GNU/Linux. Such an Operating System is made of a Kernel Space and a User Space (libraries and applications). An excellent introduction to the Anatomy of the Linux Kernel was recently given by M. Tim Jones and published on IBM developerWorks. Here are the components of the Linux Kernel, and how they match the components of the Intalio Business Operating Platform (Intalio|BOP):

Process Management
A multi-threaded kernel like the Linux kernel is architected around a pretty advanced Process Management infrastructure. By “process” we do not mean the processes used by businesses to run their operations, but the “threads” of computing that keep a CPU busy most of the time. In a similar fashion, Intalio|BOP is architected around a process engine (Intalio|Server, itself based on Apache ODE), which is an implementation of the BPEL industry standard for process execution.

Memory Management
Next to the Process Management unit is a Memory Management unit responsible for managing the transient data used by execution threads. By transient, we mean data which life-cycle is bound to the life-cycle of processes they relate to, as opposed to persistent data, which is usually stored in files onto the File System (Cf. next component). Similarly, the Business Process Management component of a Business Operating Platform is responsible for storing the transient data used by business processes. But unlike an operating system, a BPM system usually stores transient process data in a persistent manner onto a Relational Database Management System (RDBMS), for two main reasons: One, it allows the system to scale better by “passivating” idle process instances into the database. Two, it brings reliability to the system, by ensuring that no process instances are lost should the process engine go down or be turned off. Nevertheless, both concepts of transient data management are essentially the same. Intalio|Server can be deployed against virtually any relational database, using OpenJPA as persistence layer.

Virtual File System
The Virtual File System is responsible for managing the persistent data used by the operating system and the applications it runs. Similarly, a Business Operating Platform includes a Document Management System (DMS) responsible for managing the documents used by business processes. Documents can be either structured (using XML Schema) or unstructured (stored as plain files). Combined with a Content Management System (CMS), the DMS becomes a full-blown Enterprise Content Management (ECM) system, which is a first-class component of the Business Operating Platform. In the case of Intalio|BOP, we are using Apache Sling as content repository and the JSR-170 as standard interface.

System Call Interface
An operating system’s kernel provides a System Call Interface that allows processes running in the User Space to make calls to system services for starting a new process instance or reading a file for example. Similarly, a Business Operating Platform provides a set of interfaces for deploying new processes, accessing documents (JSR-170), or monitoring the overall platform (SNMP, JMX). While no standard API has been defined for process engines yet (one ought to develop one at some point…), Intalio|BOP provides platform interfaces using Java API’s as well as REST and WSDL services.

Device Drivers
Device Drivers allow an operating system to make use of peripherals such as disk drives, a keyboard, or a mouse. Similarly, a Business Operating Platform provides a set of protocol adapters and application connectors allowing processes to be integrated with third-party systems and applications. While many attempts have been made at developing standards for application connectors (JCA, JBI), none ever really succeeded on the marketplace (even though SCA looks promising). Intalio|BPO provides a set of connectors based on the JBI and WSDL technologies, and is planned to support SCA by using Apache Tuscany.

Network Stack
While some resources (peripherals) are directly attached to the computer and can be accessed through a Device Driver, many (including other computers) are remote and can only be used through a Network Stack. Similarly, most third-party systems and applications used for the execution of business processes can only be accessed while crossing firewall boundaries. In such cases, integration happens through Web Service interfaces, using the WSDL industry standard. Intalio|Server is based on the BPEL process execution language, which itself relies on WSDL for Web Service invocation. Nevertheless, a RESTful version of BPEL is currently being developed by Intalio, and will be supported by Intalio|Server in some future release. In either case, Web Service interfaces are provided by an underlying Enterprise Service Bus (ESB). For this purpose, Intalio|BOP includes a component called Intalio|ESB, which itself is a combination of multiple open source projects, including Apache Axis2, Apache ServiceMix, and Apache Synapse. Intalio|ESB itself can be deployed on top of a Message Bus in order to support multi-site deployments.

These six primary components make the Linux Kernel. Interestingly, the Linux Kernel does not have any notion of registry, at least one similar to the Windows Registry. Instead, configuration files are stored in specific directories (/etc or /usr/local/etc), in a much more losely coupled manner. While many will argue that the absence of a registry is one of the design elements that make the GNU/Linux operating system more robust than many alternatives, businesses need some kind of registry where all processes and related artifacts can be stored and looked up. Such a registry is one of the services to be offered by Intalio|BOP alongside several others that are analogous to the services offered by the GNU/Linux operating system at the User Space level.

Registry
While many operating systems offer some kind of Registry, a Business Operating Platform should offer a Master Object Registry (MOR) that would record all artifacts, including data objects, processes, rules, services, user interfaces, etc. In order for it to scale and support the kind of queries that developers and users might need to perform, the registry should be based on strong Semantic Web technologies, namely RDF, RDFS, and SPARQL. For this purpose, Intalio|BOP will use the Jena Semantic Web Framework as underlying infrastructure for Intalio|MOR (to be made available in a future product release).

User and Security Management
Most operating systems provide a way to manage users and their entitlements. Nevertheless, such security services are usually fairly limited to coarse-grain resources (files and applications), and cannot scale to very large numbers of users and entitlements. A Business Operating Platform must overcome such limitations, and provide a way to define complex entitlements related to any resources or artifacts, for an unlimited number of users and groups. Furthermore, since a Business Operating Platform is responsible for orchestrating business processes which execution might span multiple applications, it must also provide Single Sign-On services (SSO). Intalio|BOP is currently based on the Java Authentication and Authorization Service (JAAS). Future releases will add support for OpenID and XACML.

Windowing Framework
Most operating systems developed since 1984 (year when Mac OS was first released) provide some kind of windowing framework offering a graphical interface to end users. Similarly, a Business Operating Platform must support the development of user interfaces, but these must be accessible over the Internet through a standard web browser, rather than being bound to a particular computer or client-side operating system. While many Rich Internet Application (RIA) frameworks have been released over the past few years (Flash, JavaFX, Silverlight, etc.), the most ubiquitous is AJAX, which uses a combination of asynchronous JavaScript and XML for providing interactive web applications. AJAX is more a programming style than an actual framework, and is supported by multiple implementations, such as Google Web Toolkit (GWT) or the Dojo Toolkit. For its part, Intalio|BPO makes extensive use of GWT, while providing a graphical IDE for the development of AJAX applications — Intalio|AJAX (based on TIBCO General Interface).

User Desktop
All graphical operating systems provide a desktop giving users access to their documents and applications. In a similar fashion, a Business Operating Platform must include an Enterprise Information Portal offering a single point of entry for all resources offered to end users, from task lists to document repositories and administration tools. Such a portal should also facilitate the collaboration among end users, allowing them to easily share resources such as processes, tasks, or documents. For this purpose, Intalio|BOP includes a component called Intalio|Portal based on the Liferay open source project, and supporting the JSR-168 industry standard. Intalio|Portal also includes Liferay Social Office for social collaboration inside the enterprise and across extended value chains.

Administration Tools
Most operating systems provide administration tools for configuration and tuning purposes. Similarly, a Business Operating Platform should provide tools for managing its various components, as well as the applications and processes it supports. While the various components of Intalio|BOP all provide some fairly advanced administration tools, each has its own interface, making it more difficult than it should be to have a complete view of the system. In order to remedy such a limitation, Intalio|BOP will soon provide a unified management interface, shared by all components of the platform. Furthermore, it will offer an implementation of ITIL V3 processes for Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement.

System Monitoring Tools
Most operating systems also provide monitoring tools tracking various metrics such as CPU utilization or memory allocation. In a similar fashion, a Business Operating Platform must provide a Business Activity Monitoring (BAM) framework offering real-time information about the status of processes, activities, and transactions, through the definition of custom Key Performance Indicators (KPIs), and the presentation of real-time dashboards. For this purpose, Intalio|BOP includes a component called Intalio|BAM, based on the Eclipse BIRT open source project.

Integrated Development Environment
Any operating system provides libraries and Integrated Development Environments allowing developers with various skillsets to build custom applications on top of it. Similarly, a Business Operating Platform must offer a set of development tools that can be used by business users, architects, and developers alike. For its part, Intalio|BOP offers 3 development environments, each targeted at a specific user: Intalio|Business Edition for business users, Intalio|Community Edition for process analysts and systems architects, and Intalio|Developer Edition for software developers. Each edition provides a specific view on the overall platform, while relying on a common runtime engine — Intalio|Server.

These are the components that make a Business Operating Platform, alongside others that do not have a close match within modern operating systems. Among them, we could mention a Business Rules Engine (BRE) or Business Rules Management System (BRMS), a Complex Event Process (CEP) or Event Stream Processing (ESP) engine, and a Data Integration engine. These components are either part of Intalio|BOP today (Intalio|BRE), or will be added to the platform in the near future.

From an architecture standpoint, a Business Operating Platform should respect the following principles if it is to be used for business-critical applications and deployed in a large-scale production environment:

Web-based User Interface
While web-based user interfaces cannot match the interactivity and richness of dedicated client applications yet, the gap is closing extremely fast, and all user interfaces of a Business Operating Platform should be web-based within 2 to 3 years. In the case of Intalio|BOP, the only rich client component of the platform is Intalio|Designer, which is based on the Eclipse workbench. Nevertheless, many components of Intalio|Designer are first packaged as web-based applications, then embedded within the Eclipse workbench. Such is the case for the IDE of Intalio|AJAX and the editor of Intalio|BRE (Intalio 6.1). Moving forward, the next generation of the Eclipse platform (e4) will enable the platform for use on emerging web-based runtime technologies, and the BPMN modeler of Intalio|Designer will be migrated to a web-based interface, possibly using the extremely promising Oryx platform.

On-demand and On-premise Deployment
In order to support the widest range of usage scenarios, a Business Operating Platform should support deployments both on-premise and on-demand. On-demand deployments should be based on a multi-tenant architecture making proper use of virtualization technologies (Cf. On Multi Tenancy) in order to offer virtually unlimited scalability both horizontally (many customers per data center) and vertically (many users per customer). Intalio|BOP is available for deployment both on-premise and on-demand.

Grid Architecture
A true Business Operating Platform should be considered as core building block for any Platform as a Service (PaaS) offering. As such, it must support deployment on a grid infrastructure, allowing scalability to thousands of servers or more. In order to provide such a level of scalability, Intalio|Server is currently being packaged on top of Shoal and Apache Hadoop, while Intalio is working with an open source database vendor to support the collateral deployment of thousands of database servers on a single grid.

Open Source
Last but certainly not least, a Business Operating Platform should be made available under Open Source licenses. I write licenses (plural), because not one single license could be used to put such a massive platform together (as far as I can tell). But a combination of compatible licenses could. The primary reason why a Business Operating Platform should be made available under Open Source licenses is that it will support the development of business-critical applications that will be used for decades to come, and the risk of vendor locking or product discontinuation associated with the use of proprietary closed-source software is simply too great. For its part, the core components of Intalio|BOP are licensed under the Apache, BSD, Eclipse, GPL v3 (plus AGPL and LGPL), and MIT licenses, which are compatible with each other.

Developing the first Business Operating Platform is Intalio’s mission, are we’re working very hard to make it a reality as soon as possible. It will be made possible by a combination of smart acquisitions, collaborative product management, and self-empowerment. If this sounds like fun, join us for the ride!

Whether analyst firms like it or not, BPM is not a business application, it’s a business platform, and as such, it must support the development of enterprise applications in a process oriented way. For most new applications built against existing systems of records (ERP in particular), orchestration of services and support for human workflow is all you really need. But for more green-field environments (of which you’ll find plenty in emerging markets), the development of custom data objects is necessary, and this is precisely what CRM systems are good for. To better understand this notion, forget about the content side of CRM (content as in business objects such as Customer or Opportunity). Instead, focus on the underlying infrastructure, which allows one to develop custom data objects through simple wizards. In other words, takes the Sales out of Salesforce.com, and focus on Force.com instead.

Much like BPM 2.0 tools let you build processes in a zero-code fashion, you’d like a true Business Process Platform (BPP) to let you build data objects without having to write code either. And not just that, but the platform should make these objects directly consumable by the process engine, through well-defined interfaces that could be generated automatically from the data model. Granted, there are many tools one could use to do that today, but they’re either too complex to use for business analysts, or too limited in their ability to support the more complex object models. This is precisely what Salesforce.com did a great job at (I’ve never tried Aura Portal, but I must assume it does a good job at it too), and we definitely need to add such a capability to our product. Here is how we’re approaching the problem.

First, we need to agree that we will use a Relational Database Management System (RDBMS) as repository for our data objects. While object-oriented databases are out of fashion and XML databases never really materialized, relational databases are available from a variety of sources, both commercial and Open Source, and nothing beats them in terms of reliability and dependability. Document-oriented databases like Apache CouchDB are intriguing, but they’re not optimized for structured data objects.

Second, we need to decide how to use the database itself. The first option is to store data objects in dedicated tables (one table per object). The second option is to create a set of generic tables (3 to 5 usually), and store all objects into it. The later is the option retained by Salesforce.com. When the Salesforce.com application was first designed ten years ago, virtualization did not really exist (at least in the way we understand it today), and the approach made perfect sense in order to support tens of thousands of customers in a multi-tenant environment. Unfortunately, the approach has its limits, for it forced Salesforce.com’s engineers to essentially re-invent the database on top of a database (Oracle in that particular example), making it very difficult to support complex queries with multiple levels of joins, and creating some severe scalability issues. Today’s virtualization technologies and low-cost databases (MySQL or PostgreSQL) dramatically change the equation, and deploying an off-the-shelf relational database on top of a grid of low-cost servers would give us scalability both horizontally (in terms of number of customers) and vertically (in terms of number of objects and users per customer).

Third, we need to select some kind of middleware to connect to the database. There are plenty of Java-based options there, from Hibernate to OpenJPA, but Java might not be the best language to start with. While we need to make it easy to create data objects without having to write code, we also need to support the ability to script data objects, without having to invent yet another language (like Salesforce.com did with APEX). When it comes to scripting, Ruby seems to get the most votes today, and Rails is exactly the kind of middleware we need to go from data model to database tables, without having to write much code, or any code at all for that matter.

Fourth, we need to develop a dead-simple user interface on top of the middleware. In this area, Salesforce.com should be used as ultimate benchmark. Its user interface makes it very easy to create new objects, define custom fields for them, set access control and visibility rules, and dynamically create forms and views for editing data objects. And when it comes to forms, simplicity should be the rule. Once you created a custom object with Salesforce.com, the application automatically creates a default “Page Layout” for it, which you can barely customize. All you can do is define sections which can have either one or two columns (of the same size), and move fields around with a drag-and-drop user interface. That’s it, and that’s all one should really need. And if you need something more custom, use a more advanced tool, such as Intalio|AJAX for example.

Fifth, we need to generate interfaces for these objects, and both REST and WSDL should be supported. REST because it’s easy to use, and WSDL because it’s all BPEL can natively consume (until we develop a RESTful version of BPEL that is). These interfaces should be totally canonical, and automatically generated by the database middleware. They should be registered into some kind of directory that could be looked-up through a dedicated REST interface (too bad UDDI never took off).

Sixth, we need to add some kind of service invocation tool to Intalio|BPP Business Edition, with a simple data mapping tool. This tool must be an order of magnitude simpler than the Data Mapper of Intalio|Designer, and should be built using the Google Web Toolkit (GWT, also used by the Business Edition). Nevertheless, the Data Object Builder described in this article should also be integrated with the other editions of Intalio’s platform, the Community Edition, Developer Edition, and Enterprise Edition.

Once we get all that done, we’ll get something pretty close to Coghead. At this point, it’s unclear whether we should add any business content to the platform or not. But should we decide to, Apache OFBiz looks like a good place to start from.

We’re currently kicking the tires with this project. If we decide to move forward with it, we will most likely develop it under the GNU Affero General Public License Version 3 (AGPL v3). If this sounds like fun, feel free to drop us a line.

In the meantime, we’ll create a D3 project for it.

10. No worklist support
Intalio’s Tempo project does that, and it’s available under the Eclipse Public License. It’s also part of Intalio|Server, and it now includes Apache Jackrabitt (using Apache Sling) for document management. And if you want something more lightweight and do not mind writing some Ruby code, you might want to take a look at Singleshot.

9. No clustering
Intalio|Server provides support for clustering, for both load-balancing and fail-over. More advanced clustering support for grid deployment will be part of Intalio 6.0 Beta 2, using Shoal. Support for Apache Hadoop is also being considered by the Server Team, which recently moved to new offices in San Francisco, CA (feel free to stop by).

8. No reporting
Intalio|BAM provides real-time information about the status of processes, activities, and transactions, through the definition of Key Performance Indicators (KPIs), and the presentation of real-time dashboards (powered by Eclipse Birt).

7. No fixing of in-flight processes
In-flight process modifications are supported through Intalio|Server’s management console. Furthermore, Intalio|Designer makes it easy to break large and long-running processes into smaller ones, therefore enabling in-flight process re-deployment, without violating the transactional integrity of deployed processes.

6. Rudimentary monitoring
Intalio|Server provides a pretty advanced management console for process monitoring.

5. Hand-editing WSDL’s to specify where the service is hosted
Intalio|Designer makes it fully graphical and quite intuitive.

4. Installation
The entire Intalio Business Process Platform can be installed in less than 5 minutes.

3. Deployment
Process deployment from Intalio|Designer is just one mouse click away.

2. BPMN modeling
Intalio|Designer is the most advanced BPMN modeler currently available, and is based on the open source Eclipse BPMN Modeler project lead by Intalio. Nobody wants to write BPEL code by hand, but some developers might like to write SimPEL code instead. Those should take a look at Intalio’s upcoming Developer Edition.

1. Include people
Once again, Tempo and Singleshot do that pretty well.

So, here we are. BPEL is the industry standard for process execution, Apache ODE is its most reliable, scalable, and standard-compliant implementation, is available under the Apache License, and is the cornerstone of Intalio’s Business Process Platform, which itself addresses all Alex Neihaus’ points.