Steve Jones wrote: > Technology only matters where it is applied. The most common problem > is where people focus on the technology as being the solution rather > than thinking about the problem first and then what technology is > appropriate.
Using a technology requires some accommodation for it from some perspective. Whether you use a library that converts SOAP to Java objects, or you write all the code yourself, you are investing in the technology with some effort and dependency on the technology. You can create a highly customizable marshalling layer in your software to manage this interaction with the real world. But you have committed then, to that technology which you created to interface to all the other technologies. It might be flexible, but you have to deal with all the bits and pieces that don't work quite right, or which have issues around performance or usability for particular scenarios. At the architecture level, you have to make a decision which says "All data interfaces will be done using mechanism X". That commitment to any X, no matter what it is, is a commitment to technology of some nature. > Now I might be short sighted and naive, but I would say that comparing > technologies for flexibility independently of the problem is pretty > much a recipe for disaster. I don't believe I suggested this. I simply said technology matters. How you treat it in the architecture process and how you treat in the design and coding process will have some impact on how that technology impacts your project. But in the end, there is a 100% chance that your project will be impacted by whatever technology you choose. It might be a positive impact even! Gregg Wonderly
