Earlier today Amazon announced the launch of its Simple Workflow service (SWF) in beta. The announcement (and the attendant – and detailed – blog) explain that:
Amazon Simple Workflow coordinates the flow of synchronous or asynchronous tasks (logical application steps) so that you can focus on your business and your application instead of having to worry about the infrastructure.
So: has Amazon introduced a technology that will be useful to organisations looking to implement BPM projects in the cloud? And: how does this fit into the other offerings that are currently available?
To be clear – Amazon’s SWF is a programming framework which will help developers to handle stateful and potentially long-running workflows without having to write loads of tedious custom infrastructure code; and that means that for lots and lots of application developers building SaaS and PaaS propositions, it’s something that is definitely worth exploring.
From what I can tell from an initial pass, SWF can be used not only to assist with programming workflow behaviours that are ‘internal’ to applications that will be hosted on Amazon’s AWS platform; but also used to coordinate execution of tasks and applications that are distributed across multiple cloud platforms and also across a cloud/on-premise boundary. And that means that SWF could be pretty useful for companies building application services on AWS that need to manage long-running state, and also for companies looking to build cloud-based integration platforms and channels where the primary purpose is to coordinate systems from a central cloud-hosted logical point. Again from first sight, SWF appears to be not a million miles away from what Microsoft provides with its instantiation of the Windows Workflow Foundation within the Azure Platform – and that’s unlikely to be a complete coincidence.
But SWF is *not* a BPM tool or platform in any significant sense, just like a combustion engine is not a car. You can’t use SWF to manage processes through their lifecycles, and you have to code tasks and flows by hand using programming languages rather than through abstract models. But in theory – because there’s some simple runtime instrumentation available, as well as support for things like external signalling (enabling unexpected events to alter flow behaviour at runtime) - you could build a moderately sophisticated BPM toolset based on SWF as the core of the runtime platform.
For me, the announcement of SWF is significant not really because it will quickly help organisations get their business processes under management, become more effective and agile and so on, but because it’s yet another signifier that:
- There’s a growing understanding in the general application software developer community that co-ordination of work is something that needs to be supported explicitly; it’s not enough to build another generation of systems of record; and
- Cloud-based application services are a mainstream consideration, and the things that the majority of industry cares about (not innovators and early adopters) – how do I get this to co-ordinate with other things I have, how do I get data in and out of it, and so on – are rising up cloud platform providers’ agendas quickly.
I’ll be looking for SWF customers to talk to over the coming months to see how much real ‘business process’ work gets done, and how much is integration pipeline work; and also trying to dig into some of the potential technical and commercial limitations that arise in practice.
I’m interested to know what you think, too – is SWF interesting? (For that matter, is Microsoft’s Workflow Framework on Azure interesting?).