Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Siebel Systems (SEBL) - strong buy? -- Ignore unavailable to you. Want to Upgrade?

To: Stock Farmer who wrote (6723)	5/21/2003 12:02:19 PM
From: Lizzie Tudor	Read Replies (2) \| Respond to of 6974

deeper tech labor pools (Ottawa), I still have to laugh over this John. Ottawa has a deeper tech labor pool than SV. OK John, sure. Also, last year I worked in an israeli startup company. I know you aren't going to know the specific details of what I'm saying, but perhaps some others on this thread will understand. We farmed out a middleware app to an israeli software shop ("the best one") - the task was essentially a trading community based on the object model with things like inheritance, etc. Basically, we wanted a middleware trading community product, where you could add a customer, and then link other customers to him and inherit all his business attributes on down. We explained the concept and documented it. Whenever we would call in to this software shop (in the middle of the night which would screw up everybody's schedule back in CA) everything was "fine, fine". We asked about their benchmarking numbers, again "fine". Then we get the product back, I took a cursory look at the architecture and found that they were storing the business-level data (customers etc.) in the oracle data layer in objects!!! . In other words they had an object in oracle called customer, and another object in oracle called payment_terms and another object called order_header and order_lines. What this means to people that aren't into data is that there is no field level addressability on these "records". This offshore firm understood the function we were trying to achieve, flexibility in business relationships in a middleware product. But what they were missing is any concept of how these products are used by customers in the real world, obviously they have never seen the architecture of SAP, Oracle apps etc. Nobody with any practical knowledge of how applications data is used in say, analytics would store the customer data in large objects like that. And, for most queries this thing was slower than xmas- same problem, no way to key the data. Herein lies the problem with offshore development. Some things are just assumed when you work with strong people locally. Otoh when you are working with some offshore facility, it is like trying to explain changing a tire on a car to a blind man, this is a huge strain on your tech leads who have to watch these offshore devt teams constantly so they don't make huge mistakes like this. If it takes your tech leads 100% of their time to police these people offshore, then it is actually MORE expensive working this way vs. what can be done here. Oracle apps, which use offshore development for huge % of their core functionality starting with the 11i release, are the buggiest apps in the business. Why are offshore app developers so hard to manage? Because they don't have the context you get with local R&D, imo. Earlier this year, Oracle delivered the third version of its 11i applications suite, known as 11.5.3, for Unix computers and for Windows. Previous releases of the 10-month-old suite required a staggering 5,000 software patches--and an amazing degree of patience from early adopters. But missing functionality and those software bugs in the first release of 11i and the subsequent 11.5.2 version could also be costing Oracle potential business. Walter Stokes, lead database administrator for EDS's Oracle application service provider offering, is advising ASP clients not to upgrade to 11i until EDS can evaluate 11.5.3. The earlier releases are "the buggiest software I've ever seen come out of Oracle," Stokes says. Oracle's CRM module has been particularly problematic, he says, requiring up to 100 patches for one customer. informationweek.com