Hi Eric, On Sun, 2006-08-06 at 15:12, Eric Newcomer wrote: > I was talking with someone Friday about some of the problems in Web > services (we have seen several posts to this forum about them) and he > reminded me of the tools component of the issue. In fact that may be > one of the largest challenges the industry is facing since developers' > view of technologies such as Web services is viewed through the lens > of what features, functions, and capabilities a given toolset > supports.
After reading this and all of the other posts in this thread, I was wondering if your last sentence doesn't reinforce the issues Dan mentioned about tool dependencies. Maybe it's just me (possibly proving one of Keith's comments about character traits :), but if the developers' views of Web services and other technologies are really that influenced by *any* particular tool vendor's offerings, how can they understand what that technology can really do for them in their solutions? You must understand the distinctions between the concept and the implementations. If you really understand the technology, you should be able to build, modify or use tools to allow you to leverage the capabilities that you need to deliver your solutions. Yes, one set of tools may make it easier than another, but that's all part of the evaluation/selection process Dan mentioned in his post. However, in most cases, Keith's right: your employer isn't paying you to develop a better mousetrap. The thing is, sometimes even if that isn't what they don't want you to do, it is exactly what they need you to do. The communication paths should work both ways, and the business owners should understand the overall value of what they're getting when the project is delivered into production. Unfortunately, for reasons already covered previously by many different people, what often happens is that while the idea might be sound, the implementation itself isn't. This is where the hubris Keith mentions ends up manifesting itself. Part of the decision to embark on going your own way means to commit to delivering production-grade software. If you can't do it, or your team can't do it, then to start down that path is sure folly. While at times I might seem anti-vendor, I'm not. This scenario is precisely why you need vendors to do the heavy lifting. How often and what to lift can only be determined by the specific environment you're working in at the time, and what makes sense for one team in an organization on a given day may not make sense for another. This is the point I was trying to make about really understanding the context of the solution--not just the software part, but the whole environment. Once you get that, you as the developer/designer/architect have the information you need to make the right decisions. Not that it's my place to say it, but thanks to everyone participating in this discussion so far. I think there's been a lot of good points expressed. Cheers, ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org 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/
