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. > > 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/
