JP, I applaud your efforts to reinvent the term but unfortunately I don't think I can change what I think SOA infrastructure means just because of your epiphany around service oriented people.
Don't get me wrong, I think you are onto something important, but it's not really anything new. In my book for example we discuss the fact that service contracts extend way beyond WSDL to include things people write down on paper. But the contracts are still part of SOA infrastructure. What I understand you are doing is emphasizing an aspect of SOA that tends to get overlooked by technologists, and that's great, but to me this is still a matter of emphasis rather than separation. Or a sliding scale if you will - technology still plays an important part but you are correct to remind us that it's not the be all and end all. But I think there's another very important aspect of this discussion, and something that bears emphasizing in addition to the emphasis on people. Services are not objects, and emphasizing their relationship to human activities helps reinforce this distinction as well. For years we have tended to model software artifacts as things (i.e. objects) but now we are more correctly (correct from the point of human abstraction that is, meaning easier to understand and map to business requirements) focusing on functions (i.e. services). This is confusing since you can use an object to implement a service even though a service isn't one. I see this mistake fairly often, for example in a recent book manuscript I was reviewing. Emphasizing the human aspect should also help reinforce the important distinction between objects and services. Eric --- JP Morgenthal <[EMAIL PROTECTED]> wrote: > Eric, > > And I believe that your focus is a fine one. > However, going back to > the title of the email. I don't believe, because of > the other applications > of SOA, that it is appropriate to say "SOA > Infrastructure" unless we're > using it to cover all aspects of implementing a > service including the pens, > pads, chairs, buildings, etc. > > JP > > -----Original Message----- > From: > [email protected] > [mailto:[EMAIL PROTECTED] > On Behalf Of Eric > Newcomer > Sent: Monday, March 13, 2006 9:41 AM > To: [email protected] > Subject: RE: [service-orientated-architecture] Re: > SOA Infrastructure > > Ok, cigars notwithstanding, I think I get it about > the > non-computerized contracts being an important part > of > the design, and valuable in their own right. Not to > be > overlooked etc. > > I would still say, however, that the main point of > any > SOA exercise would be to automate as many of the > contracts as possible, since computers typically > (but > not always, as you are saying) tend to help > businesses > run more efficiently. > > Thanks, > > Eric > > --- JP Morgenthal <[EMAIL PROTECTED]> wrote: > > > BINGO! Give the man a ci-gar! That's exactly > what > > I'm saying. Remember > > the 'A' in SOA. I claim that SOA is about a way > to > > design a system-any > > system-and it does not have to be realized in > > software. I believe it is a > > grave mistake for the industry to associated SOA > > with the fact that it has > > to be realized in software. And, indeed, this is > > exactly what I believe > > others believe when I see terms like "SOA > > Infrastructure" and "SOA Testing". > > > > SOA is a way to design a system that closely > models > > the business, breaking > > down the business as a set of services with a > > well-defined contract. Some > > of these systems may be automated, while others > are > > based on humans. A > > service is a black box that has a well-defined > input > > and output and > > guarantees a certain level of delivery. > > > > JP > > > > -----Original Message----- > > From: > > [email protected] > > > [mailto:[EMAIL PROTECTED] > > On Behalf Of Eric > > Newcomer > > Sent: Sunday, March 12, 2006 11:40 AM > > To: > [email protected] > > Subject: Re: [service-orientated-architecture] Re: > > SOA Infrastructure > > > > Todd, > > > > I am really baffled by this, I have to admit. Are > > you > > implying that an SOA doesn't have to be realized > in > > software? > > > > I have been thinking of SOA as related to > software, > > isn't it? > > > > I realize there are a lot of nontechnical issues, > > and > > I completely agree that an SOA needs to be defined > > independently of technology considerations, but at > > the > > end of the day isn't the point of the exercise to > > improve the usefulness and suitability of > computers > > for business applications? > > > > Are you and JP arguing that it's enough to do the > > design? This is what I don't get. > > > > Thanks, > > > > Eric > > > > > > --- Todd Biske <[EMAIL PROTECTED]> wrote: > > > > > +1. If I could give it +2, I would. Every > time > > I > > > sit down and > > > think about what it takes to make SOA > successful, > > I > > > don't think > > > technology ever comes up on my list. > > > > > > -tb > > > > > > On Mar 11, 2006, at 3:42 PM, JP Morgenthal > wrote: > > > > > > > Eric, > > > > > > > > Technology is not required to implement > > anything. > > > I can take any of > > > > the bank services I represented in my example > in > > > my post and > > > > implement them > > > > with humans. Will I still need > infrastructure, > > > yes, probably a > > > > building in > > > > which to work, a phone, a pen, pencil, maybe > > I'll > > > even throw in a > > > > pad for > > > > good faith. The one thing I don't need is > > > technology (unless you > > > > want to > > > > consider the pencil technology, in which case > I > > > won't argue). > > > > > > > > The problem with saying SOA Infrastructure is > > > that it immediately > > > > associates in non-technical people's minds > that > > > this thing is > > > > beyond them, > > > > not in their field of vision, "that thing that > > IT > > > does that we all > > > > hate > > > > because they're too slow doing it in the first > > > place." > > > > > > > > I just worked with a company where we used > SOA > > to > > > define the entire > > > > enterprise. The CFO and the sales team and the > > > marketing team and > > > > the loan > > > > team didn't see SOA as technology. They saw > it > > as > > > the way they > > > > were being > > > > organized. They saw it as the way they define > > > what they do to other > > > > departments, they say it as requirement to > > develop > > > a contract that > > > > explains > > > > to other groups how to use their services. > > > > > > > > SOA can be so much more than we're giving it > > > credit for today. It's > > > > only recently that I've seen the power of > using > > in > > > organizational > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> 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/
