[service-orientated-architecture] Re: Roy Fielding on REST

[Rob Eamon]

+1.

Bingo. SOA as a style of design (architecture being design + 
aesthetics/principles in my view) for software systems. The 
enterprise/application/integration/etc. architecture that includes 
service-oriented principles must be business driven.

If the business analysis and design is service-oriented as well, all 
the better. Some call this SOA. This causes confusion because it 
appears that the SOA was already taken to refer to software systems.

But whatever the business design activity is called, it is clear that 
it must drive the architecture of the software systems. I think we 
all agree with that!

Now if we can work on getting away from using "SOA" as *the* term for 
contemporary architecture efforts, since a useful architecture is 
more than just service-oriented, that'd be just ducky! :)

-Rob

--- In service-orientated-architecture@yahoogroups.com, Eric Newcomer 
<[EMAIL PROTECTED]> wrote:
>
> Yeah, I guess I have managed to confuse myself too.  ;-)
> 
> What I mean by "business level" is really a technology level, but 
independent of implementation.  As I mentioned, the definition of SOA 
that I use is a "style of design" for IT applications.  To me that is 
not about technology per se, since the design can be done 
independently of the technology choice (which can be made after the 
design is done - ok so there's some iteration left to see that the 
technology meets the design requirements etc.).
> 
> And this design needs to meet business requirements, and that's 
where I think I may be confusing some folks.  I view the objective of 
a service design to model or mimic (as best as possible) a service 
provided by the business to a customer or to another business.  For 
example a retail bank's services to its customers are things like 
open an account, withdraw funds, make a loan payment etc.  Therefore 
the services in the SOA design should be thing like open an account, 
withdraw funds, make a loan payment etc.
> 
> This is signficant to me because with object oriented design you 
would get the recommendation to model the objects first (i.e. 
customer, accounts, loans, etc.) and *then* think about the 
operations on the objects as performing the functions the business 
needs.  This results in overly complex design, and in many cases 
unnecessary artifacts since businesses tend to think of what they do 
more in terms of functions than things.  (This topic has enjoyed some 
debate on this and other forums.)
> 
> SO - while I do see a connection to business, I am not sure I can 
say that I'd be in the camp of promoting SOA as a CEO level task - 
although the CEO should definitely be aware of a cultural shift in 
IT, he is not going to be involved in service design, except perhaps 
to the extent that software services need to closely follow business 
services (which he or she might well design or at any rate approve).
> 
> Not sure this helps but this is apparently why I end up getting 
into the business vs technology discussions, because I separate the 
design phase from the implementation phase, and believe the design 
phase can (and should) be done independently of the technology phase. 
> 
> Eric