Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

SAP vs. Oracle, Battle Royale 147

Mark Brunelli writes "As the battle for business application supremacy heats up, Oracle users are standing by Larry Ellison and Fusion while SAP customers say NetWeaver will lead the way to victory." From the article: "Zoellner, who says he has worked with both Oracle and SAP users throughout his career, believes that the Nucleus Research study cited by deHenry is right on in its conclusion that Oracle's average three-year total cost of ownership (TCO) is 48% lower than SAP's. The business analyst said that the TCO issue is particularly important to companies in developing areas."
This discussion has been archived. No new comments can be posted.

SAP vs. Oracle, Battle Royale

Comments Filter:
  • wow (Score:5, Interesting)

    by caffeinemessiah ( 918089 ) on Tuesday March 07, 2006 @01:39AM (#14864615) Journal
    if ORACLE's TCO is 48% lower than SAP, just how many small countries' budgets does SAP charge for a small installation?
    • by r00t ( 33219 ) on Tuesday March 07, 2006 @01:43AM (#14864624) Journal
      2. A small, blunt object used as a weapon, often constructed from a bag filled with loose, heavy objects such as lead shot or coins.

      5. Colloquially, a sap is a weak or gullible person. Also known as dupe; see confidence trick.
    • Re:wow (Score:5, Interesting)

      by tyler_larson ( 558763 ) on Tuesday March 07, 2006 @01:56AM (#14864671) Homepage
      if ORACLE's TCO is 48% lower than SAP, just how many small countries' budgets does SAP charge for a small installation?

      Costs vary (particularly installation and configuration costs), but as a rule of thumb, if your business's income isn't enough to make your state government envious, then SAP is not for you. If all you need is a "small" installation, then you really don't need SAP.

      Though I am interested in hearing what Oracle has to offer; I had thought that SAP was the only player in this field, which is why they can charge so much for such a horrible product.

    • Re:wow (Score:2, Interesting)

      by Avogadro65 ( 942457 )
      I don't know how much my company spent on its recent upgrade to mySAP, but initial SAP installation a few years ago cost $28 million. $3 million for the software $25 million to install the sucker That's for 4 large plants, a general office, and countless sales offices across the continent.
    • actually, the cost for a sap implementation has killed many companies.
    • Re:wow (Score:5, Insightful)

      by supersnail ( 106701 ) on Tuesday March 07, 2006 @07:21AM (#14865392)
      I have not much experience with Oracle ERP impelmentations. But my experience of both SAP and Peoplesoft is this:-

      It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.

      The main problem is upper IT management are sold on the "we implement best practice you dont have to change anything" idea. Which collides with the
      real world of "we dont do it that way here" of the business managers.

      The only way to implement these products quickly and cheaply^H^H^H^H^H^H for merely outrageous cost is to implement the vanilla package and change the way the business is run to suit. This usually involves sacking/losing half your business management to force the changes through.

         
      • that's true. they say that with SAP you don't need do code, only customize. But instead of 1000 coding man hour, you will need 1000 customizer man hour (more expensive than coding). Here in Brazil a lot of companies are doing small erp-like systems... all crap, but better than SAP since you have access to the code
        • they say that with SAP you don't need do code, only customize. But instead of 1000 coding man hour, you will need 1000 customizer man hour

          Fact is, there's only so much you can do with customising - it's analagous to slotting lego bricks together. You can't make settings for what isn't there - that tends to put an upper limit on how much of it you can do.

          Hacking code around is more like carving your own bricks. Or just carving. There's no end to what you can create - useful or not, needed or not, justifie

        • Interesting. Last time I looked at SAP (today, actually) I had access to application code. Not the kernel, but what use would that be anyway?
      • Re:wow (Score:2, Informative)

        by al_broccoli ( 909467 )
        It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.
        Wow, that's such impressive FUD. Do you work for Microsoft?

        My team of 12 (internal employees, not consultants) can have a freshly installed system (takes me 1 day to install) configured in under a month. You couldn't write a product in any language or tool with the same number of people in under 2 years. And even then, it would be cripped compa
        • Re:wow (Score:4, Insightful)

          by molarmass192 ( 608071 ) on Tuesday March 07, 2006 @09:51AM (#14865811) Homepage Journal
          configured in under a month.

          This would only be possible in a VERY small company rollout and with absolutely no customizations, no legacy data, or legacy workflows. I guarantee you, and yes, I've done several Oracle Apps rollouts, that a company with 1000+ employees has no hope in hell of rolling out a system in anything under 6 months. The average being well over a year. The longest part of these rollouts are getting people to sign off on workflows, the tech piece is a relatively small part of it.
          • True, I am referring to basic functionality. But for many, this is just fine. I can't speculate as to how much time it would take for customizations without defining those ahead of time. Of course, my management seems to be able to. :)
        • My team of 12 (internal employees, not consultants) can have a freshly installed system (takes me 1 day to install) configured in under a month. You couldn't write a product in any language or tool with the same number of people in under 2 years. And even then, it would be cripped compared to SAP's ERP product.

          Oh yeah? well, my team of one can have a freshly installed system (takes me 1 day to install) configured in less than a week. Of course then the organisation spends 3+yrs fighting over business pro

          • Of course then the organisation spends 3+yrs fighting over business process and we bring in 100+/- consultants to converge the existing business with the ERPs implementation.

            Hard to blame any application vendor for that.
            • Hard to blame any application vendor for that.

              Wasn't blaming the vendor, just pointing out that unless you are in the extraordinarily unlikely position of having a business that lines up 100% with the vendors "best practices" installing the software is the cheap and easy part. 'Cause after that, you get to either customise the software or re-write your current busines processes. Typically it's a little from column-A and a little from column-B.

              So! The point was that depending on how much or how little you

              • unless you are in the extraordinarily unlikely position of having a business that lines up 100% with the vendors "best practices"

                The inflexibility of SAP is a bit of a myth, to be honest. If you think installing SAP means there's only one way to do it, you're simply plain wrong. When they talk about customising, that's basically plugging a range of preprogrammed behaviours together. But it's surprising just how many variations that can give. In my experience 90% of the times SAP "can't do it" it can, b

              • Agreed, but any SAP implementation project I've been associated with has taken the stance that, where the customer's business processes differ with the way SAP automates things, the business processes will change (where possible), which is why it's so common to have a business process re-engineering in association with an SAP implementation. The reason for this is, of course, the expense associated with customizing and maintaining the SAP system on your own. Virtually all companies do this, and it's reaso
              • If, as you suggest further up, you can spend 3 years arguing internally it would seem you're not even 100% aligned with yourselves.
      • Re:wow (Score:5, Insightful)

        by hey! ( 33014 ) on Tuesday March 07, 2006 @10:17AM (#14865941) Homepage Journal

        It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.


        Well, it depends. Look at it this way, management is the customer. Your internal IT group is one vendor, SAP is the other. Does the customer really understand what he wants or needs? Probably not; they're focused on other areas. So as a vendor you need to have a market position -- an "elevator pitch". SAP's is pretty good: "we implement best practice you dont have to change anything". This is garbage to the developer's ears, but music to the customer's ears. What they are saying is the customer doesn't have to become an expert in the IT area, they can stick to their knitting and SAP will take care of the strategic IT direction. Lazy? Maybe. Sometimes Lazy == Efficient; knowing when this is so and not so is not a science.

        The next thing on the customer's mind is risk. Can the vendor do it? Well, looking around, pretty clearly a lot of people are have some degree of success with SAP's products. Can the same be said for you? No. While it may not be your fault, clearly the vendor you work for has not solved whatever problem it is to date, so in the customer's mind you're asking for a second chance. Unless you can convince them you're not their father's IT department, forget it. What you need is the one service that as an internal vendor you're not allowed to have: marketing.

        The thing that's never on the customer's mind is how much trouble it is for you. If another vendor makes the decision easy, offers apparently lower risk, then the fact it makes your life hell by making highly paid technologists do dull configuration work, well it doesn't matter. The customer would get rid of you if he could, but he can't figure how, so he may as well put you on work he understands, which is underwriting a safe bet.
        • "Some degree of success with SAP products"... what, they bought it?

          Who here's ever seen a wildly successful SAP deployment in any medium to large sized company? I haven't.

          I know someone who's made a second career out of consulting to a specific small companiy that wanted to "act like the big boys", on the implementation of SAP.

          That person had been through the hell-on-earth that the larger company's SAP implementation had been and become over the years, so that gave them enough insight to go in and try to p
      • It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.

        Sorry, but you don't know what you're talking about. I've installed complete PeopleSoft systems, including creating DB2 and/or Oracle DB backends, in less than a day. And I'm not even a PeopleSoft guru, just a techie who did some training.

        Writing a complete system, to do everything that one of these products does, would take a considerable amount of

        • Admittedly my experience has been peripheral technical support for these projects. And I would add the caveat that these were both for very large and complex companies (everything needed to be multi-lingual and multi-currency).

          But the projects took between three and five years to deliver and employed about 50 people each.
          And as I had to use some of the front end applications I can attest to
          the poor quality of the end user interface.

          Speaking to the people involved more closely and listening to thier various
          • Admittedly my experience has been peripheral technical support for these projects.

            Translation: I'm a helpdesk monkey.

            these were both for very large and complex companies (everything needed to be multi-lingual and multi-currency). But the projects took between three and five years to deliver and employed about 50 people each.

            I'll go out on a limb and assume that this was in the US. That would break down as one year explaining what another country is, one explaining what another currency is, and one expla


            • Translation: I'm a helpdesk monkey

              Actually the day job is as a middleware guru.
              Various other posters have commented on the lines
              of "why don't I get a job consulting on this if I know so much"
              the answer is that I get paid more than a SAP consultant and
              the work is much more rewarding and interesting.

      • It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse
        If I thought that to be true I'd be making a nice income going to companies and helping them do just that. So if you think it's true why aren't you?
        This usually involves sacking/losing half your business management to force the changes through.
        You say that like it's a bad thing.
    • by Nelson ( 1275 )
      Am I the only one that is just utterly amazed that they can actually come up with quantifiable numbers that they can compare between the two? Isn't that what they built Deep Thought for in H2G2? People write PhD thesis' on that crap and don't even start to answer it, they just raise more questions.
  • by ameoba ( 173803 ) on Tuesday March 07, 2006 @01:42AM (#14864620)
    It seems illogical to compare TCO of SAP, an established ERP platform, with Oracle, a Database that's in the process of buying the pieces to start their own ERP suite. Maybe in another 5 years when Oracle has their product line put together it would make sense to compare the two.

    Even at that, in the Enterprise market, where 'quality' is judged by 'longevity', Oracle's going to be at a major disadvantage.
  • TCO (Score:4, Insightful)

    by Anonymous Coward on Tuesday March 07, 2006 @01:44AM (#14864629)
    Why isn't Net present value used as the benchmark for comparing two IT projects? It really is the only one that makes sense because TCO doesn't take into account the interest rate.
    • Re:TCO (Score:4, Interesting)

      by the_womble ( 580291 ) on Tuesday March 07, 2006 @02:47AM (#14864825) Homepage Journal
      Why isn't Net present value used as the benchmark for comparing two IT projects? It really is the only one that makes sense because TCO doesn't take into account the interest rate.


      Because everyone (i.e. including management) knows that NPVs are very uncertain thanks to all the assumptions that have to be made in order to calculate them.


      As non-IT people are less familiar with TCO they are less likely to be suspicious about the numbers.

      • Exactly. For most things, NPV is complete bullshit. I buy NPVs when you use the risk-free rate, because yes, you could take your money and buy a T-bill with it and that's a valid comparison.

        But most companies use internal rates of 12-15%. Let's say they're weighing a $500,000 computer upgrade. Using a 12-15% number employs the fiction that they could take that $500K and invest it in a worthwhile project that would yield 12-15%, so they're computing the tradeoff of that (fictional) project vs. the up

      • NPV is extremely valid when comparing two projects. The assumptions you reference can cause differnt results if they are not applied consistently to both projects. When done in the same organization, with the same assumptions affecting the factual situations, they are a valuable tool. NPV is not an absolute number but a method of ordering different alternatives. Your post is correct if you compare NPV of two projects computed with different assumptions by different individuals.
  • SAP == CRAP (Score:5, Interesting)

    by autopr0n ( 534291 ) on Tuesday March 07, 2006 @01:45AM (#14864635) Homepage Journal
    Seriously, how many people have ever had a chance to glimpse into the dark heart of SAP? It's very ugly. Hedious even.

    It might run business well, but it's hardly very extendable or flexible. Given the price you're better off writing your own system, IMO.
    • Re:SAP == CRAP (Score:2, Insightful)

      by Big Nothing ( 229456 )
      "you're better off writing your own system, IMO"

      Please e-mail me your name, so I can tell our IT dept, economy dept. and human resources dept. to NEVER EVER EVER hire you or consult you or even talk to you. Please.

    • Re:SAP == CRAP (Score:5, Interesting)

      by jools33 ( 252092 ) on Tuesday March 07, 2006 @03:51AM (#14864970)
      "Seriously, how many people have ever had a chance to glimpse into the dark heart of SAP? It's very ugly. Hedious even.It might run business well, but it's hardly very extendable or flexible. Given the price you're better off writing your own system, IMO."

      5 years ago I think this comment was valid.
      Having worked in SAP for over 10 years I can partially agree with your comments. Historically SAP has been slow to adapt its central ERP system (R/3). However thats not where the battle is being fought at all - and I think you've missed the point of the article. SAP's new platform - Netweaver really isn't one single system - its a complex architecture not a single platform any more. Its this architecture that Oracle is competing against by acquiring as many of the competition as possible and then trying to integrate them into a single solution. SAP have had a smarter approach where they have mostly not bought out the competition (althought thats not the case with MDM or Toptier). SAP have instead realised about 5 years ago the direction where things were heading and I really believe they are several steps ahead of Oracle now in terms of building a full blown Enterprise Services enabled architecture. In my opinion SAP have neglected updating the central (legacy) ERP system (R/3) in favour of building an enterprise services / integration architecture around the old central product - so much so that the old legacy R/3 system isnt really central anymore - the systems around it such as business intelligence, CRM, APO, Xi, solution manager have taken a much more prominent role - and each of these new systems - whilst running on the same base kernels really are completely reworked in terms of the architecture and APIs on offer.
      SAP still have a long way to go - and they could really do with reworking some of those older "hideous" code libraries - particularly on their R/3 platform. With Netweavers Enterprise service architecture - SAP looks to be truly flexible and extensible and leaving its old "hideous" code behind - and I suggest the previous poster take a read on http://sdn.sap.com/ [sap.com] for a more up to date understanding of what SAP today is all about.
    • Re:SAP == CRAP (Score:1, Insightful)

      by master_twig ( 575562 )
      SAP is actually an acronym.

      Suffering And Pain.

      God how it hurts.
    • Hardly very extendable or flexible? You could try throwing countless dollars and developers at it like IBM did. It took a few years, but many of the wrinkles have been ironed out.
    • SAP stands for

      Schreck Angst und Panik
      or
      Software Aus Pakistan.

      They're using it here at work for almost everything. Looks like a relic from the stoneage (Sapgui). Impossible to support with newer software, interfaces with close to nothing.
    • Re:SAP == CRAP (Score:3, Insightful)

      I can't claim to have glimpsed into the dark heart of SAP but having had to work with/around it for over two years I can tell you this: SAP is a slow, bloated, inflexible pile of pig waste. Some examples:

      Users had to print a form. They selected the form and printed it. The information was squished on the page (horizontally). After pointing out the issue and providing samples the response was, "The printouts worked in testing. We have no plans to go back and redo the forms. Have the user choose a close
      • When inputting the time you work (which has to be done every day) the initial starting date is always the first of the year. You have to manually change the date to sometime during the current pay cycle to input your time.

        Where I work we use SAP and I have to disagree with you on about everything you have to say. I input my time once a week and when a new week comes along it automatically goes to it.

        If you get paid by several different funding agencies (as I was at my previous location) you have to manu

        • I work for state government so that probably explains many things.

          As far as my time is concerned, the only way I can explain it is that it uses a grid to hold the information. Line 1 would have a certain funding code number for the agency which paid part of my salary. Line two would be a different funding code number for the next agency that paid part of my salary. A total of seven lines.

          As far as taking leave is concerned, since each agency has a different percentage of funding allocated to it, each has
    • Have you looked into the linux source? Not exactly beautiful and tricky to modify unless you really know what you're doing.

      It may run your apps well, but it's hardly extensible or flexible. You'd be better off writing your own operating system, IMO.
  • Open source (Score:3, Interesting)

    by Eightyford ( 893696 ) on Tuesday March 07, 2006 @01:53AM (#14864664) Homepage
    "My feeling is that the pricing from SAP is far too high," Zoellner said. "I know this has been a problem."

    With so much money going into enterprise applications like SAP, why haven't we seen an open source alternative? Why wouldn't IBM, Walmart, and GM (for example) get together and create an open source version? They could share the costs with each other and smaller companies, while avoiding vendor lock-in.
    • The answer (Score:5, Interesting)

      by SuperKendall ( 25149 ) * on Tuesday March 07, 2006 @03:41AM (#14864945)
      The reason you have not seen an open source SAP is because it's so big and monsterous and hard to figure out what it does, that no-one knows if there's already an open source SAP or not. There could be several right now.

      Only half kidding.
      • What the hell is it? I get a different answer every time I ask.
        • That's because it does so many things. Consider it a framework that has modules for all the business related functions and then some; Material Mangement, Sales, HR, Finance, etc. They're all tied together and are able to share the information as needed. To tie it all together is a built in programming language called ABAP which is like 1908's BASIC + some SQL commands. It's meant to replace all your various in house programs into one intergrated product. A lot of companies jumped on board during Y2K
        • It's an Enterprise Resource Planning suite.

          A somewhat longer answer is:
          It's your accounting system of record. If you're audited, that's what gets audited. IT holds your chart of accounts. It holds all data necessary to develop your Balance Sheets and P&L statements.
          That's the "core" module, and both SAP and Oracle have commonalities here, with an Accounts Payable, Accounts Receivable, and General Ledger module that is typically considered a "core" installation.
          After that, you start getting complic

          • In terms of open source solutions, I highly doubt anyone's gone that route. It's such a big undertaking, I don't think OS has even come up with a reasonable, scalable accounting suite.

            I think it's not so much that open source couldn't, but it just wouldn't want to. Accounting is boring - it's not even mathematically interesting - and all this double entry nonesense sounds very inefficient. Business majors are so square. Sales is for teh luz3rz in 5uitz.

            What would 99.999% of geeks rather do - research

      • If you are still half kiding, I am completely serious. As far as I can see, SAP sells the same customization capacity of gcc. It can become anything, and so, it needs a complete program to become something.

        The reason you don't see some open source SAP is because FOSS people don't have a marketing department, so they normaly create software that in fact does something, or follow the specs and write a compiler.

        Well, ok there is a big library with the SAP package (the framework thing), but those we have at F

    • Re:Open source (Score:2, Interesting)

      by blacklevel ( 956427 )
      While this is not a full-scale alternative to the likes of SAP or Oracle, Compiere http://www.compiere.org/ [compiere.org] does cater to the small and midsize market. This currently only runs on top of the Oracle database, but is in the process of being ported to Postgres.
    • Re:Open source (Score:2, Insightful)

      by bn557 ( 183935 )
      In a lot of cases, the responsibility in the case of financial transaction flaw, falls on the software developer.
  • TCO studies are hardly if ever conclusive because in some situations, one product will have a lower TCO in the long run and in other situations a different product will have the lower TCO. I think the reason why companies keep going back to TCO is the fact that it is nearly impossible to prove right or wrong (one case or even a handful of them does not make a rule), they hope lazy managers will believe them on the subject without thinking it through, and they are run by weasels.
  • by marcushnk ( 90744 ) <senectus@nOSPam.gmail.com> on Tuesday March 07, 2006 @02:07AM (#14864711) Journal
    and Oracle financial won hands down time after time after time.
    Where it was let down was in the procurement and maintenance sections... where BOTH sucked fetid dingo kidneys.

    That was 3-4 years ago now.. so I hope Oracle have picked up their game....
  • by Anonymous Coward on Tuesday March 07, 2006 @02:11AM (#14864723)
    it's a carefully placed advertisement from the Oracle PR machine. 48%? Gimme a break, no one can determine TOC figures for something as complicated as SAP to that degree of precision.
  • by Anonymous Coward
    SAP and Oracle will resolve it once and for all by putting Japanese schoolboys and girls on an island and letting them fight it out? CooL!
  • by lucm ( 889690 ) on Tuesday March 07, 2006 @03:22AM (#14864902)
    Until now I was sure that the only thing with a higher TCO than Oracle was a Sea Stallion helicopter (38 hours of maintenance required for every hour of flight). I guess I never thought about SAP TCO because most of the SAP rollouts I heard about failed.

    Those projects are so incredibly expensive, I have no idea what kind of scale they use to calculate the TCO. Teradollars? I can imagine a board meeting (CIO: "Hey guys, we must make room for 317 Teradollars in the next budget for this SAP thingy. So I guess we'll have to forget about the Winzip licenses for now.").

    Seriously, a friend of mine is convinced that SAP is part of a secret plan to crush the western economy.
    • Until now I was sure that the only thing with a higher TCO than Oracle was a Sea Stallion helicopter (38 hours of maintenance required for every hour of flight). I guess I never thought about SAP TCO because most of the SAP rollouts I heard about failed.

      But all we hear about is SAP projects that failed - we hardly/never hear of any successful ones. I've been doing software rollouts for PeopleSoft/Oracle for 4 years now, and I can tell you that while Oracle's product may have a lower TCO, it's usability su

  • by alchemistkevin ( 763955 ) on Tuesday March 07, 2006 @05:17AM (#14865149) Homepage
    on an Oracle affiliated site! Oh, it's very transparent and connects to well document studies, doesn't it? No? Anyways, we'll just take their word and say SAP's TCO is almost double that of Oracle's similiar offerings!? Similiar? Does anything from Oracle even stack up close to SAP's offerings? Nope! is the one word answer, no matter which camp you belong to, you cannot bring up a product that seamlessly brings together all aspects of a business as SAP does.

    All the modules can be individually customized and presented to the customer for his choosing whenever he wants to use that part of the package.

    No, it's not a battle royale, Fusion, never was and will never come close to where SAP is in the market today.

    High Costs!?!

    What's that, do you say a piece of code is costly just because it initially costs higher!?

    Have you ever worked in a company where SAP was implemented, do some costing for such a company and then come back and post on the cost savings they've had in their departments after implementing SAP, yes a few implementations do go pear shaped but this is generally not the case.

    I don't know about Zoellner's previous jobs but certainly can't find anything on google relating him to know anything that he claims to know about SAP.

    (Disclaimer: I'm an SAP Tech. Consultant)
    (home: http://alternateplanet.net/ [alternateplanet.net] )
    (blog: http://alternateplanet.blogspot.com/ [blogspot.com] )
  • Silly Arguments (Score:3, Interesting)

    by Trojan35 ( 910785 ) on Tuesday March 07, 2006 @05:39AM (#14865189)
    Guys, SAP has stuck around and will stick around because it's very hard to learn. You don't realize that sometimes it's more painful to fix a broken system than to live with its quirks. There are good reasons why businesses stick with SAP.

    Further, let's just drop all this OSS nonsense. I believe it would take 10+ years of development for anyone to seriously consider it. Let's say you develop a system. Who is trained on it? What major companies have successfully run it?

    Look how long it's taken Linux to gain acceptance, and Linux is something you can incorporate one server at a time. To move your whole company over to a new database system is not something anyone wants to do unless there's a proven, stable solution. This is just one of those areas where OSS can't compete effectively IMO. OSS isn't the answer to every question, as much as some would like it to be.
    • I think OSS has a place with in the ERP model. I don't expect to see an OSS financials package taking off any time soon, but the opportunity exists for OSS projects to gain ground in other areas like an HR package.

      This is especially true with Oracle. As it aggressively purchases other products, like People Soft, I expect efforts made to increase scale and extend compatibility between product lines. One of the simplest ways to extend compatibility without creating a ton of other issues is to extend the API
    • Compiere [compiere.org]
  • by simon_hibbs2 ( 792812 ) on Tuesday March 07, 2006 @06:44AM (#14865315)
    Ever noticed how all the biggest, most successful OSS projects are basic computing infrastructure projects? They're software written by techies, for techies. Things like compilers, operating systems, networking infrastructure, web server platforms, languages, databases. To write these things all you need to know is protocols, fundamental software architectures and how to program. They are areas where competent techie developers have a large amount of 'domain knowledge' - experience and in-depth understanding of the problem at hand.

    Open Source doesn't work well when the problem domain is an area that few techie developers have knowledge of. Then you need to bring in experts in the required area of expertise who have the time and motivation to contribute to an Open Source solution. Now this does happen, but it's much rarer. Take my employer. We produce engineering modeling design software for cellular mobile telephone networks. Our development team includes a group of very knowledgeable and experienced radio network engineers who do testig and write specs and requirements, include experts in 3G radio technology of which there are not many in the whole world. Without their contributions over the last decade, our software wouldn't be possible. You see a similar thing happening with computer games, which require a considerable, high-quality contribution of art assets.

    Techies have an innate interest in developing technological solutions to problems - if they have an itch it's likely to be a technical one and they are likely to want to develop technical methods of scratching it, which often means software. Artists, radio engineers and specialists from many other disciplines such as accountancy, human resources, etc don't have the same compulsion to develop or contribute towards software based solutions to their problems. It seems to me that corporate integration platforms like those offered by SAP and Oracle fall into the same category. They aren't the sort of problem you average techie is likely to feel any compulsion to solve, and those specialists you'd need to have involved in the development process aren't likely to be interested in doing so. This is where heavy ammounts of corporate funding is required to bridge the gap.

    Now of course this doesn't exclude OSS from the party. For example groups of companies could collaborate to fund an OSS solution to their common problem, but these are likely to be competing companies. We're talking about huge investments of cash here, invested over time spans of 5 to 10 years or more. I think OSS will eventualy start to penetrate into these areas as the software industry matures but I expect this will happen over the long term, like my lifetime for example.

    Simon Hibbs

  • Without going into too many details, our installation of SAP is horrible. Getting to the data in our particular installation seems to be a trial of the most monumental proportions. I am encouraged to see some competition and alternatives. I'm not the biggest Oracle fan but I'm less of a fan of SAP.
  • New markets (Score:2, Insightful)

    by Tzinger ( 550448 )
    The challenge for both SAP and Oracle seems to be that the current market is basically saturated. How do these companies move down to smaller customers and up to bigger customers?
    Both products were built on a classic client-server model. A single central server supplies data and function. In a really large institution (think Army, VA, etc.) the central server cannot provide the performance needed.
    Both Oracle and SAP are going after this type customer now and that is driving some of the changes.

    Smalle
  • So much fud (Score:4, Insightful)

    by al_broccoli ( 909467 ) on Tuesday March 07, 2006 @11:09AM (#14866316)
    If all of the people that had no experience in implementing or supporting SAP or Oracle ERP systems refrained from responding to this article, it would be very quiet in here.

    The fact of the matter is that SAP is a complex beast. I've been working with it, both developing and administering, for about 12 years now. I have no experience with Oracle's ERP product (though I am an Oracle DBA), but I'm sure it's just as sizeable. The issue with most "failed" SAP implementations that I'm aware of, and there have been many, is this - incompetence. Incompetence abounds in the technology industry. It's not isolated to SAP, either. I routinely interview job candidates for Oracle DBA positions, SAP Basis Administration positions, SAP BW Developer positions, and SAP ABAP developer positions. I find one very common thread among the candidates - very few of them know what they're talking about. If you hire them, either as an employee, or as a consultant, and they are the senior technical people on your implementation project, you are bound to fail. Whether it's implementation of the ERP product itself, or an implementation of new functionality. That's not SAP's fault, it's yours.

    In the end, the decision to go with Oracle or SAP should be based upon which product fits best in your environment, if either of them do. Interfaces are a significant part of this decision, and both SAP and Oracle have their strengths which need to be evaluated and prioritized. Supportability is, as well. If you are not willing to pay your senior developers and support staff more than $100K per year to maintain the product, then don't bother, you will likely fail. If the evaluation is done well, and the implementation is managed well, and you take care to hire the right people and retain them, then you will succeed.
    • Dang, that is right on man. I've been an Oracle DBA and Basis Admin before... and there certainly is that issue. If you don't hire a competent person and are willing to pay that person for their skills, they will flounder and that part of your implementation will suffer (and if Basis suffers everyone does).
  • Just to clarify a few things.

    I'm an Oracle Applications Consultant (DBA) that specializes in performing (and supporting) the implementation and upgrade of the "Oracle E-Business Suite" (or "Oracle Applications" or "Oracle Financials" as the name has evolved over a number of years).

    I first got involved with this product in 1993 when it was on "Release 9". I believe it originated 5-10 years earlier. This product has been around for quite some time.

    In the early/mid 90's, as another poster mentioned, moving o
  • The only problem SAP ever solved was "How do we burn through our budget before implementing everything?"

    From the empirical evidence I've seen, this saying exists for a reason.

  • Having worked in a big corp or two, I think a big part of the problem is that out-of-the-ass figures like "three-year TCO" are actually relevant, because companies try to swap out major pieces of critical software like Oracle or SAP about that often (or in some cases even more often). One dot-com I worked for, in less than three years:

    1. Decided to stop using an outsourced system for e-commerce and back-end stuff
    2. Blew millions of bucks on a content-management/app-development framework
  • Cisco and Juniper both use Oracle financials for their ERP. Its not as thick and based on oracle technologies.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...