TUCON: Architect’s Guide to SOA and BPM

I enjoyed Paul Brown’s seminar in Toronto a few weeks back, so I attended his session today on planning and architecture for SOA and BPM: how to define the services that we need and rationalize our data architecture in the face of managing end-to-end processes that span functional silos? Although many organizations have systems within those functional silos, the lines of communication — both person-to-person and system-to-system — always cross those silos in any real business process.

A lot of new skills are required in order to adopt SOA and BPM across the enterprise, from high-level executive support to a worker-level understanding of how this changes their day-to-day work. To make all of this work, there needs to be a total architecture perspective, including business processes, people, information and systems all coalescing around a common purpose. Business needs to re-engage with IT — in many organizations, they’ve been scared away for a long time — in order to get that business-IT collaboration happening.

Brown covered some of the same ground about separating out services, processes and presentation on as he did in the seminar, which I won’t repeat here but recommend that you check out the link above for more details.

He went on to discuss the TIBCO BPM.SOA execution model. First, develop the execution strategy for the entire program:

  • Develop vision and program roadmap
  • Define and implement organization and governance
  • Define and implement technical infrastructure and standards

Then, move on to solutions and operations for each project:

  • Analyze process and develop project roadmap
  • Design, build and deploy business process
  • Operate the business

This last point highlights the importance of setting and measuring goals for the project; you don’t know whether your project was successful until it’s been in operation a while and some measurements have been taken.

He had some pointers for how to get started with BPM and SOA:

  • Focus on business processes first: they’re the source of business value, and the glue that binds the people and systems together.
  • Separate service access mediation (access control, security, routing, distribution) from services.
  • Acknowledge different types of processes, both unmanaged and managed/orchestrated.
  • Separate processes and presentation.
  • Embrace total architecture with a cross-functional architecture team

He finished up with some case studies of organizations that have taken an architectural approach to rolling out SOA and BPM, and how this has made IT departments much more responsive to new business requirements. Findings by one organization included that they wanted to have more IT involvement in business processes in order to better align the business processes with the underlying services. For services that will be used across multiple systems, it’s critical to have an enterprise architecture group review these for reusability.

His final summary: keep the business process focus as the source of business process; BPM and SOA provide opportunities for improving business process; and the major challenges are organizational, not technical.

Leave a Reply