[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram
> -----Original Message----- > From: Rex Brooks [mailto:rexb@starbourne.com] > Sent: Thursday, May 19, 2005 8:11 AM > To: Chiusano Joseph; SOA-RM > Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram > > Didn't mean that there was no value in what we call SOA, just > that it causes me some semantic difficulties and leads to > confusion over what constitutes an Architecture with a > capital A. Like Art with a capital A. > > Perhaps we need to develop another term term such as > sub-architecture, for any set of architectural components > short of the superset EA? Great question Rex. It just so happens that one of the X books I am reading right now is on EA, specifically an overview of various EA frameworks (Zachman, DODAF, etc.). The author asserts that there are 3 types of architectures, presented in hierarchical order from the enterprise level down (copied verbatim below): (1) Enterprise Architecture (EA): Relates organizational mission, goals, and objectives to business tasks, activities, and relations, and to the technology or IT infrastructure required to execute them. (2) System or Solution Architecture: Relates requirements and the external world to system/solution structures, including both hardware and software, so that the effectiveness of a system design concept can be communicated. (3) Software Architecture: Relates requirements, fixed system hardware, and infrastructure (i.e. COTS or GOTS) to software structures in order to demonstrate software effectiveness. In addition to your suggestion of sub-architecture, we could also consider a term such as a "local" architecture (i.e. local being "less than enterprise"). Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > Unfortunately, like philosophy, any > enterprise has an EA whether it is conscious and deliberate > or result of ad hoc increments. Same with Knowledge Base. It > starts becoming a problem for first order logic in terms of > what we mean when we that term. > > Ciao, > Rex > > At 11:19 PM -0400 5/18/05, Chiusano Joseph wrote: > > > -----Original Message----- > >> From: Rex Brooks [mailto:rexb@starbourne.com] > >> Sent: Wednesday, May 18, 2005 3:24 PM > >> To: Christopher Bashioum; 'SOA-RM' > >> Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram > >> > >> In today's meeting, I agreed with several other voices that I am > >> not sure there is an architecture per se in SOA, but rather that > >> most of what are called SOAs are, in fact, > service-components of an > >> Enterprise Architecture, which is, IMO, where the actual > >> Architecture is realized. > > > >Respectfully disagree - SOA does not have to be at the > enterprise level > >to add value, or to even be considered SOA. I also try to > remember that > >architecture does not always mean EA. > > > >Joe > > > >Joseph Chiusano > >Booz Allen Hamilton > >Visit us online@ http://www.boozallen.com > > > >> However, it is too late to bother arguing that, so we > will have to > >> be careful in describing what we mean by an SOA per se. > So I have to > >> agree with 1) and I think a service and some other infrastructure > >> entity, be it a remote system or another node in the same > system are > >> required to constitute an architecture. I'm not sure > about whether > >> we should stipulate satisfaction of needs. It makes good common > >> sense, though. > >> But, I think that in essence there has to be a service and a > >> service consumer for an SOA to exist. > >> > >> Regards, > >> Rex > >> > >> At 2:44 PM -0400 5/18/05, Christopher Bashioum wrote: > >> >Two points: > >> > > >> >1) in our document, we make the assertion that a service is the > >> >fundamental building block of an SOA. If that is correct (and I > >> >believe it is), then you cannot have an SOA with only 1 building > >> block. > >> >The concept of a service being the fundamental building > block of > >> an SOA >implies rather strongly that the relationship > among multiple > >> services >(and the possible specialization of > >> >services) is part and parcel of an SOA. In other words, > there is > >> >something important to how these building blocks get put > together > >> that >is inherent in SOA. Not sure what that is just yet, and > >> maybe we can >show that in a single stack. > >> > > >> >2) I am not sure about the sufficiency of Ken's > statement. I think > >> >there is something about the orientation applied when building a > >> >service description that gets to the re-purposing. I.e., > building a > >> >service with the stated requirement of re-purposing of > that service. > >> > > >> >Having said #2, I am not sure if that is really an essential > >> property >of SOA, or if it is a quality of a "good" SOA. > >> > > >> > > >> > > >> >-----Original Message----- > >> >From: Duane Nickull [mailto:dnickull@adobe.com] > >> >Sent: Wednesday, May 18, 2005 2:06 PM > >> >Cc: SOA-RM > >> >Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram > > > > >Ken > >> Laskey wrote: > >> > > >> >> The essence of a SOA is multiple services coming together to > >> satisfy >> a set of needs. > >> > > >> >This is the core point we have not reached consensus on yet. > >> This is a > >> >well worded as can be so I would like to use this > assertion as a > >> basis >for the discussion. > >> > > >> >Thoughts: > >> > > >> >I would agree that "The essence of a SOA infrastructure > is multiple > >> >services coming together to satisfy a set of needs. I do have > >> >reservations about the concept of multiplicity of services being > >> used >as a key metric to define SOA. > > > > > >> >Questions: > >> >1. Is it necessary that there be more than one service > in order that > >> >SOA be SOA? > >> >2. If yes to #1, is it necessary to call services only > in sequence? > >> > > >> >My gut feeling is that having multiple services is probably > >> a given for > >> >any specific implementation of SOA, however it is not a > requirements > >> >for something to be service oriented. If I architect one > >> application > >> >and build it with a single service, service description, > >> policy set, (+ > >> >whateverElseGetsInTheReferenceModel), is that service oriented > >> >architecture? I think yes. > >> > > >> >I would fully support a reference architecture depicting multiple > >> >services being used either sequentially or in parallel, > >> however think > >> >that is a sub project best left for a dedicated sub committee. > >> > > >> >Duane > >> > > >> >> > >> > >> > >> -- > >> Rex Brooks > >> President, CEO > >> Starbourne Communications Design > >> GeoAddress: 1361-A Addison > >> Berkeley, CA 94702 > >> Tel: 510-849-2309 > >> > > > -- > Rex Brooks > President, CEO > Starbourne Communications Design > GeoAddress: 1361-A Addison > Berkeley, CA 94702 > Tel: 510-849-2309 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]