Re: [service-orientated-architecture] Re: SOA Infrastructure

[Todd Biske]

On 3/10/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote: While I wholeheartedly agree with the premise of architecture before design, Alex replied: I want to ask that because I cannot agree with "architecture before design". I'd actually love to hear more on people views regarding architecture and design.   Strictly within the context of a project, I've had many colleagues who have struggled with exactly what an architecture review was, both from the presenter side and from the reviewer side.  I've met reviewers who clearly were expecting a design review (i.e. they wanted a complete class diagram, among other things), and I've met reviewers who were content just seeing the physical components involved without any mention of the business logic associated with the system.  The presenters have the worst scenario because they have no idea what the reviewers are expecting. For me, I've only been able to make a clear distinction between what I expect from a concrete solution architecture and a concrete solution design when I started to think about SOA Governance.  The reason for this is that one of the things that I believe must happen for an enterprise SOA effort to be successful is that ownership of services must be identified early in the process.  If it isn't, the service is likely to be completely dominated by the needs of the project that identified it, and probably have little value outside of that project.  At what point should these ownership decisions be made?  To me, it's as soon as the service boundary has been identified.  I want the concrete solution architecture to identify these boundaries with a short narrative on what the service is expected to do.  At this point, I can see if a similar service exists in my repository (in which the owner is now known), whether the service matches a planned service from a strategic blueprint, or if it is brand new.  >From there, the governing body can figure out who should develop and own the service, and get that team hooked up with the project (service consumer) team and have them iron out the details of the interface (design).   If the project came in with all of the details already, this already puts some bias into the interface design process, when it should be a negotiation between the provider and all currently known consumers, rooted in standards wherever possible.   Thoughts?  One litmus test that is an interesting exercise is whether this same approach would hold for external integration, since the scenario I described above is suited for internal consumers and providers.  I still feel that the interface design should be a negotiation, and it holds true that if you don't come to the table with something in mind, the other party is going to dominate the negotiation. -tb 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.