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.

6 thoughts on “Service-Oriented Business Architecture

  1. I almost agree with James.

    I think what you just described is simply Business Architecture practice.

    Or may be the question is, SOBA as oppose to what?

    Modeling the enterpise from the perspective of Planner/Owner (row 1, 2 Zachman Framework) existed long before SOA and it is obvious once you build the model you always can refactor that to get to primitives, therefore I am not sure how SOA plays role in this game…

    …Well…may be I’m getting tried of so many buzz words….

  2. James is spot on. SOA should align with EA to be successful, but there is no such thing as a service oriented business architecture. EA can help you with answering the question *what* to do, SOA with the question *how* to do that.

    And as for SOBA: the only true meaning of SOBA is Service-Oriented Business Applications, as Gartner coined this acronym.

  3. Thanks to all for your comments.

    I agree, SOBA does not exist (and I was being a bit tongue-in-cheek about the name, thinking of Japanese noodles), but my point was that maybe it should exist. I was thinking about how to standardize “interfaces” to non-automated processes in the same way that web services standardizes the interfaces to automated services. If we can’t standardize non-automated business processes in some way, then we have no hope for reusability of these processes.

  4. If you define service opriented business archtiecture as the interface to the services provided by a business unit it makes sense to me. For example a “processing claims” is a service provided by the insurance management arm of a financial service business. This service can then be funded through internal fee for service. for example when budgeting the FS company executive expect to process x ammount of claims. The service cost for processing a claim includes resourcing the service and execution costs end to end. So it is a simple matter of expecting x cost and y number of service invocations for budgetary purposes. Another example of a service could be the ICT department service “Maintain the printers” This would be a fee for service based on acontract similar to that which you would sign wiht the cleaners. Over the enxt 12 months the service levels must be … in return ICT is paid x to cover the cost of providing that service.

Leave a Reply

Your email address will not be published. Required fields are marked *