SOA and Trust, analogy to Components RRS feed

  • Question

  • First off this more of a discussion than a straight forward question but here goes...


    IMO, one of the touted advantages of SOA is to be able to (re)use services that best match your business needs, i.e. to cherry pick the services. A simple example of this would be to use Virtual Earth to provide all your mapping needs. My question/thought is can/do senior IT staff/architects really trust the providers of these services? As an example I'll take a step down the development tree and consider 3rd party controls. We've had VBX controls through to 3rd party web controls and now I always stay well away from them because I've been burnt on too many occasions. Either the controls don't provide the features (or quality) as advertised or the company simply disappears. Basically I don't trust them, especially if they don't supply the source code. So back to the question in hand. If I don't trust the vendor of my tree view control do I really trust the vendor of my steel manufacturing validation service?


    Obviously it comes down to domain knowledge (what do I know about steel validation processes) and the cost to implement the service yourself. I guess it isn't different to any service you use whether you're buying steel from a manufacturer or having a service agreement with a bank to credit check 10 requests a second but I have a sneeky suspision that there are a number of people out there looking at some 3rd party service but thinking, "it's just too risky, how can my client trust this service?". Is this another reason for the slow up-take?



    Friday, June 22, 2007 9:56 AM



    Congratulations - your post has been selected for an ARCast.TV Rapid Response!

    To listen to Architect MVP Juval Lowy and Ron Jacobs address your question click here

    Hope this helps,

    Ron Jacobs

    Friday, June 29, 2007 10:14 PM

All replies

  • You are talking about SaaS(Software as a Service), not about SOA.

    I am not IT stuff, however I can say my opinion.

    Do you trust regular not IT third party services for your office? For example cleaning service, security service, dinner service, post service and so on? If "yes" this is okay to trust SaaS too.

    Friday, June 22, 2007 5:08 PM
  • Dear,

    In computer world you must have know a famous phrase "Don't Reinvent the wheel". If you say i dont trust on my tree view control, the answer is simple; go ahead and implement your own tree view. But wait a min, You shouldn't trust C-Sharp/java compiler then, go ahead and build your own language /compiler.

    At certain stage you have to trust somehow 3rd party controls. So if you are using Amazon or google web services. You don't need to worry about anything.

    Hope this makes sense?

    Friday, June 22, 2007 7:51 PM
  • Thanks for your replies (so far) and this is a discussion so there is no wrong answer...
    re: SaaS I don't believe I am, in so much as SaaS is a subset of what I'm talking about. My question relates to integrating a 3rd party service into your own, "eco system". My question applies equally to bespoke service written by a 3rd party (i.e. customer or supplier) as it does a SaaS but I do concede I didn't make that clear.

    re: Re-invent the wheel. Well yes that's a given but that argument is as old as the hills themselves (well after the wheel was invented) and is one of those glorious utopian software myths. Of course you should strive for re-use but my question is related to critical business services where I've yet to be convinced that the lack of trust doesn't hinder their uptake.

    re: Trust of any supplier. I agree and made that point too. However I do believe there is a fundamental difference to vetting your cleaning staff than putting parts of your mission critical system in the hands of people you have no say over.

    To reiterate my question, is there or isn't there trust in integrating a 3rd party service into your system?

    Saturday, June 23, 2007 9:53 AM
  • Surely this is what SLA's are for? If a company providing a service to you fails to give you an adequate SLA then walk away...


    IMO it is not the same as buy a set of 'controls' for use in developing an application...




    Saturday, June 23, 2007 2:22 PM
  • Indeed like I said I think service agreements do help, but the problem with them is they act more like insurance policies i.e. it works after something has gone wrong, can you afford a critical part of your business to go wrong?

    I used the analogy of controls to show that for something non-critical such as a control I think twice. So for something critical I get very nervous!

    The interesting point about SLAs is that it does force you (the consumer) of a service to create adequate tests to ensure the component/service works, of course everyone does that for every bit of software written or used...right? The problem, as with components, is you put your trust not only in what the service delivers now but your faith in the service continuing to deliver it.

    Ok, so I've pushed my worries out there and had a few responses but what can we do to help? So far the mechanisms to help instil some faith seem to be (plus a few "new" ones);
    1. SLAs - Provide a specific contract both parties can agree on. If it goes wrong then it is a way to break a contract and potentially get compensation. Provides a level of trust, but I'm not sure how significant that level is
    2. Test strategy -  Make sure the service does what the SLA said it does before using it in earnest. Obvious one but the more testing done the higher the trust? Would you have more or less faith if the testing was done by another 3rd party?
    3. Agree to provide source code of service - chance for the consumer to audit the code but also take the code should the service provider cease to trade. I wonder how many providers would agree to this esp. concerning intellectual rights. Also in a true SOA environment the code may mean nothing to the consumer, assuming they have any in-house development. E.g Java coded service consumed by a .net only house.
    4. Multiple Service providers - a fault tolerant approach, use the same service provided by many providers. Fine for SaaS where a common service maybe implemented by many providers but unlikely to happen when talking to a specialized customer or supplier service.
    WDYT? Other mechanisms please!

    Saturday, June 23, 2007 5:14 PM

    Congratulations - your post has been selected for an ARCast.TV Rapid Response!

    To listen to Architect MVP Juval Lowy and Ron Jacobs address your question click here

    Hope this helps,

    Ron Jacobs

    Friday, June 29, 2007 10:14 PM
  • Some comments:

    Regarding source code.

    From my experience I can say that source code is good to understand how things work, but not to approve is this code right. To approve  that application okay, you need to perform dozens of different tests. And only this will be able to prove something. However in most cases this test are too complicated (sometimes not tests, this can be environment, fuzz data) , and application provider will not be able to share them.

    Regarding multiple service providers.

    This is good point, however often I see situations when services different not only by contract. They differ logically. In this case switching to another provider can make too many headaches. Solution for this is standards, they sometimes can minimize costs of such switching).


     pkr2000 wrote:
    WDYT? Other mechanisms please!

    1. External audit/certificate group for the services. For example Microsoft (not itself, something like they do for certification) can be such auditor;
    2. Standards support, I am not about protocol standards, they may support high level standards ;
    3. Of course, name and trust;
    Saturday, June 30, 2007 1:35 PM
  • Thanks Mike, Ron and Juval.


    It really does sound like there is a genuine issue here and one that ultimitely seems to come down to placing trust in that supplier. As with many areas, as Mike points out, it is as much about reputation as it is legal documents and SLAs. However, I still wonder if this does (or has) hindered the uptake of SOA?



    Saturday, June 30, 2007 11:41 PM