Thanks for the clarifications Miko. That tools are becoming available is a Good Thing. My opinion is that these are good at enforcing the equivalent of coding conventions. Definitely a good facility to have, but not the entire picture.
Given that no environment will be pure architecturally (SO or otherwise) nor technically, such tools will be limited in applicable scope. I don't mention this to dismiss the tools. Rather, the concern I have is that the presence of such tools risks ignoring other areas that also need attention. Thus, I believe we need to stop touting "SOA Governance" and instead focus on the relative importance of plain ol' Governance. Regarding my skepticism--it wasn't about WS per se. Rather, it was about how web services were so much cheaper than EDI: "EDI projects required so much time and money that before any work could be done a business plan had to be written to obtain budget authorization. Switching to a Web services standards-based SOA approach including governance dramatically reduced those projects, the Software AG executive said." Can you elaborate on why the old EDI projects took so much time and money and what specifically the services-based approach eliminated? If there are some details you cannot disclose, that's understood. I agree that XML can be easier to deal with in many ways (but not always--ever try to read an SAP IDoc without documentation guidance?). But given that EDI issues are typically message content issues, my point was that the use of web services and XML doesn't solve that problem any better. One still has to do the content work. -Rob --- In service-orientated- [EMAIL PROTECTED], "mikomatsumura" <[EMAIL PROTECTED]> wrote: > > Hi Rob, > > I'll answer on-list as I think it's an important set of topics to > discuss. > > First of all, I do agree Governance is clear for any architectural > approach. SOA-ish projects are becoming neatly "governable" for a > few reasons though imho. > > One of the enablers is the happy occasion that there are an ever- > increasing quantity of XML based elements in the SOA landscape > (whether you're using WS or not) and that the ability to parse, > validate and otherwise automate governance aspects is a very handy > notion with respect to increasing the transparency of architectural > elements including policies but assertions and declarations of all > kinds. > > This enables a larger set of stakeholders to participate in the > governance model, although not all stakeholders will express > themselves as customized repository validation parsers, but many > might through simpler registry repository based policy assertion > user interfaces common to the best products in thie category. > > Sure a shot of skepticism is most welcome. I think if I were to > read this comment out of the blue I would also disagree... I'll > try to contextualize my statement about WS as I agree it's > important to be clear and not conflate technology implementation > with architecture. > > Web Services obviously doesnt equal SOA they are neither neccesary > nor sufficient to establish a decent SOA. However, as an enabling > technology for *some* SOA projects, they provide a reasonably handy > approach to some of the interoperability challenges. > > That said, web services certainly raise as many issues as solved, > particularly since they do such a "good job" of punting a lot of > the management and governance issues to external systems. > > Anyhow, this particular talk was focused on two customers who were > both very keen on WS, so the comments may have been more focused on > SAS and Sprint Nextel... > > I appreciate your comments and feedback and your points are well > taken! > > Miko
