Service-Oriented Business Architecture

I’ve been doing quite a bit of enterprise architecture work lately for a couple of clients, which has me thinking about how to “package” business processes as “services” for reusability: a service-oriented business architecture (SOBA), if you will. (I have no idea if anyone else has used that term before, but it fits in describing the componentization and reuse of various functions and processes within an organization, regardless of whether or not the processes are assisted by information systems.)

When we think about SOA, we think about automated processes and services: web services that can be called, or orchestrated, to execute a specific function such as mapping a set of input data to output data. SOBA, however, is for all those unautomated or semi-automated processes (what someone in a client IT department once referred to as “human-interrupted” processes) that may be reused, such as a credit adjudication process that requires human intervention. In many large organizations, the same (or very similar) processes are done by different groups of people in different departments, and if they’re not modeling some of this via enterprise architecture, then they likely have no idea that the redundancy even exists. There are exceptions to this, usually in very paper-intensive processes; most organizations, for example, have some sort of centralized mail room and some sort of centralized filing, although there will be pockets of redundancy even in such a structure.

From a Zachman framework standpoint, most web services are modeled at row 4 (technology model) of column 2 (function), whereas business “services” are modeled at row 2 (business model) of column 2. If you’ve spent some time with Zachman, you know that the lower (higher-numbered) rows are not just more descriptive versions of the upper rows; the rows described fundamentally different perspectives on the enterprise, and often contain models that are unique to that particular row.

In talking about enterprise architecture, I often refer to business function reusability as a key benefit, but most people think purely about IT functions when they think about reusability, and overlook the benefits that could arise from reusing business processes. What’s required to get people thinking about reusing business processes, then? One thing for certain is a common process modeling language, as I discussed here, but there’s more to it than that. There needs to be some recognition of business functions and processes as enterprise assets, not just departmental assets. For quite a while now, information systems and even data have been recognized as belonging to the enterprise rather than a specific department, even if they primarily serve one department, but the same is not true of the human-facing processes around them: most departments think of their business processes as belonging to them, and have no concept of either sharing them with other departments or looking for ways to reduce the redundancy of similar business functions around the enterprise.

These ideas kicked into gear back in the summer when I read Tom Davenport’s HBR article on the commoditization of processes, and gained strength in the past few weeks as I contemplate enterprise architecture. His article focused mainly on how processes could be outsourced once they’re standardized, but I have a slightly different take on it: if processes within an organization are modeled and standardized, there’s a huge opportunity to identify the redundant business processes across an organization within the context of an enterprise architecture, consolidate the functionality into a single business “service”, then enable that service for identification and reuse where appropriate. Sure, some of these business functions may end up being outsourced, but many more may end up being turned into highly-efficient business services within the organization.

There’s common ground with some older (and slightly tarnished) techniques such as reengineering, but I believe that creating business services through enterprise architecture is ultimately a much more powerful concept.