The second day started with a keynote by Daryl Plummer, BPM/SOA Elixir (unfortunately, I missed the breakfast session with Michele Cantara about the BPMS market, but I ended up in a fascinating discussion about requirements collaboration using wikis with Jason Klemow, and the concept of subscribing to processes with specific attributes in a BPM with Dennis Nickel of Telus).
Plummer obviously likes to play with the new technology, which I suppose is a prerequisite for his job: he talks about TiVo and Second Life as things that are fast becoming essential parts of culture, although it’s clear that few people in the audience (except maybe me) embrace both the concept of downloading and consuming what I want when I want it, and the importance of online social networks.
He starts with some basic definitions of “service”, especially the relationship between processes and services, to drive home the idea that SOA impact people too, not just systems. He also made an excellent distinction between a model-driven (process-centric) view and a typical programmer view of things: a model-driven view describes what a person does (the business process); a programmer view describes what the system does (the code that attempts to implement that process). After having a discussion earlier about defining processes based on the data values that flow through those processes, when I couldn’t quite elucidate why that wasn’t ultimately the right way to do things, this strikes me as an important distinction.
He summarized the results of Gartner’s 2006 CIO survey (“CIOs are programmers that are passin’ for normal folk”), where the top business trend is improving business processes: there’s a lot of pressure all around to automate processes and improve them along the way, and this is going to happen only with both SOA and BPM. Plummer takes the enterprise architecture view of this, which I really appreciate — business context and functions driving from the top of the architectural view, and services as a way to fulfill the needs of the business. Processes need services to be implemented quickly and effectively, and services aren’t of use unless they are consumed by processes. SOA allows us to build an infrastructure of shared services for ready consumption by processes.
One of the key reasons for SOA and shared services is that legacy apps are still hanging around, in spite of all our efforts to get rid of them. Adding a service layer over the legacy apps allows us to create higher-level services and processes that consume these services without having to know how — or even what platform — to access the data directly on its original platform.
SOA, as Plummer reinforces, is an architectural style: not web services (although web services can be used to implement SOA), not a particular product, but encapsulated functionality accessed through a standardized interface that allows for loose coupling of services and applications. He goes through a checklist of how to know SOA when you see it, although some of the items on his list (such as a centrally managed runtime middleware network) are not, strictly speaking, an essential part of SOA.
He continues on with a discussion of event-driven processes (he refers to them as event-driven services in counterpoint to BPM-driven services, which is not necessarily a separation that I agree with). Services, properly implemented, can be combined into event-driven processes rather than structured, pre-defined processes, in order to be able to respond to events that happen in an unexpected order or manner. I did, however, like his view of the “new” application container: UI and navigation via a portal, security and management as part of the network, and logic and data accessed via services from wherever they might exist. Explicit orchestration ties all this together, which provides agility in the process model.
He points out that an SOA is never finished: in fact, it’s designed to never be finished. He uses the analogy of the Sagrada Familia in Barcelona, a cathedral that’s been under construction for more than 100 years now, and continues to change as it is built. He covers off some things about development techniques to be used when developing services within an SOA infrastructure, and highlights the business service repository as a centrepiece for BPM’s use of SOA.
His final recommendation is that the critical path to competitive business advantage goes through SOA and BPM: you need to use SOA as the underlying mechanism, BPM as the methodology for tying things together in order to get the business process improvement that’s required to differentiate your organization in the marketplace.