Chris,

I disagree with your assertion that SOA should not be used for
"throw-away" projects. SOA principles should be applied to all
projects to ensure appropriate separation of concerns and
manageability of the resulting system. But I assume we have different
definitions for the term "SOA". The biggest clue is your reference to
"an SOA". I'm always stymied by the idea that SOA is a thing. (as I
said before, by my definition, SOA is a set of design principles). By
"an SOA" I assume you are referring to a general-purpose services
infrastructure that ensures that services Communicate in a managed
way. (I refer to such a thing as a Managed Communications
Infrastructure - MCI).

From my perspective, every organization should have the functional
capabilities of an MCI in place, and it should support the needs of
all communicating systems, not just web services. The MCI model
applies SOA principles to infrastructure capabilities, affording you
much better separation of business and infrastructure capabilities
(i.e., supporting functional and non-functional requirements
respectively). The MCI model also supports declarative policy-driven
management of these infrastructure capabilities. It allows subject
matter experts to configure support for security, performance,
scalability, etc. These issues no longer need to burden business
developers. The model also allows the organization to more easily
enforce governance and compliance policies.

So assuming the infrastructure is in place, and assuming the
organization has a governance policy that asserts that all
communicating applications should be managed, then even "throw-away"
apps should conform tithe governance policy.

Besides, how often are "throw-away" applications actually thrown away.

Anne


On Thursday, July 2, 2009, Chris Deweese <chris.deweese@...> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi GV,
>
> Sorry I over-simplified your question, my apologies. I think there
> would be plenty of non-functional reasons, such as available hardware,
> scope of project, etc. For maximum benefit I would think you would
> want the SOA approach to be used to really bring value and not as a
> short term fix or an interim step. The real world often dictates
> otherwise.
>
> I tihnk we'd all agree that a lot of times it makes good sense to use
> a service in this day and age but obviously that does not equate to an
> SOA. I see an SOA that is a deeper strategy and not just applied to
> one system. You can gain good experience with services by applying
> them one at a time but more business involvement is needed to refine
> that into an SOA approach.
>
> Chris
>
> On Thu, Jul 2, 2009 at 10:16 AM,
gvarada<gvarada@... <gvarada%40yahoo.com>> wrote:
>>
>>
>> Chris,
>>
>> I get that, I was mostly interested in the non functional's that would make
>> SOA not a good fit.
>>
>> GV
>>
>> --- In service-orientated-architecture@yahoogroups.com, Chris Deweese
>> <chris.deweese@...> wrote:
>>>
>>> I would offer up that SOA is not a good fit if you're just going to
>>> throw services up for the sake of using services. I think you really
>>> have to match the use of services with the needs of the business.
>>> I've gotten myself in trouble when those things were not aligned and I
>>> just wanted to use a service (which is not SOA really...)
>>>
>>> Chris
>>>
>>> On Tue, Jun 30, 2009 at 3:56 PM, gvarada<gvarada@...> wrote:
>>> >
>>> >
>>> > Are there any guidelines or principles around when SOA may not be a good
>>> > fit?
>>> >
>>> > Thanks
>>> > GV
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Chris Deweese, Microsoft MVP, Solutions Architect
>>>
>>
>>
>
> --
> Chris Deweese, Microsoft MVP, Solutions Architect
> http://christopherDeweese.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>