I'm loving this so much. It's 138 pages, and I intend to read it all. Here's a few teasers for y'all:
One developer experienced in Oracle products called Oracle’s programming “atrocious.” He added that “they broke every single best practice that Oracle themselves have defined. It is one of the worst assessments I have performed * * .” The same developer wrote to Oracle, “You are Oracle people, working on an Oracle hardware platform, with Oracle technology products, on an Oracle solution. * * Oracle should be delivering these environments and products as a solution, like they actually understood the products and owned the solution which has not
been the case by a long shot.”
AND
Oracle’s responses to the Vendor Questionnaire also stated that OPA and Siebel, the foundation of the “Oracle Solution,” could be implemented by business analysts, not software developers, and without customization. Oracle explained that “government subject matter experts (not application developers)” could define rules in OPA “in the terms and vocabulary that they are familiar with and/or as defined in relevant statute, regulations and policy documents. * * * There is no scripting or programming needed.”
At what point will people learn that this is... just not possible? We can dress it up with fancy terms (DSL, etc) but... any business system will require people to be able to think logically and critically about what they're trying to accomplish, and define it out in great detail. Computer languages are the best way we currently have to translate those details in to a computer, and likely will be for a long time to come.
Most of the Oracle middleware I've used has already been open source, in a way. The code was mainly PL/SQL which meant it was available for viewing and editing.
For what it's worth, I've seen comments within Oracle's own code that refers to their own code as being, and I quote, "a horrible kludge". And the quality of their middleware certainly backed up those comments within their code.
I will say in their developers defense, PL/SQL is such a nasty language that it does make it hard to write sane applications. Which is one of the many reason why I'd never touch Oracle again if I can help it.
Actually you are the one who's missing the point (as was the other ignoramus who "knee jerked" down voted me before asking for clarification on the subject).
Open source just means the source code is available. It doesn't mean the source code has to be distributed with a permissive, 'copyleft', licence. While it's true that when one usually talks about "open source projects" they typically refer Apache, GPL, BSD (et al) licensed code (and culturally that would be a fair description), but when one talks about the code being open source it can also refer to proprietary projects as well (as is the case with some of Microsoft's non-free open source licences).
So my comment makes perfect sense given the parent I was replying to: "I wonder if Oregon has jurisdiction to open-source this stuff. I'd love to see the atrocities.". In this instance, the less permissive open source definition would be valid since:
(1) you wouldn't be able to redistribute the code anyway (the government might force a company to release their source code, but it's even less likely they would want to alter the terms of a copyright agreement (and even less likely for US-based companies given the investment America has in intellectual properties)
(2) you can already read the source code to "see the atrocities" (which was the crux of my point rather than arguing about what classifies as "open source" - but well done for completely missing that point and every other subsequent point)
Lastly, before you turn this into an evangelical licence flamewar; I primarily write and contribute towards GPL projects, so I full endorse and support copyleft licences. In fact I'd go further than that and say that source code that's available for viewing but not for redistribution is more damaging than good; but that's a whole other topic of conversation.
A more accurate version of what you meant might be "I wonder if Oregon has permission to make the source code available for viewing" or something like that.
Maybe you should drop this pedantry (which is starting to come across as just egotistical nonsense now) and actually pay attention to what I've been trying to say. The Middleware I was discussing did allow for derivative works (as I stated in my original post!) so the licence was akin to some of Microsoft's "shared source licences" that have been reviewed by the Open Source Initiative as being "Open Source Licences" (citation: http://opensource.org/node/207). I'm guessing you actually trust OSI's definition of Open Source Licence better than you trust Wikipedia's ;)
But even that aside, I never said Oracle's middleware was open source per se, I said it was licensed similarly to open source (though my wording might have been clearer).
Oh and since this is now just an exercise in pedantry, I should point out that you posted a link to Open Source Software while talking about Open Source Licences. Obviously the two are related, but they're not specifically the same thing (though your confusion of the two might explain this discussion)
I don't view it as pedantry, I view it as avoiding dilution of the meaning of the term 'Open Source'.
It's important that people understand that it's not just having the source code, but also a license that allows you to do a series of things with the code. That's a huge, and critical difference, not a minor quibble.
In any event, it'd be fun to see Oracle's crappy code.
It's not your jargon to decide whether it should be diluted or not. And even just using the term "diluted", you suggest a great level of superiority and arrogance towards anything that doesn't fit within your narrow view.
Besides, if people want to understand what they can do with the code then they should read the software licence (that's the whole bloody point of it!) rather than just make guesses based on a common perception of a broader software term.
I see from all the other down voting that there's quite a few elitists who seem to have opinions about Open Source licences that differs with the Open Source Initiative's.
Perhaps some of you would like to come forward and offer your opinions rather than down voting and running like cowards? Or perhaps you're just davidw's alias ;)
The second I heard about this lawsuit I said to myself "this was a WebCenter project" and I was damn right. Let anyone here who has used WebCenter (formerly Fatwire) share their tales of woe. I'm usually pretty forgiving of buggy software or design mistakes (to err is human) but WebCenter is the most unbelievable clusterfuck of software I've ever seen by an order of magnitude. It's unbelievable that anyone has ever paid a dime for the right to slap their face in agony while attempting to deploy this pile of garbage. If only the state of Oregon had asked me first...
> If only the state of Oregon had asked me first...
The main skill of enterprise sales teams sometimes seems to bein making sure no-one who can ask pointed questions is in the rooms where decisions are made.
Typically, in Oracle speak, Webcenter typically refers to Webcenter Content or Webcenter portal, which are products that existed (under a different name?) prior to the Fatwire acquisition. The fatwire product was specially rebranded to 'Webcenter Sites'. From what I understand, from talking to Oracle VARs and consultants, the Sites suite isn't as common as the other two.
Browsing through the PDF, they make references to Webcenter Portal and Webcenter Content, but not Webcenter Sites.
Source: I implemented and supported the largest (in terms of assets and users) (allegedly, according to Oracle) installation of Fatwire as of a year ago. I work on a Portal/Content project now.
I got to Fatwire in your comment, and I laughed my ass off. Maybe I know of people who used it for a CMS, and boy does that continue to be a nightmare.
Let's say this. Someone evaluated all off the shelf CMS options for a large educational org, and somehow the org settled on the only CMS where sales engineers and businessmen have the gall to tell them "well, it is really more of a caching system than a CMS" many months into this project. My oh my did the turd get stinkier and stinker after I heard those tales.
Thanks for clarifying. It all makes sense now.
Oh yeah, and this org, after more than a million wasted, this uses Fatwire. Or whatever they call themselves now.
Well ... I think it's nice to see Oregon state their case so plainly - "Oracle lied to the state of Oregon".
I've see plenty of Oracle disasters, but I think if you're going to rank horrible Oracle products, you should add Application Express to WebCenter and FatWire.
I knew one PeopleSoft project that was in the implementation phase for over a decade - it was a college that was still running part of its payroll system on a HP3000 - the new PeopleSoft system had some issue implementing the complex pay rules for classified staff.
Not made, acquired. WebCenter was acquired. Siebel was acquired. WebLogic was acquired. Java was acquired. The only product they've ever built was their flagship RDBMS which was unbeatable for so long and still fills a niche no one else can really compete with.
> The only product they've ever built was their flagship RDBMS
Which relied on cloning IBM's SQL implementation back in the day. Odd to see them now arguing APIs should be proprietary...
> still fills a niche no one else can really compete with.
Not really true. DB2 will do everything Oracle DB does, and more (12c is only now adding the multitenant capabilities that DB2 has had for a long time). IBM don't do as good a job of marketing it, though.
Even still, it still has some stupid things going on, like what's a VARCHAR2? And having to use an outer query to get ROWNUM to work when there's an ORDER BY clause.
I wish more states would do this to the large vendors that operate this way. Yes, no doubt, states bear some responsibility wrt project management failings, but time after time I hear/read/see sales promises of "this is easy", "yes the product does X", only to find out months later that in fact, no, the product doesn't do X - what they meant was "once you sign an 8 figure contract, we'll assign some junior developers to make it almost do that."
Perhaps this may serve as a turning point for more governments to bring litigation to bear when things go wrong. In many cases, it seems, more money is thrown to the original vendor to fix their own mistakes.
Hehe.minimize cost extends profit margin..
Im myself before stuck in no end project.reason is they want to follow old procedure.for me,i find hard for gov to changed from cash basis accounting to accrual accounting,the old accountant consultant also jerk...suggest nonsense module.
I was under the impression pretty much everyone in CS knew what was up. When I graduated, some people I knew went to Accenture, who billed them out at $350/hour immediately. So you'd have a few dozen "consultants" with little to no experience and one or two people who had been on projects before. I assume all the big consulting companies operate that way.
I'm sure the state of Oregon screwed up, but I have little doubt Oracle was bilking them for every dollar they could get. Whether Oregon can prove this in court will be interesting to see, I assume Oracle will settle at some point, since they wouldn't want everyone to wake up and smell the $$$.
Wait until you have to deal with the gangs of fresh b-school grads a place like McKinsey or Boston Consulting tosses at a problem.
It's almost like a human powered Markov Powerpoint slide Chain...you'll never see so many content-free slides generated so fast.
The best part is that every question about why a group of barely shaving 20 somethings with zero corporate management experience are charging out hundreds to thousands of dollars per hour to "advise" senior C-level staff on how to run their billion dollar companies is answered with "well these are Ivy Leaguers, we only hire the best!"
Meanwhile every 6-12 mo program turns into a scheduled 24 month program that inevitably misses every deadline ever set for it and runs millions of dollars over before producing a barely functional solution that gets scrapped and rebuilt a year later.
I haven't worked for Accenture, but a friend of mine did (not on the software side, but on strategy). These recent grads were referred to as "green beans."
Don't know if this is a general term or what, but I always found it both slightly amusing and slightly terrifying.
I once worked alongsize Accenture on a Siebel integration. They staffed about 100 liberal arts grads who toiled away 80 hours a week like monkeys at typewriters until the system worked. To their credit, it did. They took home $100-200MM filtered through their headquarters in Bermuda, but at least the system existed when they left.
One of my CS friends actually got on there, and he was a capable programmer at the school level. So maybe by sprinkling in a few competent people here and there they get things done. Was very funny, at some point they found out he knew something about C, so they called him in on a project that had been languishing for 6 months with some guy unable to complete it, my friend did whatever in a couple of hours and was the local company hero after that. It's quite possible the jobs they do just need a handful of people and everyone else is just padding the consulting rate.
(A) The trial lawyer's favorite accusation is "they lied!" That's because many jurors and judges won't understand technology; they will understand --- and be inclined to punish --- lying. [1] We see this in the very first paragraphs of Oregon's written pleading.
(B) Software developers should consider some pro-active steps to try to forestall "they lied!" accusations, such as: * providing a written risk-factors disclosure; * including a no-reliance clause in the contract; and * clearly labeling demos, mock-ups, and wire frames as such. These are discussed in the "related posts" linked at [1].
(C) Another example of "they lied" carrying the day: BSkyB Ltd. [Sky Broadcasting] v. HP Enterprise Services UK Ltd. [2], where the court found that EDS (later acquired by HP) misrepresented its ability to do a complex project; that resulted in the contract's limitation-of-liability clause being thrown out, which cost EDS hundreds of millions of dollars extra.
(D) For good measure, here's another example of a state suing over a software project gone bad: Indiana v. IBM [3], where IBM had a contract to overhaul the State of Indiana's system for administering welfare benefits. It didn't go well. IBM basically won in court.
As an Oregon resident watching this mess unfold over the last few years, it seems as if both parties are to blame. The State of Oregon clearly mis-managed the project from their side. On the other hand, Oracle saw this as an opportunity to dump a lot of inexperienced highly-paid consultants on a naive State, and did so. I personally hope that Oregon can recover at least some of my tax dollars that were wasted on this project, but I suspect that won't happen. Oracle probably has better lawyers.
Comedy gold throughout the first 64 pages (at least), particularly if one has worked in a systems integrator before. There are a lot of circumstances where the state poses a requirement, Oracle says "We'll assign this the highest numerical score, but you'll have to build that out" and the state heard "Great, works out of the box."
I am left with the impression that no one in a position of authority in Oregon has ever participated in software development, ever.
Yes it seems Oracle gave itself the highest score, and then redefined what the highest score meant. Then gave themselves a middle score for something else, and redefined what the middle score meant too. That's hilarious actually.
I used to work for Accenture as a technical consultant.
Having read both complaints, I'm on Oracles side more than the Oregons.
On so many big IT projects I would see the client constantly change requirements, be very vague, change stakeholders who then completely move the goal posts and effectively hold the project back for large periods of time.
It's not surprise that large projects fail when you see the state of most large clients.
This highlights a much larger problem. Our processes for delivering large IT projects need a radical change in order to stop toxic stakeholders tanking whole projects.
However, Some of Oracle's products are shit and do fuck all out of the box despite what the sales people say.
I dont know, what you read. But I read, that Oracle shut the door until three months before the scheduled release. Oracle is the specialist on software development and not their client. So if Oracle says not otherwise, they have to deliver. If those allegations are true, Oracle is to blame for the majority.
Or do you want to lead your local bakery in how your breads are made? The baker has to know, when and how to include the client, because he/she is the specialist.
I read the Oracle complaint in full (unlike you). Some of the staff at Oregon were modifying software config on production servers which totally circumvented Oracle release procedures... Oregon would not lock down solid requirements... Stakeholders and requirements would change frequently and existing work would be rendered obsolete.
I've worked with those kind of badly managed clients before. They likely ignored Oracle's advice, came up with nonsense strategies and requirements then kept being vague about the details.
Go and keep turning you bakers over off or requesting crazy ingredients that should never go into mixture (against the bakers advice) and see what kind of bread you get.
Nobody ever got fired for buying Oracle, but some people clearly got swindled (though it's pretty clear that whoever was in charge of project management on the customer side should go).
There have been a number of high profile departures in the departments responsible for Cover Oregon. However there was not a single person who could be said to be responsible for the success of the project; a fact that many ( myself included ) think was one of the reasons the project failed so spectacularly.
Kitzhaber should have appointed one person to be the RP for the overall project, and that person should have had a free hand to define the vendor relationship and delivery metrics.
As a citizen of Oregon, I'm embarrassed; I'm also pretty sure that the essential functionality of the project could have been delivered at a tenth of the cost of this shitshow.
I still cannot bend my head around the idea that a State of the most powerful country on earth should somehow be allowed to reclaim what is to all intents and purposes their mismanagement.
I am sure Oracle (like every large consultant / supplier) over sold their capabilities and stuffed the project with over paid under experienced staff and fed back sweet smelling bullshit to the upper levels. But FFS if the administrators of a whole fucking State do not know this by now, they are the ones to go.
Yes, USGDS is calling the right moves, yes open sourcing reference systems would be a good idea for federal projects but in the end, if you cannot run a software project today, you are going to fuck up everything by 2025. Hospitals, buildings, water pumps, really everything.
Learning these lessons now is a good idea. Thinking "I can still hire Oracle and if they are bad we can take them to court in five years" is not the right lesson to learn.
The above is a UK case where a supplier provided defective software, then was sued and claimed defence behind limitation clauses - it went to the high court which said yeah, you were both big boys, they aren't liable.
The principle I think extends here.
Also - that PDF is incredible - things like "they lied about how flexible and suitable it was for us". Aaaaargh! Can you really sue for "we did not do our homework?!"
> Also - that PDF is incredible - things like "they lied about how flexible and suitable it was for us". Aaaaargh! Can you really sue for "we did not do our homework?!"
So what you seem to be saying, in essence, is that the minimum requirement for government (or perhaps customers in general) is to be perfect, but the acceptable practise for vendors is to be psycopathically dishonest?
Isn't that what caveat emptor means? No it's not to be perfect, it's to basically be part of the great hollowing out - either you buy commodities priced and regulated by the market or you buy to support your core competancies - that's is unless you are great at it, it should be a commodity not a complex contract.
Oregon clearly are not great at software. So they should either become great at it or buy commodity (ie OSS).
The fact there is no OSS solution for them is a problem but Oregon, Wisconsin and so on could club together to dove the problem or let USGDS do it.
For starters, Oregon has less than half the population of Silicon Valley - there just isn't enough talent to draw from to get the in-house expertise the state needs.
On top of that, nobody wants to go work for the Government, and there is a dearth of talent at the state level when it comes to building huge software projects. Perhaps offering high salaries is a start, but the pace of the projects relative to other companies will always be a detractor. Combine that with the scrutiny of the public and constant need to practically over-document things, and you've got a culture that isn't attractive to talented software developers or analysts.
It isn't just that. Private companies pay a lot of bribes, I mean lobbying dollars, to keep the corporate welfare rolling in, and there are many, many citizen groups who gnash their teeth anytime the government "wastes" money by not paying private companies to do its work. There is a lot of motivation to keep shoveling good money after bad toward private companies, and little to change it.
The ELI5 I could glean from it was that Oracle's development and management of the project was pervasively bad, and more importantly that they continually lied and covered up information over the course of the project, misleading the state over the past three years while taking more control over the project whenever they could.
This summarizing statement says it quite succinctly:
"In effect, Oracle used its purported superior expertise, coupled with lies and pressing deadlines, to trap the State and Cover Oregon in a deadly spiral: at each juncture Oracle charged more and Oregon got less."
So this is a consulting services lawsuit, not a product lawsuit. Interesting.
Not to sound insensitive to Oregon, but simply speaking as someone who deals with contracts from major software vendors regularly, I still don't see what legal standing Oregon will have against Oracle.
I saw this because major system integrator's structure their contracts in one of two ways:
(1) Staff Augmentation. This construct clearly states the implementer (e.g. Oracle) is there simply to provide an expert service and no deliverable's are being defined and no responsibility is on the implementer to "complete" any work. You're essentially just paying an hourly rate for an consultant and that consultant is under your direction (as such, 0 liability in on the implementer).
(2) Fixed Fee Deployments. This construct clearly articulates deliverable's and earn-out. Once the implementer successful completes a predefined milestone, the implementer will earn-out a predefined amount. In this construct, the only liability the implementer burdens is the labor to achieve the milestone and typically they can disengage at anytime.
In both contract types, it clearly states the implementer is not responsible for damages, missed deadlines, etc.
So again, I'm curious to know how Oregon is going to win this case.
Oregon's case is that Oracle claimed their products worked together and could be merely configured to suit +95% of the state's requirements. That proved to be untrue. (It always does with COTS software, but it's the siren's call.) On top of that, OCS was incompentent. It's not a staff-aug vs. fixed fee case (and there are many other commercial models in SI land) -- Oregon is alleging straight up fraud and a RICO case.
"Oracle recommended to the State that it hire Oracle’s own internal consulting unit, Oracle Consulting Services, to play the same role."
I'd like to think that, for projects over a certain size, independent systems integrators who are wholly unaffiliated with the winning vendor would be required for project oversight.
This is in fact often the case, but the number of integrators qualified to handle a large Oracle project is not large, and tends to be the usual lists of suspects such as Accenture, Booz Allen Hamilton, etc who are as bad if not worse that Oracle at selling huge consulting contracts and delivering nothing.
This isn't just an Oracle problem - they're obviously over the top in this example, but this seems to be a problem with other vendors as well. I witnessed an example of this in state govt in NC over the last 2 years - loads of promises, under delivered, and as an IT consultant, it was pretty obvious what they were promising was not possible on the time schedule provided. Having tech-knowledgeable external resources to review and look for clarification on muddied points I'd think would be a good thing for the taxpayer and end-users, but they seem to rarely be the focus of these sorts of projects.
Bear in mind that Oracle have tiers of partners. Many of their top-end products have very tight requirements around who can be accredited to work on them and still get support from Oracle for problems. Those partners pay a considerable amount of money to Oracle for the partner program and certification. They are not on your side.
It's ridiculous each state is building it's own solution. The federal government should have created a FOSS flexible platform that each state could customize and contribute back to.
1. "The government is inefficient and doesn't have much experience with big IT projects." We should outsource things to the private sector, like we do the design of bridges and fighter jets.
2. Consultants want to maximise their profit by maximising billable hours. Obviously they don't recommend sharing things between states. Far more profitable to design a shitty 'enterprise grade' mess that will take ages to build, that nobody will compete to maintain, and that will need lots of (billable) maintenance.
3. The project fails, wasting loads of money.
4. People see all this wasted money. They conclude the government is inefficient.
5. People who know how to deliver working software see shitty designs, shitty incentives, and expensive cancellations. They conclude working on government IT projects would be bad for their sanity and their resume.
6. "The government is inefficient and doesn't have much experience with big IT projects."
why should it be top down? that's quite unamerican, in my opinion! one of the numerous cities, counties, and towns of various sizes and locales can develop solutions that may apply outside of their specific jurisdiction.
the very "best" (scalable/widely applicable) solutions are supposed to bubble up. that's the idea behind american federalism!
FOSS is so good for government idk why there isn't more of it, of course having someone to blame for/call when something is not working is what they look for. I wonder if having functional software isn't better.
Sure I think something like Cover Oregon could be an open-source project. The problem is the need for expert management of the project, very much the issue in Oregon: relying on Oracle to manage the project turned out to be an expensive mistake.
Plenty of open source talent in Oregon. I imagine there'd be many volunteers for a big DB/web project. It should be possible to do, after all, would Cover Oregon be more complex than Firefox or the Linux kernel?
In theory, not be all that difficult to hire a good project management team, set up the framework and let contributors work on it. Probably get done much quicker and of course, at way less cost.
Of course, doing that is taking a risk which is routinely avoided by timid bureaucrats and enterprises. Though the lesson of Oregon's experience is there to be learned--it shows the far bigger risks of doing things the same old way.
You can hire private corporations and even pay large sums of money (like 1/100th of this is a very big sum) with a proviso that all the code be published under some Free license. This is not advocating self-organizing cat herding with multiple entities donating developer time.
Hire bigco, publish what they give you so the neighbours can also use it and you're not stuck with bigco for support.
ie you can also fire bigco if they suck once you hired them.
An interesting idea, a kind of gradually-open model of participation. Could work if the source or (selected part of it) is incrementally released from time to time, so at least there's opportunity for open participation if in a more structured manner. Ultimately, the entire source is made available, but by then it works according to specs and has been constructed sanely.
Maybe my interpretation of your idea wouldn't work exactly as you has in mind, but I see your point, that maintaining greater control of the development process would likely lead to a more coherent and predictable product that functions in accordance with carefully designed specs.
Among flies in the ointment is the necessity for such a highly principled and skilled steering group to manage the effort with the requisite wisdom around scheduling releases and titrating the level of community involvement. The level of talent it implies is likely in short supply.
That said, an admiral proposal, distinctly possible, even revolutionary. To quote Spinoza, "all things excellent are as difficult as they are rare".
No. I'm not being clear.
Hire eg IBM global services to build you the solution. In the contract it states clearly, part of the deliverable is the source code that will be published under xyz license. Whether you hire IBM, Oracle, Accenture etc or do something a lot less moronic you insist on source and insist on being assigned the copyright to it and you publish it. Every time. Always.
That's the step forward I am suggesting. Not the linux kernel model of development. If such a thing arose for particular projects, great. But it's not a requirement nor the goal.
they should be able to for things like this, it's a grotesque waste of money for states to build their own system. It would be as insane as each state having it's own army or space program.
it is absolutely ridiculous, they (the federal government) could have (did) build their own system and then host it for each of the states. Better still, host it in the ones where electricity can be generated cheaply. This is whole reason we have a federal system.
I usually don't read those, for fear of being drowned in legalese. Turns out, the first few pages are written in plain, readable English. (I expect this is true of most of the rest as well.)
I did not read the whole document, but I believe the first few pages are… unforgiving to say the least. I could already hear the heads rolling.
They represent missing content. Similar in usage to ellipsis, but might indicate a larger text missing. Afaik, not redacted text, but edited down to contain only the main information.
One of my favorite quotes in the "Issues" section is the trouble the Army was having trying to adapt their personnel policies into standard PeopleSoft actions, with a contractor developer eventually claiming to the Army "you guys (Army SMEs) just don't know how to properly manage people...".
Perhaps, but somehow I doubt that the same exact methods suitable for personnel management for civilians is always applicable to the Army.
That was by far not the only problem; the Navy actually uses PeopleSoft for its military personnel management nowadays (presumably they found developers more willing to modify PeopleSoft).
and the DoD is only one government department. This is really well replicated.
There's gold in washington available for ramming your blood funnel in anything that smells like money.
Unfortunately when governments get "big business is better" religion things tend to go pear-shaped. In my neck of the woods a change of government led to a change in procurement policies for IT. "We won't engage with any company without experience running $100 million+ projects for any government contract and they need offices in at least three countries."
This is a great way of making sure only EDS (sorry, HP), IBM, and the other usual suspects are the only ones who can do work. Not the best use of my tax dollars.
One developer experienced in Oracle products called Oracle’s programming “atrocious.” He added that “they broke every single best practice that Oracle themselves have defined. It is one of the worst assessments I have performed * * .” The same developer wrote to Oracle, “You are Oracle people, working on an Oracle hardware platform, with Oracle technology products, on an Oracle solution. * * Oracle should be delivering these environments and products as a solution, like they actually understood the products and owned the solution which has not been the case by a long shot.”
AND
Oracle’s responses to the Vendor Questionnaire also stated that OPA and Siebel, the foundation of the “Oracle Solution,” could be implemented by business analysts, not software developers, and without customization. Oracle explained that “government subject matter experts (not application developers)” could define rules in OPA “in the terms and vocabulary that they are familiar with and/or as defined in relevant statute, regulations and policy documents. * * * There is no scripting or programming needed.”