Following on from my previous post "How to buy as a corporate" I was delighted to see the following at JustSell which also suggests the path of an explicit sales process.
Step 6 - close - agree to purchase.
That means "ask for the order".
Occasional thoughts on business process management, eprocurement, customer service, the dark art of sales and the creatures that inhabit these worlds.
Thursday, September 13, 2007
Thursday, September 06, 2007
The "Lego dream" of SOA
Sticking with Cynthia Rettig she has some great comment on the realities of the current tech buzz around SOA - "The Lego dream has been a persistent favorite among a generation or more of programmers who grew up with those construction toys. Unfortunately, however, software does not work as Legos do".
Boiling SOA (service orientated architecture) down to some very simple points, I see it as 1) the removal of business logic from the application interface layer and 2) the exposing of said business logic in a way that it can be consumed on demand from any application (ie an API or web service). As Cynthia says - this is a massive job for legacy applications and riddled with complexities and pitfalls - not least of which is what happens when these things get nested on top of each other and you hit a problem buried deep down in the underbelly of the beast?
I get the business benefit of this for software application behemoths - who appear to me to be the ones most pushing this barrow - "hey, don't throw out our old stuff - just drive it in a different way". What I struggle with is the genuine business benefit for the business user. The argument consistently put is that you can flexibly consume an end to end business process with a modular approach to the application layer.
It's seems like a great idea but when I put it in terms of some crude analogies does it really stack up?
The boomer couple retiring from their inner city lives are moving out to the hobby farm in the mountains - rather than sell the 2 door soft-top sports car they have taken the SOA approach and dropped in a sturdy 4x4 chassis and transmission. While they were at it the SOA'd the cat by peeling off the skin and fur and replacing it with a border collie shaggy dog model.
Hmmm - didn't quite get the expected outcome there. I think this SOA thing has a long time to run before the true business benefits are fully realised.
Boiling SOA (service orientated architecture) down to some very simple points, I see it as 1) the removal of business logic from the application interface layer and 2) the exposing of said business logic in a way that it can be consumed on demand from any application (ie an API or web service). As Cynthia says - this is a massive job for legacy applications and riddled with complexities and pitfalls - not least of which is what happens when these things get nested on top of each other and you hit a problem buried deep down in the underbelly of the beast?
I get the business benefit of this for software application behemoths - who appear to me to be the ones most pushing this barrow - "hey, don't throw out our old stuff - just drive it in a different way". What I struggle with is the genuine business benefit for the business user. The argument consistently put is that you can flexibly consume an end to end business process with a modular approach to the application layer.
It's seems like a great idea but when I put it in terms of some crude analogies does it really stack up?
The boomer couple retiring from their inner city lives are moving out to the hobby farm in the mountains - rather than sell the 2 door soft-top sports car they have taken the SOA approach and dropped in a sturdy 4x4 chassis and transmission. While they were at it the SOA'd the cat by peeling off the skin and fur and replacing it with a border collie shaggy dog model.
Hmmm - didn't quite get the expected outcome there. I think this SOA thing has a long time to run before the true business benefits are fully realised.
Subscribe to:
Posts (Atom)