Hello Eric and IP, I found your conversation interesting. Forgive me to jump in for three points.
First, relationsphip between Business and software design. The two systems have been historically treated as very different endeavors. The two types of engineering involve different practitioners with different background using different techniques to achieve different goals. This convention dichotomy inevitably creates incompatibilities between the business and its software, with two systems working in different ends with different means. One end is to have business conforming to technology such as ERP systems. Now we go another extreme that is to have technology conforming to business as technology is just tools or resource to support business. The saying that IT is the environment of business implies that IT and business can not be separated. Second, architectural frameworks(Zachman, FEAF etc) view organizations as overlapping architectures (business, data, technology, application, service, performance etc). Zachman is only giving guidlines to models of these architectures but not bringing forward prescribed models. I see logic problems with FEAF but it is out of topic here. Third, SOA (my personal oppinion) is not meant to create business architectures. It is not a business arcthiecture framework. It is a technology architecture pattern among many, Nothing more, nothing less. This technology architecture is more friendly to business adaptivity and change. Creating business architecture is far more complex than any framework can provide. Organization theories, complexity theory, systems theory, living systems all contribute to business architectures modeling. Viewing a business consisting of services is only viewing a ear of an elephant. Jerry --- JP Morgenthal <[EMAIL PROTECTED]> wrote: > Eric, > > Actually, it has nothing to do with an epiphany, > just a plea for > (sorry to say it) vendors to stop abusing > terminology to support their sales > efforts. My apologies for those that are offended > by that statement, but > who among on this list can deny that they do this. > > SOA Testing, SOA Infrastructure. Come on Eric, you > and I have been > at this game a long time. When was the last time > you built a test harness > for your object architecture? When was the last > time you developed > infrastructure for your message-oriented middleware > architecture? You don't > apply physical entities to an abstract quantity. > Even a C++ compiler knows > you can't create an instance of an abstract > interface! :-) > > I do believe that SOA is being undermined by its > association with > the words that are following it and I believe it is > being led by the vendor > community that is selling tools to this market. > Perhaps even led by the > analyst community consulting to the vendors helping > them to try to > differentiate themselves in a rapidly commoditized > market. > > If anything was an epiphany, it was that as an architectural > paradigm, SOA is up there with FEAF, Zachman, etc. > It can be used liberally > to describe any system regardless of what that > system is comprised of. > Moreover, it's more robust than these EA frameworks > because it carries with > it the weight of compliance and governance inherent > in its definition. > > JP > > -----Original Message----- > From: > [email protected] > [mailto:[EMAIL PROTECTED] > On Behalf Of Eric > Newcomer > Sent: Monday, March 13, 2006 5:35 PM > To: [email protected] > Subject: RE: [service-orientated-architecture] Re: > SOA Infrastructure > > 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] > > > > === 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/
