First, the Customer Support Process. It’s a pretty complex one originated from a custom user interface built in Ruby on Rails, integrated with our new trouble-ticketing system (itself integrated with Salesforce.com), our knowledge database (Confluence), our legacy bug tracking system (Jira), and our original Demand Driven Development (D3) portal (itself to be migrated to a collection of processes running on Intalio|BPP). This process is only a prototype right now, but should be fully implemented within a month or two. In the meantime, feel free to download the BPMN project for it, which you can import directly from Intalio|Designer (File/Import…).

Customer Support Process

Second, our Marketing Process, which was described in details in this article. After some internal discussions, we concluded that the process could be implemented through a generic BPMN pattern, rather than dynamically generating BPMN code. This is a much better solution, for three main reasons: One, it’s a lot easier to implement. Two, it will allow any changes to the Execution Table (the spreadsheet describing the process) to be applied to running process instances in flight. Three, it will support the definition of any loops within the process, and the use of recursion within the process — a process instance can create a new one, like is the case when a Public Call or a Webinar have to be organized for example. What follows is a map of the generic process that will support the execution of any process designed with our Execution Table Template.

Marketing & Public Relations Process

The Execution Table Template has been cleaned up in order to support its design with Google Apps or Zoho (Google Apps version), the definition of arbitrary loops, recursion, and multiple forms, which are now captured through separate sheets (Data Input Form). Integration Points, Ideas, and Timesheet are also captured through separated sheets, and used for documentation purposes only. What follows is a screenshot of the Execution Table designed using Google Apps, also made publicly available (Decision Table | BPMN Model).

Execution Table

What’s truly remarkable about this project is that Intalio|Designer and Intalio|Server could be used off-the-shelf for implementing a custom process design and execution framework built upon a proprietary process execution meta-model, in a matter of days, and without having to write custom code. So far, we spent 18.5 hours on the project, and we expect to have a first running version of the end-to-end process within two weeks, working on it in our spare time.

Another interesting discovery made through this project is the fact that processes modeled with our Execution Table Template can be used by auditors working on SoX compliance projects. We presented our idea to half a dozen companies in Japan earlier this week, and every single one indicated that they could use our tool for their J-SOX projects (J-SOX is the Japanese equivalent of the Sarbanes-Oxley Act). As a result, we’re seriously considering packaging this template with our Business Rules Engine (Intalio|BRE) and upcoming Complex Event Processing (CEP) engine into a solution for next-generation Governance, Risk Management, and Compliance (GRC).

Third, the side project I mentioned above. As part of our Marketing & Public Relations project, we had a need for an Enterprise Content Management system that could be used to develop and publish all our marketing collaterals. While we could have used Intalio|ECM for this purpose, integration with Google Apps and Zoho was lacking. Furthermore, we wanted a system that could not only store our marketing collaterals, but also all our process artifacts, fully integrated with Intalio|Designer. Last but not least, we wanted a system that could store XML documents natively, and provide integration with Apache Cocoon, in order to support the publishing of content on our existing website.

After some internal discussions, we decided to develop our own system. It is built on top of Apache Sling, which itself is based on Apache Jackrabbit. The funny story about Jackrabbit is that it is based on Apache Slide, which itself was contributed by Intalio to the Apache Software Foundation 8 years ago. Small world, very small world… Sling also includes Apache Felix, which is the OSGi framework that all Intalio’s runtime components will be deployed on top of moving forward. Jackrabbit now includes Apache Lucene, to be used as search engine. Finally, we’re looking at the Jena Semantic Web Framework in order to support the tagging and indexation of documents in a scalable manner.

At present time, a prototype integration of Sling with Tempo has been developed by Nicolas (Cf. blog post and screencast), and we are considering creating a D3 project for it, while debating about the Open Source license this new project should be released under. If this sounds like fun, please take a look at our tentative roadmap and drop us a line. The codename for this project is Doubleshot.

Any good Office 2.0 setup, be it mine or yours, needs a focal point, a place where all the bits and pieces fall into place. And because no single solution will address all the requirements you might have, what you really need is a platform that can integrate multiple applications in a meaningful way. If your setup is made of simple widgets, something like web-based desktop might be all you need. But if you’re using a lot of transactional applications, and need something a lot more data-oriented and workflow-driven, a CRM system is what you should be looking for.

Problem is, building a platform is one of the most difficult things to do. We are building one at Intalio, so I know a thing or two about this kind of challenge. And what I learned from more than seven years of trials and errors is that your success as a platform vendor hinges on your ability to develop a thriving ecosystem of partners whose success is tied to yours. In Intalio’s case, it’s over 44 system integrators and 22 independent software vendors located in 21 countries. And in the case of Salesforce.com, it’s the AppExchange, with over 500 applications developed by over 240 partners. The larger your ecosystem, the stronger the platform. It’s that simple.

Today, many Office 2.0 vendors have embraced AppExchange and started to offer their services as extensions to Salesforce.com. Among them, there are a few I just cannot live without anymore: EchoSign for electronic document signing [review], Koral for content management [review], and Spanning Partners for data syndication and synchronization [review]. The desire to have these directly integrated within the hub of My Office 2.0 Setup is what convinced me to return to my first CRM love. Today, Salesforce.com has matured into a full-fledged platform, and it has become too difficult to ignore its appeal.

That being said, I want to make it crystal clear that after three months using SugarCRM extensively, I could not find anything missing from a pure CRM standpoint, and in many areas John Roberts’ company kept innovating where Salesforce.com had stopped. SugarCRM is certainly one of the best CRM systems out there for on-premise deployment, and the on-demand edition I have used has worked absolutely flawlessly. For this, I would like to thank the good folks at SugarCRM. I learned a lot from them and their application. But being the bleeding edge pioneer that I am, I need something that will help me build a more integrated Office 2.0 setup with minimal resources, and I think I will find it where I came from.

Note to Marc: you should really talk to the folks at ThinkFree.

Among other things, a security architect is usually interested by authentication and entitlement. The first is there to ensure that you really are who you say you are, while the second gives you permission to conduct some actions upon specific resources once you have been identified and your credentials have been defined. From an architecture standpoint, authentication has been largely solved with Single Sign-On architectures. It does not mean that companies have deployed it yet, nor that Web resources are supporting it — I wish they were — it just means that the standards have been set, implementations have been developed, and best practices have been defined. Entitlement is another story altogether.

Entitlement, which is also known as authorization, is a complex problem to solve, because it covers a broad range of actions that can be conducted upon a broad range of resources. While the scale and complexity of a Single Sign-On infrastructure typically grows linearily with the number of systems and users having access to them, the scale and complexity of an entitlement infrastructure grows exponentially with the number of resources and services it is controlling access to. Because of such inherent complexity, standards for entitlement or authorization are fairly complex too. For some time, one of the references in the space was the Role Based Access Control model developed by the National Institute of Standards and Technology (NIST). Eventually, it got superseded by the eXtensible Access Control Markup Language (XACML) developed by OASIS, which is one of the most complex specifications I ever came across.

From an architecture standpoint, I believe that XACML is using the right model to solve the problem at hand. As James explains in his post, it defines several components such as a Policy Administration Point (PAP) which allows for centralized administration, Policy Decision Point (PDP) which defines how rules/conflicts are resolved and the Policy Enforcement Point (PEP) which is responsible for the actual enforcement of all policies. The technology is good, but the challenge has been in getting multiple vendors to adopt it. If history is any indication, what happened for authentication will happen again for entitlement. Because vendors of enterprise systems and applications had different ways of authenticating users and did not agree on a common standard, other vendors had to step in and provide generic solutions that could connect to a variety of existing systems. For authentication, such solutions came from traditional security vendors such as RSA. For entitlement, I believe that solutions will come from ESB vendors, for SOA is providing a compelling event for their deployment. They might also come from BPM vendors, for business processes provide the right set of scenarios for defining meaningful entitlement policies.

This brings us back to the original question, which is to understand how the security model used by an ESB will mesh with the one adopted by a BPM system. Security, alongside discoverability and resusability, is one of the services that should be offered by a good ESB, and entitlement is one of its critical elements. XACML is quite a good fit for the ESB model, in the sense that it would allow service owners to specificy rules and policies for granting access to services managed by the ESB. Things get a little bit more complex for a BPM system, for the reason that entitlement can be implicitely defined and transparently enforced when using the right process modeling methodology and notation. In this respect, the BPMS acts as some kind of process firewall.

The idea for a process firewall is pretty simple: model your process in BPMN using multiple swimlanes — one for each participant, be it a human being, an external system, or another process. The very action of breaking your process down into participants implicitely defines who can do what, which is also called authorization, or entitlement. Essentially, entitlement definition becomes a simple by-product of process design, and it’s one that comes out for free, with the right level of granularity. If you adopt this approach and make the assumption that all your services will only be consumed by processes deployed on the BPMS, setting up your ESB for policy enforcement becomes trivial: no service can be used by any other system than the BPMS, and let the BPMS do whatever it wants. With such a model, the BPMS becomes your PAP, your PDP, and your PEP, all in one. Pretty cool, isn’t it?

Of course, this model is overly simplistic, and most real-world deployments would include services that are used by many other systems than the BPMS. In this case, the ESB becomes the primary PAP, PDP, and PEP, and is extended by the BPMS, which acts as a secondary PAP, PDP, and PEP. If you adopt such a model, two options become available to you: one is to use the BPMS to circumvent the entitlement rules defined by the ESB, the other is to use the BPMS to refine them. According to the first option, a given role might not be able to perform a certain action upon a given resource based on the rules defined in the ESB, but would be allowed to perform it within the context of a specific process managed by the BPMS. According to the second option, the ESB might define broad entitlement rules for a set of resources, and let the BPMS define narrower scenarios whereby particular roles perform some actions upon a subset of these resources, again within the context of a specific process. The first could be characterized as an exception definition mechanism, while the second is a specialization technique for the definition of fine-grain entitlement rules. I believe that both could be used side by side, and that there would be significant benefits in so doing.

The way an ECM system would fit into this picture is quite interesting as well. Access control is a critical feature of any ECM to be deployed within an enterprise environment, and sharing the same entitlement architecture with the BPMS and the ESB would provide significant benefits. For documents that would be attached to process instances, the entitlement architecture would define who gets to do what with the document, at different points in the process execution, which is something that is very difficult to do with a standalone ECM that has no notion of process context. Also, using the ECM’s native access control infrastructure would allow the definition of proper entitlement rules for the manipulation of process artifacts, such as process models, service definitions, or user interfaces, while coupling it to the BPMS’ process deployment infrastructure would allow the definition of rules that are directly related to different points in the process’ lifecycle, such as development, testing, deployment, or update. For more on the intersection between BPM and ECM, you can refer to this article.

As far as I know, no BPM vendor has ever adopted such a model in combination with an ECM and an ESB. Nevertheless, the technology exists today for building such a thing, and all we need is enough customer interest for getting it done. This is something that Intalio is actively pursuing today, and I would expect that we will be in a position to announce interesting developments in this area sometime this year.

In the meantime, I wish you all a very good week-end.

There are two primary reasons why I like Amazon Web Services: One, they define very simple interfaces for addressing very common needs you have when developing any kind of Web-based application. Two, they promote a no non-sense pricing model that makes them a viable option for most projects. Thing is, I am not the only one thinking that way, and I am hearing more and more organizations, small and large, starting to adopt Amazon’s services, which raises a very important question: can we rely on them?

As any utlity, Amazon Web Services are subject to failure, and recent outages experienced by developers are a painful reminder than when you put all your eggs in the same basket, and the basket falls on the ground, you better like your eggs scrambled. Which is why you should use multiple baskets.

Imagine for a moment that an open-source project would be created with the goal of developing all the software necessary for deploying clones of Amazon’s most popular Web services, including EC2, S3, SQS. Imagine that you could deploy this open-source software onto your own servers. Imagine that more elaborate versions would be developed on top of some kind of grid operating system — like 3TERA, allowing any ISP or Web hosting provider to provide plug-compatible Amazon-like services by using unused bandwidth, processing, and storage capacity. Finally, imagine that such an open-source project would also develop the client-side software you need to use Amazon’s Web services in combination with any other clone in order to get failover capabilities, without having to learn any new API. Do you think such a thing would be of value, to you or others?

I recently asked this very question to a group of five IT executives working for one of the ten largest companies in the world, and the answer was a resounding ‘yes’. I must assume that you could find many other companies, small and large, that would share the same opinion.

If such a thing existed, you would be able to use Amazon’s low cost services for your daily operations, and the services offered by more expensive providers whenever Amazon would go down, for some limited period of time. You would also be able to run your own version of Amazon’s services within your own data center as a backup, giving you the assurance that your data and your services remain available, even in the event of a catastrophic failure, or a decision to increase prices beyond reason.

Today, popular Web sites and mission-critical applications served over the Web rely on redundant connections to the Internet that are provided by multiple service providers, as a way to remove any single point of failure. Time has come to apply the same approach a level up in the stack, and I could not think of a better starting point than Amazon Web Services for it.

Initially, Amazon might see such a project as a competitive threat, but over time, it should realize that most developers will still use its original services as primary ones, for they are most likely to provide the highest level of availability, at the lowest price point.

Such an open-source project does not exist today, but I bet it will very soon.

Enterprise Service Bus
The ESB will be the core component of your Service Oriented Architecture, so you want to get this one right. An ESB is a piece of middleware, and as such it’s notoriously difficult to characterize. Some see it as an intermediation interface, others as a full fledged platform. Some like it to be totally distributed, others prefer to manage it centrally with dedicated servers. What makes it even more maddening is that in some instances, there is no way to tell whether a given ESB is one or the other, for it can be both depending on how you look at it. So let’s try to simplify the problem: if you’re narrowing your search for the perfect ESB to commercially-supported Open Source offerings, you should ask yourself whether you want your ESB to be more Java centric than XML centric. If you do, I would go for one that is based on Sun’s Java Business Interface (JBI), and ServiceMix (supported by LogicBlaze) is as good as it gets. If you do not, I would take a look at Mule (supported by MuleSource). And if you cannot make up your mind, I would use both side by side. This is what we are doing at Intalio, and it seems to be the only way to satisfy the demands of all our customers.

Web Services Stack
If you want to make SOA part of your product, you will need to hook it up to your existing components. For example, you would like to invoke a Web service from a process through the ESB. For this, you will need some kind of Web services stack that will provide support for basic protocols such as SOAP, deal with its multiple versions (v1.1 and v1.2), handle attachments, supports WSDL’s multiple styles (RPC/encoded, RPC/literal, Document/encoded, Document/literal), etc. All this is very boring of course, so you certainly do not want to do it yourself. Instead, you might want to consider the excellent Apache Axis (supported by WSO2), and go on with your life. There are some alternatives of course, but this one has been picked by both JBoss and IBM WebSphere, and when these two competitors agree on something, you can be sure that it’s pretty good.

Web Services Application Server
Once you get your Web services stack and your ESB running, you can expose your existing components as Web services. That’s great. But what if you have to build new components? Well, you have two options there. Option number one: use a good old J2EE application server, and write some business logic packaged as beans or servlets, like we did for our BPEL4People task manager. For this purpose, we are using IBM WebSphere Application Server Community Edition (WAS CE), which is not much more than a commercially-supported version of Apache Geronimo. Option number two: use a dedicated Web services application server. This option should be of interest if you’re looking for a more lightweight solution, and one of the best implementations has been developed by WSO2, was previously known as WSO2 Tungsten, has been aptly renamed WSO2 Web Services Application Server, and is available under the Apache Software License.

Service Registry
Once you get all these neat little Web services, it would be a good idea to register them onto some kind of registry, so that they could be discovered by others for reuse purposes. On this front, you need something like CentraSite, a standards-based SOA registry and repository jointly developed by Fujitsu and Software AG. It provides advanced search capabilities leveraging UDDI 3.0 and metadata models, comes with a neat report generator, and provides two sets of user interfaces, one AJAX-based for Web browsers, and another implemented as a set of Eclipse plugins.

Administration Portal
Last but not least, you will need a way to manage all your services, for you will soon realize that you have a lot more of them that you thought. For this, just keep in mind that Web services are nothing more than tiny little pieces of IT, and there is no reason why you could not manage them the same way you manage any other pieces of your IT landscape, through some kind of system management portal that gives you tools for inventory, monitoring, charting, event correlation, root cause analysis, alerting, and control. Well, that’s good news really, because an Open Source system management portal has been released recently. It’s called Hyperic, and it’s sexy as this kind of thing can be. To make things even better, it has already been integrated with Mule, which does not hurt if you’re planning to use it as your ESB.

So here we are, all major components of our SOA are available through commercially-supported Open Source offerings, and we are working with our customers and partners to fit them all together into the underlying infrastructure that will make our BPMS rise and shine. If that sounds like fun, come join us and add your piece to the puzzle!

Open Source will drive BPM adoption
The release of a complete BPMS under an Open Source license should significantly reduce any barrier to adoption. The leading Open Source BPM vendor will capture the largest market share, while more companies will start BPM projects than in the prior three years combined.

Google will acquire a complete Office 2.0 suite
Google Docs is like ThinkFree’s Quick Edit mode: it works, but the feature set is way too limited to convince a large-enough number of Microsoft Office users to make the switch. Something akin to ThinkFree’s Power Edit mode is necessary, and buying it will certainly be quicker than building it. Google, which doubled its workforce to almost 10,000 employees in 2006 would rather spend cash and stock than waste time. ThinkFree or Zoho look like perfect targets, even though convincing the good folks at AdventNet won’t be an easy task. Apple Computer might make a similar move too, significantly enhancing the capabilities offered by the excellent .Mac online service. On the mobility front, Palm will likely be acquired as well, possibly by a telecommunication service provider.

Office 2.0 will start getting adoption in the corporate world
While early adopters will continue to be very small businesses and academic users, the corporate world will start playing with the technology as well. Individual users will favor large collections of applications such as Zoho, while corporate departments will prefer feature-rich suites such as ThinkFree. This movement will be acknowledged by several Gartner reports, as well as a cover article in BusinessWeek magazine.

All top ten off-shore software development firms will have a BPM practice
The Capability Maturity Model for Software (also known as CMM) has been retired, and the Capability Maturity Model Integration (CMMI) replaced it, with a stronger emphasis on business processes. The model-driven development approach enabled by Business Process Management (BPM) technologies makes it easier to measure and improve the quality of development processes compared to traditional software development approaches based on the writing of code. Off-shore software development firms have known that for a long time — Infosys was one of the first companies in the world to develop a working implementation of the BPML language back in 2001 — and will take advantage of it, now that commercial implementations have matured enough.

Open Source vendors will grow faster than their closed source competitors
More user accounts will be created on SugarCRM and vtiger combined than on Salesforce.com. Compiere will announce the successful migrations of several large Oracle E-Business Suite customers. Intalio will sign more new customers than Lombardi, Pegasystem, and Savvion combined. The vast majority of SOA projects will be using Open Source solutions such as Axis, Mule, and ServiceMix. And the first Open Source database vendor (EnterpriseDB, Ingres, or MySQL) to release a plug-compatible replacement for the Oracle database that can support the SAP R/3 application for over 10,000 concurrent users will get the best home run in database history since Sybase, but that might take a couple more years…

Apple Computer will make online data synchronization really work
Once the iPhone — or PodPhone, or whatever Steve decides to call it — is released, people will realize that its killer feature is not that it can play tunes, but that it can synchronize contacts and events in a wireless fashion more easily than any other system. Granted, such synchronization has been working fairly well with the BlackBerry+Exchange combination for quite sometime now, but who really likes to administrate a Microsoft Exchange server? Also, a Mac-compatible version of QuickBooks Online Edition will be released, unless a competitive offering steals the show first.

SOA will get simpler
The Java Business Integration (JBI) API will go the way of CORBA and be relegated to specific vertical industries such as telecommunication services. Large corporate users demanding very high transaction volumes — think Wall Street brokers & dealers — will favor lightweight application servers with streamlined stacks for Web services such as Apache Axis, and MuleSource will emerge as the leading Open Source ESB player. Production-grade ESB functionality will come for free with all major Open Source stacks, accelerating the demise of the few propriatery EAI vendors left standing.

Enterprise 2.0 will establish itself as a sticking meme
High-profile conferences originally focused on collaboration and e-Business will adopt the moniker, Oracle and SAP will incorporate Enterprise 2.0 stacks similar to Intel’s SuiteTwo within their respective product lines, and the SEC will issue new guidelines for corporate blogging.

Standards for online services will be adopted
Enough services supporting OpenID and Amazon’s Simple Storage Service (S3) will become available for early adopters to build a working Office 2.0 Setup that provides single sign-on and remote data storage. Open Source frameworks offering plug-compatible alternatives to Amazon’s EC2, S3, SQS will be released as well, enabling truly distributed backup strategies to be developed.

That’s it for now. Happy new year to you all again!

Disclaimer: I work for Intalio and serve as an advisor for ThinkFree and Zoho.

BPMS will go mainstream: Draw
The concept for a Business Process Management System (BPMS) has been gaining momentum, but I would not call it mainstream yet. The ground for BPM 2.0 has been laid, and the first Open Source BPMS has been announced. Nevertheless, customers are still trying to figure out what BPM really is, and which flavor for it will best address their needs initially. Gartner recently came to the rescue, suggesting that an Open Source solution might be a good way to get your feet wet initially. But a commonly-accepted compeling event for the deployment of a BPM platform — think e-Commerce for an application server — remains to be found. SOA might very well be it, but it’s losing ground as well, as illustrated on this Google Trends analysis, also mentioned in this earlier post. Like it or not, BPM is a complex concept, and it will take time for corporate buyers to get their arms around it. In the meantime, the best way to get there is to lower any possible barrier to adoption, and this is what Intalio is all about.

Industry consolidation will accelerate: Miss
No game-changing mergers or acquisitions were made in the enterprise software space this year, and IBM did not come back to the enterprise application game. Smaller deals have been stealing the show, especially Red Hat’s acquisition of JBoss, which must have compelled Oracle to finally make a move on the Linux front. The real question now comes down to this: how long will Salesforce.com remain as an independent company? IBM, Oracle, and SAP would all make pretty good buyers. Another option would be for Marc to finally extend his platform with ERP functionality, which could be achieved in several ways, one of them being to acquire Compiere or Intacct. Let’s hope the later comes true.

Office 2.0 will become a reality: Hit
Within less than nine months, the Office 2.0 Database, announced on this post, grew from nothing to over 330 applications. The concept introduced exactly a year ago got its first conference, with over 450 participants, 105 speakers, and 56 sponsors. Zoho emerged as a likely winner in the space, and ThinkFree demonstrated that web browsers are now powerful enough to support most of the features that are offered by traditional Office 1.0 productivity suites today [Disclaimer: I serve as an advisor for both companies]. Google’s release of
Google Docs on the first day of the Office 2.0 Conference also gave a clear signal that things are getting serious now, and that past involvements with OpenOffice.org were just smoke and mirrors. Next year, it will be interesting to see wether Microsoft finally releases something of substance under the Office Live brand, and who gets their hands on ThinkFree. The later would be a perfect acquisition for Google, but in the meantime an OEM deal with Intuit or Salesforce.com would make a lot of sense as well. Investors might also be interested to know that the company is giving serious thoughts to the idea of raising a small round of venture funding…

Software off-shoring will go further West: Hit
If your Indian off-shoring partner made you lose sleep over high employee turn-over, you might have considered going further West. During the past year, Eastern European countries such as Ukraine became a popular destination for the off-shoring of software development projects, so much so that the unescapable law of supply and demand kicked back in full swing. And because these countries are so much smaller than India, its effects were felt stronger, faster. Down the road, it seems that off-shoring is a dynamic process rather than a singular event, for which target destinations keep changing as local markets mature. Next steps? Latin America, Northern Africa, and China of course.

Open Source business models will prove themselves: Hit
Following on the footsteps of JBoss and SugarCRM, more and more enterprise software companies went the Open Source way, including Hyperic, Intalio, and Terracotta. Learning valuable lessons from their predecessors, many commercial Open Source upstarts are being liberal with licensing terms, which compelled some industry observers to challenge their claims. Next year should see a clarification of the rules, with the addition of generally agreed-upon terms for attribution to the ever more popular Mozilla Public License (MPL), with the blessing of the Open Source Initiative (OSI) hopefully.

All software will go the service way: Hit
Alongside the emergence of credible Office 2.0 solutions, all categories of software saw the release of online alternatives, including drawing, music playing, and video editing. A year ago, guessing the next category of software to go online was challenging. Today, the game has changed, and the challenge is to identify the one that will be the last. At this point, only one application is missing from my Office 2.0 Setup: a good online accounting tool.

SOA will get more complex: Hit
Service Oriented Architecture (SOA) was supposed to make integration simpler. Instead, it made everything a lot more complex, and the introduction of the Enterprise Service Bus (ESB) did not really help. Standards for Web Services kept multiplying, and the market kept fragmenting itself, with the Java Business Integration (JBI) API on one side, and slightly more pragmatic approaches such as Apache Axis on the other. Too many options create confusion, which vendors of proprietary solutions are the only ones to benefit from. Clarity and simplicity are much needed, but I’m not sure where they’ll come from next year.

Corporations will discover the beauty of social: Hit
LinkedIn will most likely sign its tenth million users in the coming quarter, and TIME Magazine named You (and that includes Me) as Person of the Year. Most searches made on Google return entries from Wikipedia within the top ten results, while the Internet Movie Database (IMDB) usually tops official websites developed by major studios for any new movie. During this past year, the corporate world started to pay attention, and the concept for Enterprise 2.0 was born, followed by commercial implementations such as Intel’s SuiteTwo. Next year should see an acceleration of the trend, with more and more practical use cases and success stories being released.

Standards for online services will emerge: Hit
Bugs have been added to the Office 2.0 Bug Tracker faster than standards have been released to fix them, nevertheless, a couple of initiatives have been gaining some significant traction, among them JSON and OpenID. Also, and against all expectations, Amazon started to release a set of commodity services (EC2, S3, SQS) for online computing that’s giving us a very good preview of things to come. Next year should see Google and Microsoft following on Jeff’s footsteps. The creation of a full fledge standardization body for Office 2.0 is not out of the question either.

Score: 7 Hits, 1 Miss, 1 Draw
Let’s call it a 83% success rate. Not too bad… In fact, it’s a little bit too good, and the reason for it might be that my inferences for ‘06 were a little bit too open ended. For next year’s, I will try to be a little bit more specific, which should make the challenge more interesting. See you next year!

The announcement was made to family and friends invited to a dinner held at the W Hotel San Francisco. Yvonne Avery was kind enough to extend an invitation, which gave me the opportunity to connect dots that would have looked like isolated stars otherwise. Back in 1999, Jan Baan, founder of the prioneer BaaN ERP company, made an investment in WebEx. He then went on to create Cordys, one of the most innovative BPM companies out there, spending about 200 million euros ($250M) of his own money for building what is arguably one of the very few BPM 2.0 platforms in existence today. Along the way, he shared his vision with Subrah S. Iyar, WebEx’s co-founder, Chairman and CEO. WebEx Connect is the vision’s first incarnation.

This is significant, because Mr. Baan knows a couple of things about processes. In fact, BaaN’s application was the very first ERP to be powered by what could be called a process engine, allowing business processes to be designed explicitely, instead of being buried into code. If you believe that Subrah Iyar knows his fair share about collaboration — over 2 million users would agree with you, then you realize that having the two work together on a collaborative composite process platform — I know, it’s a mouthful — could lead to some interesting results.

What’s even more interesting is that WebEx is not positioning Connect as a standalone product, but rather as a platform that other ISVs can use to develop on-demand applications. While WebEx’s partner ecosystem for Connect is not as large as Salesforce.com’s for AppExchange, it’s user base is 8 times as big, and the underlying technology — thanks to the use of the Cordys platform — looks a lot more like the kind of thing you would want to use in order to build enterprise-grade composite applications.

But technology is only one part of the equation. As my good friend Jason Lemkin from EchoSign pointed out, the real challenge for any SaaS vendor will be to develop distribution channels for its application. You can build it, but it does not mean they will come, as many Office 2.0 companies will find out sooner or later, unfortunately. On this front, yesterday’s event gave us very little insight in terms of what kind of co-marketing program WebEx will put together in order to promote its partners. At the end of the day, Salesforce.com, WebEx, and our good friends at Zoho — which interestingly enough appeared many times on the slides presented yesterday — will have to learn from the master of all platforms: Microsoft. No company has done a better job than the good folks from Redmond in developing an ecosystem around a single platform, and as Steve Balmer would tell you, it’s all about the developers. Make it work for them, and business will take care of itself.

Next month, WebEx will turn ten years old, and it looks like the company is everything as innovative as it was when it was created. The demo I saw yesterday gave me confidence that the most ambitious players in the field are making the transition from data to process, understand the need for Web 2.0 user interfaces, and acknowledge the fact that next-generation IT systems will be pioneered by your most creative knowledge workers, not your risk-allergic IT department. It will be quite interesting to see how Open Source players will learn from these new ideas, and build similar platforms from existing Open Source components. Alfresco + Intalio + Zimbra, anyone?

On the registration side, we’ve got good news and bad news. Good news: we received plenty of them. Bad news, we’ve got so many that we won’t be able to extend the early bird registration period. September 1st will be the last day to benefit from the $395 early bird special. After that, the registration price is $595. So if you want to save a cool $200, make sure to register now.

On the sponsor side, we’re proud to be joined by ThinkFree, which has one of the most complete Office 2.0 productivity suites currently available. Also, Coghead has decided to use the event has launch pad for their product. This makes me pretty happy, because I wrote about this company six months ago, and I was really eager to know what they were up to. It looks like the wait should be well worth it: if you want to know what BPM on demand should look like, look no further, for my friend Greg Olsen has it all figured out.

For managing the marketing of the event, we joined forces with SugarCRM and will use their on-demand deployment option. Our account will be activated tomorrow, and we will upload all our data for participants, speakers and sponsors. Blogtronix will demonstrate their corporate blogging solution, and Socialtext will provide the conference’s Wiki, which we will launch next week and will use to collectively refine the content for each panel. Also, Netvibes will be used as virtual desktop on all demo pods. Many thanks to Jeff Clavier for this one.

Over the past seven days, we received more and more pressing requests for an Enterprise 2.0 track to be developed throughout the conference. Our Editorial Board, which is made of members of the illustrious Enterprise Irregulars group, took this advice to heart and started inviting companies that have interesting things to say on the subject. As a result, ActiveGrid and BEA decided to join us as sponsors. Now, all we need to do is make sure that the super-stealth and ultra-cool Abgenial uses the event as launch pad as well. With Oren Michel’s Mashery added to the mix, we should have a pretty good overview for the state-of-the-art technologies that are available today for enterprise mashups. And if yet another 2.0 meme is confusing you, just memorize this simple equation:

On the speaker side, we added biographies and pictures for all 52 speakers and panelists, which now include Michael Arrington, Editor of TechCrunch, Jeff Benrey, CEO of Trovix, Stowe Boyd, Managing Director of A Working Model, Kevin Hale, Co-Founder of Wufoo, J.B. Holston, CEO of NewsGator, Robin Hopper, CEO of iUpload, TJ Kang, CEO of ThinkFree, Paul Kedrosky, Venture Partner at Ventures West Management, Tariq Krim, CEO of Netvibes, Michael McDerment, CEO of FreshBooks, Vassil Mladjov, CEO of Blogtronix, Craig Remy, CMO of Intacct, Peter Rip, Partner at Leapfrog Ventures, Paul Wiefels, Managing Director of The Chasm Group, and Peter Yared, CEO of ActiveGrid.

Regarding the final program for the conference, our Editorial Board will meet tomorrow evening at Socialtext’s headquarters in Palo Alto and dispatch speakers and panelist across keynotes and panels, for both plenary and breakout sessions. The schedule will be published on Friday this week, or Monday next week at the latest, using the excellent 30 Boxes calendaring service. If you’re a speaker and do not like the spot you will be granted, please do not complain to me, for I won’t be directly responsible for it. The Editorial Board is. Only problem: it does not have an email address, and I do not have any desire to create one at this point. So I really hope you’ll like the spot these guys will give you. Really.

From a logistics standpoint, the promotion code for the St. Regis Hotel should be communicated very soon now. If you think it’s long overdue, you’re absolutely right. All I can say is that Starwood would certainly benefit from a good injection of Office 2.0 productivity. If you know anyone there, please make sure to send them an invite to the conference.

Last but not least, all demo equipments for sponsors will be purchased before the conference. We’re talking about 20 complete setups made of a cute Apple Mac mini, a 20-inch Apple Cinema Displays, a keyboard, and a mouse. We will sell 10 of them for 25% off retail price immediately after the conference. If you want to buy one or two, just drop me a line, and I’ll put them aside for you, all neatly packaged in their orignal boxes.

That’s all for now. Lot’s of catch up on blogging ahead of me…

Why don’t analysts cover Intalio more?
Because we do not pay them anymore. Sorry, I could not resist… Yet, this is not far from the truth. We do not spend enough time with them, for we have very limited marketing resources. I am the one responsible for this, and I am trying to fix it, with an analyst roadshow to take place in September. During my seven years working for Intalio, I’ve learned that industry analysts won’t say much about you if you do not brief them first, in a proactive manner. Analysts from the private banking world do though. In fact, the best research seems to be made by bankers, which sort of makes sense when you think about it: what they research has a direct impact on their own money, not their customers’ money… Overall, I think analysts should be paid by customers, not vendors. This would add a lot more credibility to their work. But who am I to say that?

Will we integrate Intalio|BPMS with an Enterprise Portal?
It’s done already. the user interface components of Intalio|Workflow are already packaged as JSR 168 components. And we have a customer in Canada who is working on some integration with Liferay Enterprise Portal, which James referred to. We are also considering integration with content management systems such as Alfresco for example.

What should the Open Source community do to promote our sales process?
CEOs of Open Source companies already do that to a certain extent, and Marc Fleury is a good example for this. What’s missing is more metrics on what’s working, and what’s not, and clarification around the concept of downloads. Part of the problem is that the number of downloads seems to be the metric that Open Source companies are evaluated against. Personally, I think that the number of qualified registrations to a user community is a much more interesting way of sizing the user base for a commercial Open Source product, and serving as upstream feed into the sales process. Clarifying the terminology used to describe one’s community would benefit all involved.

How could BPM enable fine-grained entitlement?
This is an issue very dear to my heart. Four years ago, I introduced the idea of using the BPMS as ‘Process Firewall’, as illutrated on this partner website, which transcribes sections of our website circa 2002. The idea for a process firewall is pretty simple: model your process in BPMN using multiple swimlanes, one for each participant, be it a human being, an external system, or another process. The very action of breaking your process down into participants implicitely defines who can do what, which is also called authorization, or entitlement. Essentially, entitlement definition becomes a simple by-product of process design, and it’s one that comes out for free, with the right level of granularity. Back then, very few people understood the idea, but today it seems to be gaining a lot more acceptance. Timing is everything…

How many customers does a typical BPM vendor have?
Most pure-play BPM vendors will claim to have several hundred customers. Some traditional workflow vendors have thousands of customers. But if you’re looking for customers that have used BPM products themselvess without relying on the vendor’s own consulting services, I doubt that very many BPM vendors really have more than a handful of these, if any at all… And you’ll be hard-pressed to find these customers talking freely about their experience on the Internet. This is what we are trying to change. Customers, speak up, please!

On one hand, and to a large extent, the Service Oriented Architecture (SOA) is a solution in search of a problem, and the Return on Investment (ROI) customers can expect from any SOA initiative has been a hot topic of discussions as of late. In such a context, Business Process Management (BPM) might very well be the one indisputable reason why any IT shop should consider deploying SOA today.

On the other hand, the benefits BPM can offer to the business, in terms of agility, affordability, and accountability, cannot be gained without the proper underlying infrastructure. So far, BPM has remained a point solution, deployed through proprietary products. The emergence of SOA, and the establishment of industry standards that take advantage of it — BPEL being first among them — should lay the ground for BPM’s mainstream adoption.

BPM is SOA’s Killer Application
The problem with the Service Oriented Architecture is that it is exactly what its name implies, an architecture. It’s a set of guiding principles. It’s a philosophy. It can help an architect design a blueprint for something concrete, but nothing more. It is not the blueprint, even less the building. Architecting is not building, and if companies do just that, they’ll end up with very little in the end, after having spent a lot of time, money, and efforts getting there. SOA should not be seen as the end, but the means to the end. The challenge then becomes about finding what the end is that will justify the means.

Advocates of SOA have heralded the need for agility as the main business driver for deploying their architecture of predilection. Unfortunately, business types have found it difficult to understand how SOA could provide true business agility. The most litterate among them might have realized the benefits it could bring to their IT departments in terms of costs reductions, but the other quickly dismissed it as yet another IT fad.

From a business standpoint, a service is too small a unit to really appeal to the business side of the house. Its granularity is too fine. And it’s only when elevated to the level of processes that business folks usually start paying attention. Reusing a currency conversion service across multiple applications, and saving three man-month of development along the way, is one thing. Being able to shave three weeks in the overall order-to-cash process is another. Guess which of the two will get the CFO’s attention?

Once customers start putting a Service Oriented Architecture in place, the desire to tie their newly-available services together into coarser-grain services, or higher-level processes, is felt rather rapidly. This should not come as a surprise: services can be seen as neatly-packaged units of functionality, and the main reason for such a packaging is to enable their composition.

Now let’s make a little experiment: I suggest you draw a set of boxes on a white board, and give them names of ‘services’ that make sense for the particular business you’re in. Then ask a colleague to ‘combine’ them into something useful. I bet you that what you’ll see being drawn on the white board is a set of arrows connecting the boxes, and resembling the flowcharts you used to draw when practicing the principles of the good old Business Process Reengineering methodology. Here you have it: a process!

But BPM would not be SOA’s killer application if it would work only after you get SOA, for, as we indicated before, you might never get it. Instead, BPM is SOA’s killer application because it will give you the reason for doing SOA at the first place. Without BPM, the main ROI for SOA is reduced IT costs. With BPM, you can directly link the ROI for your SOA project to the ROI you could get from any improved business process. All you have to do is ask the business which processes they’d like to fix first, put Return on Investment tags on them, and you’ll get the justification for your SOA initiative, with the budget to deploy it.

Better yet, deploying SOA in the context of BPM-powered process work will give you the right SOA. Here is why. SOA is more philosophy than religion. The book of SOA is more Tao Te King than Bible. For example, no consensus has emerged as to what the level of granularity of services should be. Some will say it should be at the level of fulfilling a purchase order, orders will advocate that it should be lowered to the level of recording the purchase order, yet others will recommend that it should be down to the level of creating the header for the purchase order, while using another service to record each line item. Who’s right? Nobody knows…

In reality, there is no absolute answer to this question, and the right answer will depend upon the business scenario — not to say business process — the question was asked in relation to. As a result, deploying SOA in the context of a BPM process will help you package services with the appropriate level of granularity, at least within the context of the business processes they’ll be involved in. Nothing will prevent you to compose coarser grain services out of smaller existing ones, or expose technical details of another into finer grain ones, but you will do it for a very good reasons, always justified by business requirements. Again, SOA is a means to an end, and the way this means is shaped usually depends upon the actual end that is sought after.

For all these reasons, BPM is SOA’s killer application.

SOA is BPM’s Enabling Infrastructure
One of the main ideas behind BPM is to abstract technical systems and requirements in such a way that new business processes could be designed, deployed, executed, monitored, and optimized, without having to write any software code, while most of the work would be done by non-technical folks — or at the very least less-technical ones.

This in turn would bring agility, affordability, and accountability to the business. Agility as in the ability to change the process as fast as the business itself is changing. Affordability as in the ability to deploy, in a cost effective way, a new process that could not have been deployed with any other technology before. And accountability as in the ability to prove, in a non-ambiguous way, that what your IT systems are doing in relation to your business processes is exactly what they were intended to do at the first place — in today’s SoX-constrained world, people are discovering this to be a lot harder than they initially thought.

To some, this idyllic scenario might sound too good to be true, and until recently, it really was. Without a way to provide the functional richness of existing systems packaged into reusable units, without having to expose their technical complexity, what could have been presented as a silver bullet actually turned into magic pixie dust, which is another word for vaporware. It just did not work, or at least not as advertised, and behind the neat little boxes and arrows, armies of developers would have to write arcane code, using languages such as C++, Java, or JavaScript.

Granted, there were some technologies that could have been used to make it work. CORBA was one of them. Problem is, as early incarnations of what we call SOA today, they were not ready for prime time, and more often than not turned out to bring more complexity, exactly where there should have been less. Again, it just did not work.

Then came XML, and the idea of using standard Internet protocols to connect all the pieces together. People called it Web Services, then started thinking about an architecture for managing it all, and SOA was born. It took some more years for the concept to mature, but it eventually reached a critical mass of adoption, making it the de-facto standard for any enterprise architecture today.

Of course, industry standards played a key role in this adoption process. By its very nature, SOA is all about enabling different actors (people, processes, and systems) to communicate with each others, and sharing a common language is usually a good way to foster communication. This lead to the development of specifications such as SOAP and WSDL, which today are the fabric of any new application being developed.

Right around the same time, industry standards for BPM started to coalesce as well. BPML got rid of proprietary languages — very few remember WSFL and XLANG today, and was eventually replaced by WS-BPEL — also known as BPEL, which took full advantage of the emerging stack of standards for Web Services — as well as IBM’s deep-pocketed marketing resources. But because boxes and arrows seem to be more pleasing to the eyes of most business analysts than angle brackets, BPMN was developed, and eventually established as the standard graphical notation for the modeling of executable business processes.

Ultimately, a stack emerged. WSDL for packaging services, BPMN for designing processes, and BPEL for executing processes built out of packaged services. All of a sudden, true BPM — what some call BPM 2.0 — became possible. It worked in a Zero Code manner, supported One Click Deploy for the most complex processes, and enabled a groundbreaking middle-out approach that empowered business analysts and less technical folks — called process analysts today — to work together on the same process, using the same tool.

Then BPM started to work, enabled by SOA.

First, I would like to understand how SAP NetWeaver will really support BPMN and BPEL. And I would like to know whether SAP is afraid that Oracle could eventually acquire IDS Scheer, following the recent announcement of a partnership between the two companies. IDS Scheer ARIS is a key component of NetWeaver’s BPM offering, and losing it to Oracle would certainly not be a good thing for SAP and its customers.

Second, I would like to see how SAP plans to integrate some Office 2.0 technologies within its offering. As said before, Duet is nice but duos are better. Zoho has been invited to participate in the Web 2.0 in the Enterprise think-tank session organized by SAP, and I am very curious to learn more about SAP’s plan in this area, especially following Edwin’s comments to this post.

Third, I would like to better understand SAP’s strategy with respect to SOA, and especially how it defers from Oracle’s, as claimed in this very interesting article published by TheServerSide, and shared with me by Assaf Arkin.

If you have any other SAP-related questions, feel free to send me an email, and I will do my best to get answers from the right people. In the meantime, here is what I wrote during SAPPHIRE:

Many thanks again to SAP for being so supportive of the blogging community. And congratulations to Jeff Nolan for having secured support for a second event. This definitely proves that the first one was successful, and not one of these blue birds that you see only once in your lifetime.

Question to IBM, Oracle, and Salesforce.com: when will you jump on board?

Whether you go top-down or bottom-up to cross the business-IT divide, the gap remains the same. There is nothing magic in this, it’s just called Euclidian geometry. The main idea behind the promotion of a new type of developer known as Process Analyst is to provide a way to bridge that gap, in a middle-out fashion. Start from a middle ground that both business and IT can understand — I believe that BPMN is as good as it gets for this, then reach out to the business side through business metrics that business types love to play with, and to the IT side through BPEL as a way to embrace its newfound love for all things SOA.

BPM and SOA are the two sides of the same BPM 2.0 coin. BPM is SOA’s killer application, while SOA is BPM’s enabling infrastructure. Try using BPM without SOA, and all you get is Business Process Reengineering or traditional workflow. Deploy SOA without BPM, and you’ll find it difficult to justify any Return on Investment to a business buyer. If there is a BPM vs. SOA war, it is fought by BPM vendors who cannot embrace SOA for they do not natively support BPEL, or SOA vendors who cannot embrace BPM for their products will always require coding. Take your pick!

According to the BPM 2.0 model, web service interfaces should be generated on the fly for any application or middleware system that supports some form of API, and there are very few that do not today. Even legacy mainframe systems can expose APIs through the use of common screen-scraping tools. A good BPMS will be able to leverage these APIs and generate web service interfaces for it. Furthermore, the BPM 2.0 model also states that such interfaces should be offered for both inbound and outbound transactions, meaning that a BPMS can invoke a transaction with a third-party system through a web service interface (inbound), while a third-party system can call a process deployed on a BPMS through a very similar interface (outbound).

This answers a question that we get all the time: “do I need SOA to use BPM?” The answer is both “yes” and “no”. Yes, you need SOA to use BPM, for that’s how the BPEL execution model was designed. But no, you do not need to have your Service Oriented Architecture in place before being able to use BPM, for the mere installation of a good BPMS will SOA-enable most of what you already have, or at least it should. If you pick the right BPMS, it will come with an Enterprise Service Bus (ESB) and a Service Repository that are the cornerstones of any Service Oriented Architecture worth using. In other words, buy BPM 2.0 and you’ll get SOA for free. And if you’re lucky enough to pick an Open Source BPMS, you won’t even have to pay for it. Is this a good deal, or what?

Both Dion and Sandy advocate in their articles (Dion’s, Sandy’s) what are referred to as enterprise mashups. To the IT expert, these might not look much different from plain-vanilla Enterprise Application Integration (EAI), but customers will like the former much more than they liked the later. Mashup sounds quick, and easy, and fun. Integration sounds expensive, and difficult, and plainful. Words matter.

Quite frankly, I do not know what BPM should be called to regain it’s appeal. When I wrote the first white paper on BPMS in the Spring of 2000, my coach at the time (Marylene Delbourg-Delphis) advised me that the word process had some bad connotation, inherited mainly from the Business Process Reengineering legacy. I was young(er) and foolish(er) at the time, so I did not pay much attention to it. I should have had, but there is no time for regrets now, so we’ll have to stick to the word ‘process’ I guess. But the word ‘mashup’ sure sounds cool, so I might start writing about process mashups more and more. We’ll see if that one sticks…

UPDATE 6/21/2006: Joe McKendrick wrote a good article on Mashup vs. SOA.

I intend to learn more and write quite a bit about SAP NetWeaver, the upcoming Business Process Platform, and SAP’s plan regarding Open Source and Software as a Service. If you happen to be there as well, please feel free to drop me a line and let’s meet for a drink, a motorcycle ride, or a short trip on an airplane. Many thanks to Jeff for the invitation, and kudos to the folks at SAP who seem to really get this blogging thing.

And another Office 2.0 bug got fixed today: welcome ajaxTunes!

Tim Clark suggested ‘Mobility’ as 11th flattener, Jeff Zwelling made a very convincing case for ‘Instant Feedback Loops’ as a comment to my original post, and all participants agreed that the flattening of the world is a process, not an outcome. Sanjay Kalra and Jeff Nolan also had good things to say about the event. I would like to thank everybody who partipated. Also, many thanks to Lohika for their sponsorship of the event.

The next breakfast will take place in the Bay Area sometime in May and will be dedicated to BPM 2.0. If you’re a BPM vendor or a BPM practitioner and would like to contribute to the definition of this new market category, drop me a line and I will add you to the guest list.

Flattener #1: 11/9/89
When the Walls Came Down and the Windows Went Up
The fall of the Berlin Wall made the world an open playing field. Today, Intalio does most of its business in North America and Western Europe, but we’re getting more and more demands from Latin America, Eastern Europe, the Middle East, South Africa, Asia, and Australia. The Wall has been down for more than sixteen years, but as an American company, we still cannot do business with Cuba, Iran, Sudan and Syria.

Flattener #2: 8/9/95
When Netscape Went Public
The Internet is the infrastructure that made BPM possible. It gave us web services and a Service Oriented Architecture that allows processes to be integrated with existing systems at a fraction of the cost of traditional EAI approaches. It provided the communication vehicle for the Open Source movement to really catch on and dramatically lower the cost of commodity software components. Finally, it gave us the vehicle through which we can market and sell our software, using participative communication tools such as this blog, and circumventing the physical packaging of software, thereby allowing us to conduct our business in a purely electronic way.

Flattener #3: Work Flow Software
Let’s Do Lunch: Have Your Application Talk to My Application
Standards such as BPMN and BPEL are enabling interoperability across Business Process Management Systems in a way that early workflow pioneers could only dream of. Public APIs for popular online services are turning the BPMS into a mean and lean mashup machine, paving the way for truly componentized IT architectures where system architects simply assemble existing components, and software code writing is reserved for the most arcane applications.

Flattener #4: Open-Sourcing
Self-Organizing Collaborative Communities
More than 80% of the code developed by Intalio is Open Source and in the process of being donated to the Apache Software Foundation and the Eclipse Foundation. This code forms only 20% of the software we ship to our customers, the remaining 80% being borrowed from existing Open Source projects. This participative model is pushed a step further with the introduction of a Demand Driven Development model, whereby smaller communities of users participate in the funding of specific product features, which are in turn donated back to the Open Source community. This creates an accelerating factor that turns traditional closed-source development into a massive competitive disadvantage.

Flattener #5: Outsourcing
Y2K
Most functions that are not core to the business are outsourced. This includes facility management, human resources management, public relations, advertising, finances, legal, software development, quality assurance and testing, consulting, and customer support. The only functions that are kept in house are the ones that are critical to the development and distribution of a complex software tool: architecture design and customer training. Most of the engineering team that remains on our payroll is composed of highly talented architects, while we use our training group as the most technically-aware pre-sales organization.

Flattener #6: Offshoring
Running with Gazelles, Eating with Lions
Most of our software engineering is done out of Western Ukraine, where we find extremely talented developers at a rate similar to what we would pay in India, but with a yearly turnover of less than one percent. Our software quality assurance and testing is done out of Bangalore, India, where we are also setting up a support infrastructure that will be available from 9 AM GMT-1 (Paris) to 6 PM PST (Tijuana, CA). We are also working on the development of telesales organizations to be based in India and Ireland.

Flattener #7: Supply-Chaining
Eating Sushi in Arkansas
Several customers have asked us for the packaging of our BPM software into a hardware appliance. The question is not whether we will do it or not, but when. Because we want to remain a software company and do not want to manage an inventory of expensive hardware products, we’ve been discussing with supply-chain partners that can take the most recent version of our software, install it on hardware appliances, and get it shipped to customers in less than 48 hours, anywhere in the known world.

Flattener #8: Insourcing
What the Guys in Funny Brown Shorts Are Really Doing
Our decision to release our first BPM appliance will be driven by a single metric: volume. We will pull the trigger as soon as customer demand will be sufficient enough to allow us to work with in-sourcing partners such as DHL or UPS in order to provide technical support for the hardware part of our solution.

Flattener #9: In-forming
Google, Yahoo!, MSN Web Search
Intalio’s marketing budget is pretty low. In fact, for the time being, it does not even exist, and this blog is the only marketing investment we’ve made over the past three months. We do not go to tradeshows, unless we’re invited to speak there and travel expenses are paid by the event’s organizers. We do not advertise in any trade magazine, and instead work hard to get the BPM 2.0 section of this blog to be syndicated by online publications such as BPMG, BPM Institute, and BPTrends. Moving forward, the only marketing expense we are planning to make will be for Google Adwords, but we will do it in such a way that it directly pays for itself, by tracking the conversion of paid-for clicks into paying customers for our training services, using Google Analytics in combination with Salesforce.com.

Flattener #10: The Steroids
Digital, Mobile, Personal, and Virtual
Our biggest productivity enhancer is called Office 2.0. All our customer information is managed by Salesforce.com, our software documentation is developed through Confluence, an enterprise Wiki platform, and our internal communication is conducted through blogs, email and Skype.

Looking at it from that angle, the world seems pretty flat indeed…

Many thanks to Alex for recommending Thomas L. Friedman’s great book.

BPM will go mainstream. Integrated BPM solutions will be made available for free and will include everything you need to design, deploy, execute, monitor and optimize business processes. They will be supported by commercial vendors, dramatically raise the bar for competitors and radically lower barriers to adoption for all users.

Consolidation will intensify. Very few pure play BPM vendors will remain standing. Those that do will go vertical by selling specific business applications and getting their core BPM capabilities from Open Source projects or established vendors such as BEA, IBM and Oracle.

All major System Integrators will have BPM practices. The most innovative will be found in India and will blend BPM with BPO (Business Process Outsourcing). Most will standardize on standard methodologies such as BPMN. A few will adopt specific products at a corporate level.

The Apache Software Foundation will acquire a BPEL server, or two. Both the Geronimo project and the Web Services project will add a BPEL server to their respective stacks. One will become the most widely used BPEL implementation in the industry, much as Apache’s HTTP server is the most widely used web server on the Internet today. Competition from JBoss will fail to materialize for lack of focus on a user base that cannot write Java code.

BPMN will be extended to support Human Interactions Management. The BPM community will realize that having two separate notations, one for web service orchestration and the other for human workflow, defeats the whole purpose of BPM. One unified notation will emerge. This notation will be called BPMN and will incorporate most of the concepts found in HIM.

BPEL 2.0 will become the de-facto standard for BPM. All BPEL vs. BPML discussions will be put to rest. Support for distributed transactions will be made available, finally. A formal BPEL4People specification will be released and many proprietary extensions will emerge. Standardization efforts will keep most of us busy for very many years to come.

A first set of standards for BAM will emerge. IBM will lead work, with the participation of some Business Intelligence vendors. First implementations will be available before the end of the year.

All ESB offerings will support BPEL. Most will embed a lightweight, non-persistent implementation, coupled with a rule engine such as Corticon or Drools and will be used for advanced message routing and complex event processing. Some will embed a more advanced BPEL engine that supports persistence and distributed transactions.

BPM as a Service will not materialize. Lack of customer demand, inappropriate user interfaces and security concerns will prevent the Software-as-a-Service model to become successful with BPM. Only workflow automation services sold to specific vertical industries such as banking and insurance might have some limited traction. The situation will change only when Office 2.0 models establish themselves in the corporate IT world, toward the end of the decade.

The first BPM appliance will be released. It will accelerate adoption by simplifying purchasing and installation. It will be available in two forms, as a desktop appliance for development and as a data-center rack for production.

The first grid-enabled BPEL engine will be released. It will be deployed on thousand of servers for CPU-intensive tasks. Similar engines will be ported to Network Attached Processing solutions such as the Azul Compute Appliance.

This is it for now. Let’s reconnect on December 31, 2006 to check which of these inferences actually materialized. Until then, happy BPM to all!