In this blog, I will be writing about aspects of Enterprise Architecture that straddle the boundary between the business and the technology realms.
The views that I express on here are mine. They aren't filtered, controlled, managed, refined, doctored, censored, or intended to represent any views that my employer has.

Tuesday, July 15, 2008

I have been having conversations over the last few weeks about whether a service (in the SOA sense) is an interface or an implementation. This is a surprisingly tricky path to navigate.

At one client the following question (or a variant) comes up quite frequently, "We want to service enable our C++ back end code, but the services framework is all Java how can we get them to co-exist?"

So we have an implementation, we can't use it directly but we do want to leverage it. Clearly the implementation itself isn't the service. If it were there would be no discussion. Also the interfaces it already provides may not be the same as the operations we would want to offer.

So we take the time-honored approach and wrap the code. The wrapper then exposes the service's operations and deals with the complexity of mapping the operations to whatever the original code supported. Now what is the Service in this scenario? Perhaps it is the wrapper code - after all it is the wrapper that has the signature, the wrapper that is directly invoked, the wrapper that will have the nice QOS measures, the wrapper I will look up in my registry.... However the wrapper doesn't "do" anything. Of course if the wrapper is really generic and abstract then it doesn't help to describe the service as being the wrapper. No one will have a clue when they go to the registry (white pages) what the service does. A description like "Wraps existing C++ code so it can be made available in the services framework" is hardly a confidence booster.

So what to do? My general favorite is to use a special purpose framework (auto generated if possible) to wrap the C++ (or other legacy) code. Make sure that the service is the wrapper and not the C++ implementation and manage that in the registry.

After all, one of the SOA principles is autonomy. The actual implementation doesn't have to be constrained as long as the interface supports the appropriate operations.

At some primitive level there are three sets of things that flow in an organization. These are Goods, Information and Money. Not a shattering insight, but the interactions between these three categories give us some really good insights into how a business works. This isn't a typical customer focussed, outside in kind of view, but deals with what actually happens inside the business.

Why is this view of the business important?It is holistic, actions that occur in one of these flows has impact on the others. Shipping the software to a customer (Physical Goods) can tell the money flow that revenue recognition can occur and can deliver information that the shipment has taken place.

Looking at the interactions of these flows gives us clues into:

Adherence to accounting practice (when do we recognize revenue, for example?)

Inefficiences in process (oh, we recalculate the revenue in many different places, even though nothing has changed)

Opportunities to improve quality of service (let's move the credit check - an information flow request) to earlier in the cycle so we don't incur costs before we know if the customer can/will pay)

Business modeling - "what if" (What happens if we attempt to move the credit check earlier?)

Real time information delivery from both Goods and Money (How many units did we ship today?)

Realization that the information need to control a Goods flow isn't available identifies a process breakdown

Ultimately, of course, what we deal with in information systems are informational abstractions of the Goods and Money. For us in IT it is all information. However to the business it isn't so, although we use the lens of the information system to help us look at the underlying realities. Our information system lenses are so distorted, however, that we often don't or can't know what is properly in or out of focus.

There are some real nuances to worry about here too. For example, in a content delivery system (e.g. a newspaper), the information (content) is treated as the Goods. Likewise in banking much of the money that flows through the bank is actually treated as Goods - but with a significant impact on Money and Information as well.

It is not trivial to create a GIM model, but the effect is enormous:

Silo thinking is reduced - all streams can see the effects on each other of actions taken. Moving Credit Check later in the Information Stream affects the Goods stream because it will curtail process actions.

Sub-optimal decision making is highlighted - "If I take this action, what breaks?

It provides a common "grammar" for talking about the business between the business and IT - a goal that has not been reached in many years of trying.

An end to end trace of a business process - with all the stakeholders shown can be built and optimized.

Why doesn't a process model work?

This is a form of process model - one where we specifically illustrate what happens to all of the major "data" sets (Goods, Information, Money). So instead of being a step by step way through the process, it is a way to handle the information exchanges more effectively. So it is an enriched process model.

What other models help?

We can leverage many of the standard models (e.g. in UML), but nothing gives us a complete enough view.

How do we do it?

It revolves around a fundamental understanding of business modeling - starting with the operational flow of goods. It is after all the operational flow of goods from start to finish that defines what the business delivers. So drive from flow of goods - starting anywhere. That depends on the scope and depends on the business. The key is that it is an operational goods flow that matters. That operational goods flow means starting with operational process.

In the operational goods flow, swim lanes and swimming pools are appropriate, but often it is a good idea to use business iconography and not boxes/lines to show things. That way it illustrates that we are firmly in the business domain, not IT.For each step in the handling of the flow ask:

Has this step had any effect on the Money side - e.g. recognized revenue, incurred measureable cost, disposed of an asset...

What information might be available as a result of this action being taken. Is the information interesting "real time", is the information needed for subsequent analysis, is the information in any sense privileged?

Yes, the questions really are that simple. The answers aren't and the implications aren't, but the questions are. What you do with the wealth of information is another matter.

We will notice over time that the timing needs of the Money flow and the Information flow don't exactly match the Goods flow. This is to be expected. We will also notice that the goods flow will continue regardless of whether the Money and Information flows are keeping up. In many cases we will see that the other flows play "catchup" and deal with the implications of Goods flow later. This is a primary cause for inconsistencies between different parts of the business and difficulties in rationalization.

It is of course impossible to fully serialize the business so that the flow of Goods is interrupted until all the Money and Information flows have properly completed. Thta's one reason why we look at the physical Goods flow - that simply doesn't wait.

In subsequent articles, I will talk about some of the interesting patterns and interactions that we see when doing this kind of modeling.