Thursday, February 09, 2006

Ubiquitous Purchase Order

If you ever get into a conversation which discusses use cases of SOA, then you have probably heard of the Purchase Order (PO). The use case goes something like this, there is a PO which needs to be routed across multiple enterprise components (recently exposed as web services) and this PO needs to find its way to its destination through a maze of business processes. It seems every one has a policy which says "if the PO is greater than some dollars then send it to big boss otherwise the little guy can do it as well".

So abstracting the use case out a bit, we are saying the PO is the input into a black box and some processing occurs and the PO changes the state of the black box and returns a zero or more messages saying so to the originator.

I have yet to hear someone question this use case in context of the vision of SOA enabled datacenter. I always wonder why the PO even has to even exist. After all in the world of SOA, multiple systems are now connected at the application level and supposedly understand the business processes extant in the organization.

POs were created because the buyer and seller had no other way to account for a transaction. PO was the document that implemented the approval process, the actual transaction and the budgeting process. If the underlying IT infrastructure is moving towards loose coupling, the overlaying business processes would need to be reengineered to take advantage of this new infrastructure.

I think the biggest opportunity in SOA might end up in the laps of management consultants. Perhaps, I should have stayed at Booz.Allen ;)

SOA Patterns and AON Appliances

There is a lot of discussion around SOA patterns now-a-days. If you have used patterns in your past life, these SOA patterns are not really the same thing. It is not a reusable chunk of code that you can cut & paste. These are big chunks of functionality that needs to be deployed at various points in your network. From an AON perspective, almost every pattern in SOA can become an independent appliance on the network.

When the first appliances hit the market in 1997 timeframe, the pattern they followed was Linux + some server. An AON appliance is a dual plane appliance which has XML for data plane and a control plane which depending upon the pattern that the AON appliance is implementing can be Java or a scripting language or anything else. The performance of course comes from the data plane.

So if we survey the SOA landscape today, we can easily find references to Gateway Pattern, Governance Pattern, Broker Pattern, Router Pattern etc. Each one of these can be made into an appliance in a service oriented network. The only difference between the appliances would be the control plane. You could deploy all these patterns into a collective which some folks call the ESB or you could drop-in appliances at various points in the network to achieve the same result.

Once you have the patterns deployed the challenge shifts to managing the multiple deployed patterns, plan for capacity, scale it and secure it etc. This is where a network based approach with appliances shows its clear advantage. Capacity planning, securing, scaling, sharing etc. are networking's forte.