Consumer SOA - my card, my rules

The other night while drinking with the Cliff Richard of SOA I ordered a round with my credit card and got the old "denied" from the machine. Now the initial result is that I've saved ten quid and fifteen pence, but its still ruddy irritating when this happens. A quick call to the company the next day highlighted the problem. I'd tried to buy some software on the internet from a company called DXO (for anyone with a digital SLR this software is the mutt's nuts) and this had been flagged as "suspicious" hence the temporary block on my card. This is about the third time this year alone that this has happened on one card or another, and I know that the bank is doing its best to save me money. Basically they've set up a system like this...

Which is great when it stops the fraud... but come the bill it ended up giving a "false positive"
Leaving Mr Lowe to pick up the tab.

Now picture a world in the future where the credit card provider enables me to provide some of my own rules, like "Don't let my wife buy another dog" or provide temporary rules like "today I will be mostly buying computers over the internet" or "Yes I am actually paying a bar bill".
This would mean that the bank's rules would also check my rules to see if there is an over-ride for what they've just seen.
And I'd end up paying for the bill, lose ten pounds and not have a reason to write a blog item. Still taking this further you might like to have your own fraud detection, maybe something you "buy" from one credit card company and then apply to all of them, or just some specific convenience functions like a validation via your mobile phone provided by your provider. This way you are not only adding additional "meta-data" but also adding in process elements.

Now this isn't half as daft as it sounds when you think about both consumer and commercial demands around next generation services, or indeed about building services today. If you are building payment then you need to split out the fraud detection service as, while tightly coupled to some extent, it will have large amounts of configuration change around the rules and potentially the process and integration points. This might be as simple as multiple different rules sets for different scenarios, or might be as complex as entirely different systems depending on what you are processing.

When looking at things like Vendor managed inventory, think about the future when those vendors will want to deploy their own tracking and eventing processes into your infrastructure. There are lots of different scenarios when this sort of external modification is desired. I'm not talking here about the mythical "change the business rules at runtime" I'm talking about delegating authority for rules or process to external parties within defined and controlled boundaries.

Right now there aren't ways that technologies or even business models really allow this sort of approach, at best delegation is enable "outside the walls", but you can be guaranteed that in future they will be. So its right to start thinking about how that might impact you, don't engineer the solution just yet because its not worth the effort but at least think about how such a solution would impact what you are delivering.

There is nothing in SOA says that you own everything that you execute, and if SOA is to provide view that the business wants then they are going to want to allow this sort of delegation. This means our thinking, solutions, technology and governance is going to change in the coming years in fairly dramatic ways.

Technorati Tags: SOA, Service Architecture