Immediately after the Spotfire-BPM session, I was up to talk about using BPM to drive top-down service discovery and definition. I would have posted my slides right away, but one of the audience members pointed out that the arrows in the two diagrams should be bidirectional (I begged forgiveness on the grounds that I’m an engineer, not a graphic artist), so I fixed that up before posting to Slideshare:
My notes that I jotted down before the presentation included the following:
- SOA should be business focused (even owned by the business): a top-down approach to service definition provides better alignment of services with business needs.
- The key is to create business-granular services corresponding to business functions: a business abstraction of SOA. This requires business-IT collaboration.
- Build thin applications/processes and fat services to enable agile business processes. Fat services may have multiple operations for different requirements, e.g., retrieving/updating just the customer name versus the full customer record in an underlying system.
- Shared business semantics are key to identifying reusable business services: ensure that business analysts creating the process models are using the same terminology.
- Seek services that have the greatest business value.
- Use cases can be used to identify candidates for services, as can boundary crossings activity diagrams.
- Process decomposition can help identify reusable services, but it’s not possible to decompose and reengineer every process: look for ineffective processes with high strategic value as targets for decomposition.
- Build the SOA roadmap based on business value.
- SOA isn’t (just) about creating services, it’s about building business processes and applications from services.
- Services should be loosely-coupled and location-independent.
There were some interesting questions arising from this, one being when to put service orchestration in the services layer (i.e., have one service call another) and when to put it in the process layer (i.e., have a process call the services). I see two facets to this: is this a business-level service, and do you want transparency into the service orchestration from the process level? If it’s not a business-level service, then you don’t want business analysts having to learn enough about it to use it in a process. You can still do orchestration of technical services into a business service using BPM, but do that as a subprocess, then expose the subprocess to the business analyst; or push that down to the service level. If you’re orchestration business-level services into coarser business-level services, then the decision whether to do this at the service or process level is about transparency: do you want the service orchestration to be visible at the process level for monitoring and process tracing?
This was the first time that I’ve given this presentation, but it was so easy because it came directly out of my experiences. Regardless, it’s good to have that behind me so that I can focus on the afternoon sessions.