[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: The Battle for Web Services
By the time an RFP is issued, the guessing had better be done and the bets made. I worded the question deliberately to see how different people would approach the problem. I said, "an enterprise of a **type**". 1. One might assume that the 'type' determines services that this enterprise offers beyond the common business sets, say spec'd by something like ebXML. One would want to understand that type very well and stay away from types one doesn't understand (start ups have a definite chicken and egg problem although the fact that many XML committees are staffed by smaller firms or industry outsiders gives them an opportunity if a thin one). 2. Given an RFP, as I said, the first thing I would do is look around for any specification citations and hardware or software required or optioned. That scopes the technology options. 3. If this is an RFP (Request for Proposal) and not an RFI (Request for Information), I would assume the consultancy period is over. I don't get to argue the customer out of things, but I can say no or suggest alternatives. RFPs are typically coded for such responses. Important: the more I argue with the customer about what is good for the web, whether or not a vendor of a particular system is evil, or anything other than answering the specific requirements, the more likely I am to lose. Keep technical politics out of Proposals and on Blogs where they belong. If I try to argue REST vs SOAP, I won't make the downselect. One has to either be prepared to say 'no bid', or implement one or either. One may get a bid that says 'service-oriented architecture is desirable' and that is all. Now one has to make a bet because dollars to donuts, the customer doesn't know what that is, and possibly, one's opinion of what that is varies from one's competitor's and perhaps one's core technology vendor's. I am willing to bet a beer that if we ask on this and a few other lists 'what is a service oriented architecture' we would get some surprisingly variable answers that make different cases for the values of different technologies for loose coupling, HTTP vs Everything Else, identity authentication, orchestration vs choreography, transaction recovery, and so on. How many would actually take the time to compose a service set standard for the enterprise type? The answer Chris gives describes the technologies he would implement. Unless that conflicts with what is found in item 2, he is ok but just starting. Now one has to determine which of the functions this enterprise type performs are suitable for web services, and which aren't. What are the criteria? As one can see from item three, the battle of the web services is not fought by the vendors of the core technologies. They are just the arms dealers and map makers. It is fought in the middle tier vendors who are often selling to small to middle sized businesses for whom ROI has to be fairly immediate and where for the implementor, the profit margins for the jobs are thin and costs are fixed once bid. Probable result: commitment to a core tech vendor production system for creating service sets for enterprises of a given type. Otherwise, one won't be able to compete against IBM. Didier says one shouldn't be dependent on a particular vendor, but for jobs of this size, one will want to be. The job is not done by a single developer but teams. Managing multiple developers each of whom has a different technical religion will result in failure to meet schedule, budget, and requirements. Particularly in the battle for web services, one will want to provide as turnkey a solution as possible or else the implementation costs will consume all of the profit. No free lunch. BTW: the battle is not over the content type standards. These have to be free and reliably implemented by the time the RFP is issued. It is **precisely** over capturing the business logic. Why did Bill Gates suddenly embrace open standards and open source? Because in a services-oriented architecture for a typed business, the implementation technology should not make any difference to the services the system can perform. If it does, the technologies are NOT standard and the customer is right back to buying from the vendor with the most complete system. No change. In other words, web services are NOT a killer app, and do not puncture the equilibrium. They open up communications and enable enterprises to interoperate. That's all. The value is still in the business logic and it is even more locked behind the firewall than ever before. len
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|