Yes, cheaper means actual gain that can be recognized as beneficial to the business. It might mean more free time to play golf for a small team of 3rd party salespeople. It might mean more cash in the coffers, it might mean more time to serve more customers etc.
I keep reflecting on my view of what "Service" means. To me, service means something that is done on my behalf, which I recognize/realize benefit from. A system is something that performs some task(s). When systems are arranged to do things that I need done together, and I realize/recognize a benefit/gain from those system(s) combined activities, then I've used a "service". The Service layer, on top of a group of system(s) provide the natural decoupling of the service interface from the system(s) implementation(s). So, I now have a realistic, tangible architecture that allows me to change providers of a particular System, without changing the Service interface. Many technologies for "inter machine communications" are based on a normalization strategy. When done at the right level, this can be a great benefit. When taken to the extreme, this can extend the cost, and make it more difficult to realize any gain. I like to maintain a layer of abstraction around this communication, and this is why I like RMI/Jini for its use of mobile code, as well as the JERI stack which allows me to plug in lots of different details to manage security and performance, dynamically. <Rant-of-the-Week> The evolving WS-* standards are reinventing a lot of things. Eventually, they'll even provide for sending mobile code by allowing you to send scripting. What this means, is that yet another programming language is actually being created. At that point, we will have solved nothing with anything new, just provide more opportunity for vendors to make money recreating technologies. It's really an endless cycle. XML is not the panecea. If we just keep pushing all of our programming activities up to that layer, then eventually, that layer will become such a low level layer of logic that you won't be able to distinguish it from existing programming languages, and then someone will invent a new "high level" layer of specification/control and we'll go around again... </Rant-of-the-Week> Gregg Wonderly Steve Jones wrote: > > > With the clarification that "cheaper" means TCO and includes ROI (i.e. > if I spend $2m and my support costs drop by $500k pa and we make an > additional $800k pa). > > Steve > > > > On 10/10/06, *Gregg Wonderly* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > Mark Baker wrote: >> How about a *testable* definition, Gregg? One that I can use to >> evaluate a system to determine whether it's architecture is SOA or >> not, as well as understand what changes I'd need to make for it to >> become SOA (including what advantages I'd gain in doing so). > > The test is this. Is it cheaper to keep doing things the way you are > doing > them, or is it cheaper to create additional services that support > automation and > decoupling of business processes from the systems. When its cheaper > to refine > your systems and better support the business through services that > wrap the > systems, then you still don't have the "right" SOA. When it's > cheaper to stay > where you are at, then you have the right SOA. > > Gregg Wonderly > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
