Found content: http://www.computerworld.com/newsletter/0,4902,110766,00.html?nlid=APP
Governance of anything is a workflow, of course. But don’t take the word “workflow” in the limited sense of “sequential process.” I use it in the broader sense of “policy-driven flow of content, context, and control throughout a distributed process.” That definition allows the flow to be sequential, parallel, conditional, etc. Allows the flow to be the collaborative give-and-take of human beings hooking up through e-mail, phone, travel, etc.
But of course I have other definitions of workflow that I whip out when the need arises. Another definition indulges my delight in alliteration, characterizing (oversimplifying?) workflow as a set of roles, routes, and rules (i.e., all of which constitute the envelope of “policies” that govern the driving of the flow, per the above definition).
Notice that I place “role” first in that list. The notion of a “role” is the foundation of any business process. In many workflow models, roles are the (actual or virtual) dots that are connected by the routes, which are in turns qualified by the rules that govern the whole process.
Govern the process. Governance. A few months back in this blog, I characterized role as “identity defined in its full governance context,” qualified by the broad attributes of “place,” “process,” and “permission.”
Re SOA governance, it’s clear that roles—human roles—play a critical (gulp!) role in design-time and run-time. In my upcoming Network World feature article on SOA governance, I make the following point: “One of the most effective approaches for SOA governance is to restrict what sorts of new services may be published to the master registry, by whom, with whose approvals, and under what conditions. Increasingly, registries are integrated with workflow features that govern how services are approved, designed, developed, published, versioned, and retired.”
Most of the registry/repository vendors provide varying degrees of support for configurable design-time administrative/approval workflows, based on clear role definitions among developers, SOA architects, etc.
The referenced found-content provides a good discussion of how SOA governance design-time (and optimize-time) roles are changing. I quote it at length: “Business architect. Process analyst. SOA enterprise architect. These are the job titles various organizations are applying to an emerging role being filled by those well versed in business and technology to oversee service-oriented architecture projects. The holder of the new job will be charged with identifying services that can be reused across an enterprise, finding services in a repository, simulating scenarios for the processes to run and determining metrics to measure the effectiveness of an organization's processes. The position will be part of either central IT or a line of business, depending on the company.”
I had a discussion on this same topic yesterday with Aiaz Kazi of SAP, here at SAPPHIRE ’06 in
What Aiaz was describing is a new SOA governance design-time role that sits halfway between the IT process architects and the business process analysts (i.e., the tech and business wonks who use their respective visual development and flowcharting tools to specify SOA-enabled business processes at various levels). This intermediate role essentially catalyzes consensus between the business process analysts and the IT process analysts concerning the eventual process, but doesn’t actually get involved in the fine-grained architecting of the processes.
Instead, this role is more of a “process steward” (my term) who makes sure, whatever new process emerges, that it reuses existing business processes to the maximum extent feasible. The process steward cracks the whip and just says no when IT process architects and business analysts attempt to create new, end-to-end, stovepipe workflows that overlap with existing processes, either in their entirety or in significant roles, routes, and/or rules.
In other words, the process steward role enforces reuse of existing business processes—SOA-style—when developing new processes. The process steward oversees the SOA governance process—the design-time workflow or collaborative process--under which business governance structures—as defined by IT process and business process architects—are crafted, revised, and optimized.
