SOA Institute is aligned with the BPM Institute and with the Business Architecture conference. This is more than just a convenient coincidence. It’s a recognition that an organization needs to address all of these skills and approaches to truly align business and IT in an agile and flexible manner.
And, it takes more than just addressing these issues. They must be addressed in a coordinated and integrated fashion where one aspect feeds into the next aspect of the system development process. In other words, defining business processes alone will not affect alignment. Nor is defining services enough to bring alignment. Even defining processes and services together is still not enough. Architecture must influence the definition of business processes, which must feed directly into the service identification process, that feeds into service design, which feeds development, and so on.
To start, we have to recognize that services are a combination of function and information. Of course, this is also true of business processes, and of the overall enterprise. So, to achieve alignment we need to understand the link between function and data at the enterprise level and the business level and the service level.
Enterprise Business Architecture is our first step in addressing these. It defines the high level business outcomes, processes and rules, and the high level information required to support them. Concurrently, the information architecture defines the business entities and the information that must be shared across the enterprise to achieve the enterprise business outcomes. This is the start of the chain. The next link is the business processes. Here, we use the business and information architecture to guide the business process designs.
The business processes are made up of business activities and tasks, and the exchange of data via business documents (of course it’s more than just this, but these are what’s important for this discussion). This is the next link of the chain. The tasks of the business processes will be implemented by business services, and the business documents will contain the information that is passed through the service interfaces. But remember that the services and information do not support just one process. They are shared across the enterprise by a range of processes, and therefore must also be designed within the same context of the business and information architectures. In other words, the business architecture drives the service grouping and identification based on the functions required to achieve the enterprise outcomes, and the information architecture defines the shared semantics of those outcomes, and which is implemented in the service interfaces.
To do this, we need to adopt a different way of thinking about design. For example, a typical approach to SOA or BPM design might incorporate this sequence: For each business domain, identify and analyze the scenarios. Break the scenarios down into tasks that are implemented by services. Look for existing services that perform the specified tasks. Use existing services where possible. Design and implement new services.
This probably seems like a pretty reasonable approach, but let’s look at an SOA focused sequence and compare: For each business domain, identify and analyze the scenarios. Understand what services currently exist (or are planned) and their responsibilities. Using existing services to frame the design, break the scenarios down into tasks that are implemented by services. Use existing services where possible. Design and implement new services.
The difference comes at the breakdown of scenarios into tasks and services. The difference may seem subtle, but the effect is huge. In the first approach, we are free to come up with almost any reasonable sequence of tasks to implement our scenario. There could be dozens of possibilities. Then, we look for existing services that do things our way, but probably don’t find very many. Instead, we implement new services, but ones that overlap with existing services. In the SOA approach, we factor in the existing services first, and then design around them. They provide a design constraint that limits the possible solutions to a few, instead of dozens. Now, when we go to use existing services, they’ve already been designed in, and work with our new application, and support our enterprise. Instead of promoting new services, we’ve facilitated reusing existing ones.
The crux is this. We are not designing an application or process from scratch. Instead, we are starting with an existing context, based on our business and information architectures, and building on top of it. We are extending and reusing, adding value to what exists, not duplicating responsibilities and adding inconsistencies. But to make this actually work, we need to make sure that the architecture, and design processes support each other. The artifacts that we produce with Business Architecture have to directly support the design of processes and services. The mechanisms for business processes need to produce artifacts that directly lead to the development of appropriate services. Anytime that the output of one step is not the input to the next step, we introduce an opportunity for errors and disconnect, but more importantly, an additional step in the process encourages developers to ignore the outputs of the previous step, creating extra work rather than providing value.
Tying all of this together is traceability. Because all aspects share a common root and are part of a continuous development process, we can follow one to the other. Starting from our strategic outcomes, we can trace down to the processes required to implement them, and then to the capabilities necessary for those processes, and then to the services which implement those capabilities and all along to the business entities and information involved. Or, if we’re going to make changes to a service, we can trace back up to see what processes might be affected, and what impact that may have on business outcomes.
