Rethinking BPM in a mashup-based SOA world
Is that enough acronyms for you? In this context, BPM is Business Process Management. It can also be Business Performance Management (like what Mercury Interactive does) or Business Process Modeling (a discipline of Business Process Management). Mashups are a new breed of application (and ecosystem) I describe in detail here. SOA is Services Oriented Architecture where the components of your application are actually discreet services that live on an intranet or the Internet and that are typically accessed through XML-based application programming interfaces (API, another acronym). Anyway, this is a long lead-in to a pointer to a piece by Sandy Kemsley who clearly gets the direction corporate software development is heading:
Stephen O'Grady pushes the concept of SOA to include mashups, and even Baseline Magazine is talking about how mashups can free you from the tyranny of software vendors with a discussion about how some of the services feeding mashups could be used in an enterprise integration context.....Imagine the next step: as corporate IT departments get over their "not invented here" fears, the BPM tools allow them to integrate not just internal web services, but external services that are part of the Web 2.0 mashup ecosystem. Use a Salesforce.com service to do a customer credit check as part of processing their insurance application. Integrate Google Maps or Yahoo maps to determine driving directions from your service dispatch location to your customer's location....Dion Hinchcliffe thinks that 80% of enterprise applications could be provided by external services, which is a great equalizer for smaller businesses that don't have huge IT budgets, and could almost completely disconnect the issue of business agility from the size of your development team. I think that it's time for some hard introspection about what business that you're really in: if your organization is in the business of selling financial services, what are you doing writing software from scratch when you could be wiring it together using BPM and the global SOA that's out there?
Kemsley, O'Grady, and Baseline aren't alone in seeing the potential of the mashup ecosystem to serve mission critical applications. At Mashup Camp at the Computer History Museum in Mountain View, CA (coming up in three weeks), sessions 5, 6, and 10 (respectively; Best Practices for API providers, Standards and MicroFormats for Mashups, and Identity Management and Security In Mashups) involve some very enterprisey topics that the attendees have expressed a strong interest in discussing. To wit, attendees from the banking and government sectors have questions about the management of user IDs across domains (when a mashup involves multiple APIs each of which relies on its own identity management technology) as well as the reliability of public components. For example, if an enterprise dispatch application along the lines of what Kemsley describes above relies on Google or Yahoo for its mapping component, enterprise architects want to know what Google and Yahoo are doing to ensure the uptime of the relevant APIs (a particularly relevant question given the recent outages at the Software-as-a-Service-based Salesforce.com). Orthogonal to that is the question of standard syntax for common APIs. For example, should there be a standard XML call for all mapping services which in turn might allow enterprise architects to easily build some fault tolerance into their applications. Code example:
If MAPproviderA is responding
Use MAPproviderA
Else
Use MAPprovider B
EndIf
Standard Mapping API call goes here.
Best practices on the API evolution front are also a concern; not just to enterprise architects, but also to mashup developers looking to turn their innovation into a business. As API providers improve their APIs, what measures are they taking to make sure that those improvements don't break the existing applications and mashups that rely on them (can you imagine an enterprise application grinding to a halt due to changes in one of the APIs it relies on?).
Finally, to the extent that enablers like Ning and mapbuilder.net are making child's play out of simple mashup development, might those abilities trickle up into SOA-based application orchestration tools in a way that finally puts enterprise application development capabilities into the hands of ordinary business managers? After all, if it only takes five minutes to develop an application like ZeroBars (at David Isenberg's request), can't anybody do it? This of course takes the PC-conundrum that IT departments had to deal with back in the 80's to a whole-'nutha level. Once business managers start developing applications, who is going to manage and support all that code? It's bad enough when a professional programmer leaves your company (where there's a higher probabability of some intra- and extra-code documentation). Ordinary non-developers on the other hand are completely unfamiliar with such disciplines and the risks of ad-hoc software that organizations could end up relying on. Trust me. I know. In a former life, part of my job was to rescue, resuscitate, and/or document rogue dBase code.