BTW I forget the correct spelling is "Pompidou". Apologies. On 16 Mar 2006, at 09:29, Steve Ross-Talbot wrote:
> I think it is wholly unhelpful to mix these terms. Let me explain > further. There is a famous building in Paris (the Pompideux centre). > It > is a building that has an architecture which is something that > architects produced. It's infrastructure is visible on the outside of > the building - unusual because most are embedded or on the inside. The > architecture was the blue print by which the structural engineers and > builders delivered what was required. The architecture simply stated > that the infrastructure was to be put on the outside and gave a clear > description of what that meant. > > Clearly we do not talk about the architecture infrastructure of the > Pompidu Centre being on the outside. We do talk about the > infrastructure being on the outside. The danger is that we further > promote poor understanding as to what is meant by architecture and we > confuse it with infrastructure. Only this week I heard a CEO confuse > the two thinking that the infrastructure was the architecture. > > Whilst I am on the topic I would like to make sure we are all of one > mind. Architecture is not something that we do. It is not a verb. It > is > an artifact that is produced in the course of building a system. > According to TOGAF it is "A formal description of a system". According > to UML it "the organizational structure of a system". Architecting is > something that Architects do and the output of what they do is an > Architecture. I suggested at Web Services on Wall Street and I have > still to hear anyone counter this - I'd love to have a debate and > learn > new tricks from those more learned than I - that there is not A in > SOA. > There is no clear, precise way within the accepted tools sets that can > be said to define the SOA space, that are being used or can be used to > "formally describe a system" or to describe "the organizational > structure of a system". > > It would be very nice if in this group of interested parties we could > actually establish what we mean by architecture and then be clear > about > how this might differ from the prevailing wisdom of TOGAF, UML, OMG > and > others. And if it doesn't how one might actually encode an > Architecture. Is UML sufficient? Can we describe all of the > interactions that occur between a set of services using UML in an > unambiguous way? Could we do with BPEL or BPMN? Could we do with > WS-CDL? > > Why should we care? Pretty simple really. When you Architect in the > world of civil engineering, electrical engineering and so on, you use > a > formal description of the system (not all the detail but enough) to > simulate and test. This is how Architects find that the stress levels > on a specific beam are too high or find that they have over specified > some tolerance can reduce the cost of a component. Without such a > description this cannot be done. I would content that we should do the > same in software. If you cannot write down your Architecture then you > do not know enough about what you are doing, and you will have a high > risk of failure because of this. > > I believe we can do better and make the dream of SOA a reality in a > lower cost and lower risk way. In effect I think we can put the A back > into SOA as opposed to continual talk of SOA when we really only mean > Service Orientation - which is a step higher than Object-Orientation. > > The above rantings are not just the work of a demented long in the > tooth perhaps should retire too old software guy. Rather they are an > extract of many discussions with many practicing Architects who > deliver > real systems (not software products) that deliver real business > benefit > to real customers. > > Thoughts please ......... > > > Cheers > > Steve T > > On 15 Mar 2006, at 13:56, Ron Schmelzer wrote: > > > So, what exactly is architecture infrastructure? Aren't these two > > different things... does it make sense to even combine these two > words > > together? > > > > Ron > > > > Anne Thomas Manes wrote:Gregg, > >> > >> A SOA infrastructure [sorry JP, but I think this term is useful] > >> ought to support any type of communication style: synchronous vs > >> asynchronous, request/response vs one-way, direct connection vs > >> brokered, queued, pub/sub, Linda, etc. It's even better if the > >> infrastructure is natively supported by most development platforms. > >> > >> I think this last point is the most serious downfall for J/JS. You > >> had the luxury of developing your own communication infrastructure, > >> and you chose to base it on J/JS. (I think this was a great > decision > >> for you.) Most organizations don't have that luxury, though. For > >> them, software infrastructure development is not a core competency. > >> So they buy it. And because a communication infrastructure is such > a > >> critcal component in their IT systems, they tend to buy it from > >> solid, stable vendors -- IBM, Microsoft, BEA, Oracle, SAP, etc. > None > >> of these vendors provide native support for J/JS (or any Linda > system > >> for that matter). > >> > >> I've always been a big fan of Linda, but you must agree that it's > a > >> fringe technology. It's been around for ever, but never been a part > >> of the mainstream. The key advantage I see for using SOAP as the > >> foundation for SOA is that *everyone* provides native support for > the > >> technology. > >> > >> Anne > >> > >> On 3/14/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote: Anne Thomas Manes > >> wrote: > >>> > I understand that the JERI stack opens J/JS up to allow > >>> integration with > >>> > other languages and protocols, but there are a number of > features > >>> in J/JS > >>> > which are available only to Java applications. > >>> > >>> There are a number of Web services features that are only > available > >>> to web > >>> services applications. > >>> > >>> Where is the line drawn to differentiate? I am not sure what > >>> missing features > >>> you think are problematic or which would cause problems. Can you > >>> share some > >>> specific concerns? This is really an interesting issue for me. > >>> > >>> At some point, the technology of choice is visible in your > SOA. The > >>> proliferation of a technology into your software implementation > is a > >>> technical/implementation issue which needs attention. > >>> > >>> Gregg Wonderly > >>> > >>> > >>> > >>> > >>> > >>> Yahoo! Groups Links > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> __________ NOD32 1.1431 (20060305) Information __________ > >> > >> This message was checked by NOD32 antivirus system. > >> http://www.eset.com > >> > >> > >> __________ NOD32 1.1431 (20060305) Information __________ > >> > >> This message was checked by NOD32 antivirus system. > >> http://www.eset.com > > > > -- > > _____________________________________________________________ > > Ronald Schmelzer > > [EMAIL PROTECTED] > > Senior Analyst > > ZapThink LLC > > Direct: 781-577-2779 / Main: 781-207-0203 > > > > > > > > SPONSORED LINKS > > Computer software > > Computer aided design software > > Computer job > > Soa > > Service-oriented architecture > > > > YAHOO! GROUPS LINKS > > > > ▪ Visit your group "service-orientated-architecture" > on the web. > > > > ▪ To unsubscribe from this group, send an email to: > > [EMAIL PROTECTED] > > > > ▪ Your use of Yahoo! Groups is subject to the Yahoo! > Terms of > > Service. > > > > > > > > > > SPONSORED LINKS > Computer software > Computer aided design software > Computer job > Soa > Service-oriented architecture > > YAHOO! GROUPS LINKS > > ▪ Visit your group "service-orientated-architecture" on the web. > > ▪ To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > 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/
