Looks to me like an overzealous lawyer at Oracle. There are plenty of 3rd party reference sites for the Oracle database that don't get shut down, why target a JDE reference?
Unless they really-really think their docs are superior? (Oracle's docs for Middleware or Database usually are world-class, though I am not familiar if this is true for JDE).
Oracle wants to push Peoplesoft. I think the bought JDE mostly to have a ready source of new customers. There are two product lines in JDE, World and OneWorld. World is based on minis (IBM i) and OneWorld is more PC/Server oriented (good for smaller customers). Peoplesoft is mostly AIX/Oracle and very people intensive and better yet, consultant friendly and a great revenue stream.
So, yeah, shutting down a site which promotes software not a the top of their list makes sense.
This is not true, JDE brings in WAY more revenue than Peoplesoft does for Oracle. When PeopleSoft purchased JDE originally they wanted to kill JDE, but after Oracle bought PeopleSoft they realized they could keep it alive and make a profit on it.
Tangential question: how do I learn about ERP software? I went to a strong CS school but this wasn't covered. I don't think I even know anyone who knows this stuff.
It's hardly surprising that ERP systems aren't covered in a CS course - they are primarily about business processes and concepts.
Having said that, ERPs systems are arguably mainly accounting systems with a lot (and I really do mean a lot) of additional functionality bolted on, so learning the basics of accounting wouldn't do any harm.
I count at least 4 different kinds of organizations that work with ERPs:
- The vendors who write them (Oracle, SAP, Microsoft and loads of others)
- Vendors who write packages that integrate with ERP systems (again loads of these - e. for reporting/data warehousing, document management, bar-code handling)
- People who work for professional services companies that help customer implement ERP systems - often implementing custom code in the platform for the ERP system (often in programming languages and environments that are specific to that ERP product!)
- Customer organizations
For a developer, I would aim for one of the first two although the professional services side of things can be pretty lucrative.
And best of luck getting a demo system to try to learn on if you aren't a part of a big company. SAP has a few demo systems, but you can't put it on your own computer to understand.
Microsoft can give you a VM with a working instance of Dynamics AX 2012 and the underlying SQL 2012 database - it's quite big and needs a fair bit of RAM (I needed 48GB) but it does work pretty well.
Having said that, I think SAP is rather more complex than AX.
It would be the overall scope of trying to install your own system to learn it. It's a massive base product, you can certainly install it but trying to run your own test environment would be a pain without the knowledge of running a business through an ERP or the necessary test data. Typically you learn the business side of things 'on the job' and come into it with a development back ground.
ERP software is often highly customised for individual businesses and their processes. There are commonalities across packages (JDE, PeopleSoft, SAP, Dynamics, etc) but for the most part they're different for each organisation. That's why ERP consultants can charge such high fees. Your SAP install is quite different from your rival's.
They often integrate with external systems (stock management, production equipment, third party accounting platforms, billing, user management), even when the ERP system itself offers functionality in a given area.
It's a huge subject area.
However, most ERP software itself is just a large CRUD application that calls out to third party services (via APIs, COM, libraries, etc).
If you really want to learn about ERP software, try go get a job working with it for a year or two. The technical knowledge you'll require to get such a position is fairly generic (database basics, user experience design, TCP/IP, Unix/Linux server management). What would really make you stand out as a candidate would be having an understanding of business process modelling and reengineering - that's all ERP software is, a mirror of business processes.
It's an interesting area to work in (perhaps not long-term unless you're really into the BPR side of things). You'll really understand how businesses work and how they see their processes. And when you're working at the enterprise scale, small improvements in the software people use daily to perform their main functions can make all the difference.
Source: I've build ERP software for the last 7+ yrs.
Full Disclosure - I'm working at company going through a huge ERP change from one vendor to JDE.
I was told by our .Net developers that JDE is for business analysts so they can do the same thing as developers without writing any code. I've only done a few minor things in JDE, but it seems very "mouse intensive". Lots of clicking this and that, joining this table to that table, looking up this record, etc.
Is this true of most ERP software, or just in the case of JDE?
There's been a shift over the years towards end user workflow-based visual programming and report generation (something many traditional ERP systems left to tools like Crystal Reports).
There are limitations to what can be accomplished in that sort of end user programming (wouldn't enjoy integrating with an arbitrary third party service, for example).
However this tends to run parallel to the regular scripting and COM/CORBA/DLL interfaces.
I must admit that the system I've worked with most recently doesn't offer any sort of end user programming or report generation, and I miss this badly. Those facilities, while basic, really lessen the burden on software engineers and allow us to focus on the more difficult tasks which deliver the most business value.
I'm working in-house (not consulting) so would much rather see our end users creating their own reports than have to, for example, put a new supplier integration module on hold in order to have a developer pull together a critical sales report.
In many deployments, I've seen not only business analysts take advantage of a simple programmable environment but also departmental power users. It's not uncommon in some larger organisations to find sales staff writing their own reports or finance professionals scripting integration with spreadsheets (yes, spreadsheets and ERP systems usually do co-exist really comfortably!). This usually depends on sensible RBAC and a well designed schema, to keep users from making damaging mistakes.
So to answer your question (I think) - most good ERP software will offer a balance between end user programming/reporting and integration features aimed at full time developers.
It depends on what you are doing in JDE really. There are several development tools, some that are easy for people with no technical experience (you mouse intensive development) but there is also tools that require a strong base of C or Java. It's fairly flexible. (Im a 15+ year JDE developer and sysadmin)
Go work for a consulting company like Accenture for a year or two. They'll pay you immensely, send you through training, send you around the country/world and burn you out after 24 months.
ERP Consultant here - of course experience is key - so to get your foot in the door, couple ways I would approach it. Your pitch ultimately needs to be, I'm THE guy for this single app, very focused and specific skill.
I would get hired at a company as a general dev or whatever and then try to transition to to a sys admin role (like "JDE Administrator"). Alot of guys work with me (me too) got in this way.
Get a year or two experience and then go be a contractor - just search for JDE contractor jobs. Or, get hired on full-time at one of the many small consulting firms that specialize in the app you're targeting.
You can come in with less experience if you can accept less salary, like at a full-time salary at a consulting co. if you can come in at 80-90k salary, that's low. I know guys got on with just minimal experience. Trust me on this, if you're smart, you'll pick up the skills.
It makes sense that it wasn't covered. Its really specific to a non-CS domain (Business). You probably learned image-processing techniques, but not how to use photoshop. You might have learned how to use acid-compliant databases, not how to use quickbooks.
Designers might have classes on how to use photoshop. Accountants might have classes on how to use quickbooks.
You might find a business-related class that covers ERP-related topics?
While you may know what ERP stands for, you're missing the bigger picture on what modern ERPs do. They aren't specific to a domain--they do everything from managing manufacturing processes to keeping the books for retailers. I've seen specific ERPs written for dairy distributors used by ice makers. Planning is just one part of an ERP. The General Ledger, WIP, logisitics, customer lists, etc, etc all can and do go into ERPs.
Moreover, folks that are experts on an ERP typically are an expert either on (a) one type of ERP (e.g.-SAP), or (b) ERPs for a specific domain (e.g.-manufacturing). You don't typically get somebody who knows many different ERPs across many different businesses. During an ERP implementation, you'll usually hire one of type A, and one of type B, and then a whole team of developers/implementers.
Each vendor gives extensive training on all sorts of different aspects of their ERPs, but really, if you'd like to get a handle on what they do, you need to know how enterprises work. And the only way you're going to do that is by working in an enterprise. I've had my exposure to ERPs by building data warehouses that have to read and interact with them. But, my college degree's in management and economics, so things like accounting and business processes were already something I had passing familiarity with. ERPs will make little to no sense if you don't understand how corproate accounting works.
ERPs are wildly complex, and each has about 1000 different packages that you can use to do...I don't even know half of what they do. The best way to get some familiarity with ERPs is to get hired in some place where they'll teach you all about it. This includes training in the classroom and on the job. These are typically consulting firms--there are a few big ones, and there are a few boutique ones that do only ERPs. Also, the vendors typically have implementation teams, so you may want to do that, as well. I will note that ERP implementers almost always are required to travel extensively, so if somebody reading this wants to go into it as a career, understand what you're getting into. Travel is insanely lucrative if you don't mind it, but if you have a family or other commitments, it can tear you apart.
>While you may know what ERP stands for, you're missing the bigger picture on what modern ERPs do.
I think his point was that ERPs are specific proprietary applications that are not used as tools for programming, and wouldn't ever show up in any CS curriculum. I didn't see any statement on what ERPs are capable of doing.
>But, my college degree's in management and economics, so things like accounting and business processes were already something I had passing familiarity with. ERPs will make little to no sense if you don't understand how corproate accounting works.
>You might find a business-related class that covers ERP-related topics?
I'm not sure why your response was framed like a disagreement.
My intent was to expand upon the idea that it's only a business tool, and direct somebody looking to get into ERPs on how to get educated in them. Taking a course related to ERPs, or for a business user, will get you not very far if you want to do things on the technical side. This is why I mentioned training, career paths, and how I became familiar with them.
The only thing I disagreed with the parent about was that I don't consider ERPs to be a "specific domain," anymore than "all of the businesses in the world" is a "specific domain." My intent was to explain to a layman that ERPs manage a ton of different processes, and that they are very complex applications with many different options.
Apparently, I have failed to do that. So, sincerely, all apologies.
Beyond that, you'll find textbooks on the topic as well. Courses on ERP (and related topics like MRP) are usually found in degree programs with names like "Management Information Systems" or something, not "Computer Science".
I'm not 100% sure I'd actually recommend anybody deploy OFBiz for a real business, but if you wanted to play around and get a feel for some of the concepts, it could be a useful starting point.
Finally, if you want to drink from a firehose, you could do something like this:
It isn't something you really want to know about. PeopleSoft is horrendous at the last large organization I worked for I'm fairly certain that a number of good employees quit based in part on being forced to use the PeopleSoft implementation for many basic HR and Administrative tasks like performance reviews.
Strictly speaking, ERP aligns more with MIS than CS. Moreover, ERP would be challenging to learn in a vendor-independent manner, which good or bad, is the way most CS courses are structured.
Since it is highly unlikely that Larry Ellison was in any way involved in these decisions within Oracle, however, it adds nothing to our understanding or interpretation of these events. Instead of broadening the context it replaces it with raw ad hominem.
Even if he's not involved in this particular decision, he certainly sets the tone with which Oracle treats with third party (users, developers, competitors, etc...)
By that logic, he also is responsible for making software that people want and for those people wanting it because using it is profitable. Oracle is hardly the only company in Silicon Valley, much less the world, known for ruthlessly pursuing intellectual property claims [it's hardly the only company in the valley with a reputation for requiring developers to dance to its tune, either].
It's not that I am greatly concerned that Larry Ellison's feelings will be hurt. What I care about is that the post is a template for the sort of comments which debase HN's discussions. It's mean for the sake of internet points, and nobody is better informed or inspired to deeper insight for having read it.
The meanness and shallowness of such posts only invites more meanness and shallowness. There are lots of other places on the internet where that provides the majority of entertainment value. It's not why people come to HN.
>Oracle is hardly the only company in Silicon Valley, much less the world, known for ruthlessly pursuing intellectual property claims [it's hardly the only company in the valley with a reputation for requiring developers to dance to its tune, either].
Does a company have to be the only exemplar of a bad behavior for it to be pointed out? That's a very hard standard to meet that would suppress any discussion of corporate decisions.
I found some of the reactions on hn and slashdot way more insightful than the blog post itself, which to me is half euphemism, half strawman, and 100% condescending.
There are 2 types of programmers... Programmer that 100% embrace MS using the .NET Stack, Visual Studio, and outlaying the Tens of Thousands of Dollars need to support that development model
And programmers that want to use Open Source/Open Standards... The Open Source/open Standards programmers hate MS because they MS views Open Source has a threat and the enemy (although they are starting to be less hostile over the last couple years)
Yes. And they haven't changed. See their slimy Android extortion techniques which taxes millions of smartphones based on some highly questionable patents and also their recent FUD-based ad campaigns.
Yeah, I love MS. I hate their licensing (too complex), and think they've not had a spotless track record, but compared to Oracle and Apple they're definitely in the good guys camp.
for ["Microsoft", "Oracle"]
{print "We hateses ~a. \n
Dirty nasty stinking ~a took our precious."}
In days of yore, the big three personalities were Gates, Jobs, and Ellison because those with an interest in creating lists of villains and heroes were inclined to hedge there bets - Gates alone might not be enough a villain for their shining knight. But then, and even more so now, Oracle and Ellison never had enough popular culture mindshare to make the Slam Books of those who keep slam books but for a narrow segment of an echoing technical community much of which didn't like Java when it still lived under Sun, anyway.
Because this is Oracle we are talking about, I am not sure if you are being sarcastic. But just in case you are not, my experience with Oracle is quite the opposite of what you describe. Oracle is sold on the golf course, and they exist purely for profit. Most Oracle consultants I know (quite a few) who actually develop software using the tools, gladly admit they work with Oracle because they can charge high fees. In fact, if I asked them their opinion on this specific incident they might actually approve - given the end result is that their knowledge is safe from newcomers.
I know it's a pretty popular view to skewer Oracle, considering how much money they make from licensing and how little they seem to do.
From the other side, I work at a medium-sized consultancy that handles Oracle databases as well as other products. I work with open source, big data technologies (Hadoop, Mongo, Cassandra), and I talk to some of our top Oracle guys sometimes. Oracle does everything, and it does it damn-near automatically - look at the concepts guide (http://docs.oracle.com/cd/E11882_01/server.112/e40540.pdf) if you want to see how many types of JOIN an Oracle DB can choose from. Exadata has more, I think, and half the performance stuff isn't even documented, it's just buried in query plans. I'll tell an Oracle guy, "hey, we just got hash-bucket joins", or skip scans, or some other enhancement, and it's like the OSS competition is still in the 90s compared to what Oracle can do.
You can complain that Oracle charges a lot of money, but in a lot of cases it's NIH syndrone. Drop in Postgres instead, then spend 6 months tuning it, or spend the difference buying extra hardware to scale out. Roll your own ERP, and forever have a small dev team of 4 guys who cost you half a million dollars to support it, because you didn't want to buy off-the-shelf, because your pride as a developer stops you from learning someone else's tool.
I spent many years bashing Oracle. Sometimes it's for the pain of the installer being different to deploying open source software, other times it's for the bill the company had to pay to Oracle. Then I actually started working with the database product, and this was to use Oracle to be a warehouse for MongoDB data. The experience has made me fairly positive of the Oracle product, fairly keen to avoid MongoDB in general, and has also spoiled my experience of MySQL and Postgres since because of features I've been spoilt with.
For me, it's mostly performance features: Last time I checked, Postgres' query planning was based only on the rather configurable, yet completely static stats tables and a few config parameters, and it didn't care very much about its experience running queries. So if for some reason I can't add quite enough stats gathering, and I know a often used query is still slow, my only choice to fix it is to do some really terrifying things to the code so that the join order is dictated by the query.
In Oracle, not only is the DB going to actually look at the query's real performance by itself, but i can just tell it to change the way it runs at runtime, if all else fails.
There's also data warehousing tricks that, AFAIK, Postgres does not support. In Oracle, if I have a star pattern, I can make the queries run without actually touching the fact table, only querying indices.
That said, exadata is voodoo, compared to how much more predictable Postgres' behavior is. But there really is a case for it if you really are building the DB equivalent of the Titanic.
> and forever have a small dev team of 4 guys who cost you half a million dollars to support it
You lose me there. Don't tell me I won't need people to run my Oracle databases. Moreover, I'll need "Oracle" people, who earn 2x what those other 4 guys earn.
I think gp's numbers are off. But for sure, if you need ERP anywhere near the scale of what Oracle offers, it'll definitely cost more in the long- and short-runs to ROYO.
This is sadly true for most proprietary IT. What would be the solution? A rigid code of ethics that would prevent IT executives from meeting their vendors outside the office?
I once worked for a company that had its CTO fired because he accepted a trip to Paris (so he could speak at a vendor-sponsored event), but only after buying a couple million dollars of inadequate and overly expensive hardware. Now he's a senior exec at said vendor.
Hint to senior IT execs: if one of your providers names you "Executive of the Year", watch out: it's probably because you are their most profitable cash cow.
>This is sadly true for most proprietary IT. What would be the solution?
Not a solution, but I think this is in the right direction:
A business model in which IT execs with purchasing power have a vested interest in seeing the business succeed -- either financially or from an purely-engineering perspective. I believe the first point speaks to itself. The second, while it aligns with my bias that engineers make better tech execs (the engineer that 'works his way up' comes with perspective, knowledge, and wisdom), I still believe that engineers look after each other and at least know when they're fucking over the next guy for some wine or a couple days in a different city.
Unfortunately, this is my only suggestion because it's hard to do an ethics-test that's relevant and it's reasonably difficult to fire execs that you know aren't honor-bound.
>A rigid code of ethics that would prevent IT executives from meeting their vendors outside the office?
I've been taken out for drinks by vendors trying to close a deal. None have yet. When I grow a personal business to the point of free trips, there's a chance I'll take those if they don't interfere with my performance or come with a moral price-tag.
Which is to say, there's nothing inherently wrong with meeting salespeople outside of the office -- it's a just a conversation and "practice business." If the vendor is selling something interesting, who knows, maybe it's worth comparing against your current solution.
This is somewhat of a cherry-picked hypothetical anecdote, but I wouldn't choose any solution that makes for pissed-off engineers or burns money.
>I once worked for a company that had its CTO fired because he accepted a trip to Paris (so he could speak at a vendor-sponsored event), but only after buying a couple million dollars of inadequate and overly expensive hardware.
That's just corruption and lack of oversight. I realize that at some point, you have to trust the decisions of your CTO, but if he doesn't have significant skin in the game (and a couple million dollars isn't chump change to the company), this purchase order should have triggered a review of the proposal.
I think you just described most corporations. Despite the PR otherwise, they're all rotten to the core like this.
However in this specific case, if Mozilla issued a takedown to w3schools, would we be up in arms about it? Vendors are generally pretty tight with documentation when it's a cut-throat sector.
Doesn't help that their own website is barely Web 1.0. It's damned near impossible to find anything in their documentation unless you've already memorized all the hoops you need to jump through.
asktom.oracle.com is something of a gem within that site. The navigation isn't great but there's a lot of good "how to" questions and answers there. I found it very helpful when I was working with Oracle. Also I recommend Tom Kyte's books. He's definitely an Oracle evangelist, but he knows what he's talking about.
You must be joking, of course. The people who'd need to access documentation are not the ones that sign the check. Oracle's client is not the company, their IT staff, not even their internal users. Oracle's client, the one they cultivate a relationship with, is the executive (IT or non-IT, it doesn't matter) authorized to sign seven-figure checks for licenses and services.
I'm not sure if you've ever worked with Oracle, but they have a long history of making it hard for customers since a good proportion of their income comes from consultants.
Quite honestly, they're one of the worst anti-user companies ever.
Shouldn't it be "the best anti-user company"? Otherwise it sounds like the company being worst at enforcing anti-user policy, i.e. failing to do it right, i.e. being user-friendly after all.
Even better would be: "the most user-unfriendly company".
How about "the most user-unfriendly company you can keep are those that express pedanticism over points they've demonstrated they have understood regardless" :p
But joking aside, I was wondering whether to say 'best' or 'worst'; I didn't even think of saying 'most'.
I think this will not affect they reputation in any way. Solaris and MySQL stories are good proof that Oracle isn't about reputation, from perspective of market that they are targeting they are doing right thing.
Oracle's JD Edwards EnterpriseOne is an integrated applications suite of comprehensive enterprise resource planning software that combines business value, standards-based technology, and deep industry experience into a business solution with a low total cost of ownership.
Essentially, an ERP and set of buzzword-bingo cards in the same box.
an integrated applications suite = bunch of software interfaces for...
of comprehensive enterprise resource planning software = your business purchasing and maintenance problems
that combines business value = giving you the most bang for your buck,
standards-based technology = not sure about this one... can be tweaked by your IT department OR helps you select products/services that meet regulatory standards so that you won't get sued for cutting corners
deep industry experience = nobody got fired for picking something everyone uses
into a business solution = we will unpack and assemble it for you, but you should really buy the Gold Support Package or budget a lot more for your IT department, because it isn't compatible with anything else
with a low total cost of ownership = we make most of our money on the Gold Support Package, but will let you fool yourself into thinking that you won't need it.
JDE has a consistent, logical, and totally infuriating table and column naming convention that's a holdover from its System/34 days, so that you're always having to select GLAA from F0911 and so on.
Worse yet, the system doesn't store human-readable descriptions in a consistent manner, so you have to do half a dozen joins just to get to the object names. So JDERef would have provided a valuable service to anyone who needs to talk to a JDE database -- without a handy schema reference, it's just a pile of characters.
Roughly 5,000, as I recall (JDE was only tangentially related to my world). I think about 1,500 of those map to specific system objects.
There's also various naming conventions for other objects; user-defined value lists have terse names like "UDC 98/SY" (which is, I think, the value list of value lists, or some such), batch routines have names like "R09430," and so on. It's all horribly brain-deadening, and the cognitive barrier to entry is extremely high. Evidently ORCL likes it that way.
Hundreds, depending on the packages used by the customer. The good news is that the names never changed, so you could write a third-party add-on to it and it would always work. I know of a company that wrote a plug-and-play data warehouse for only JDE customers.
I get annoyed when people let bad actors off the hood by obscuring their names with asterisks. We know who the overall "bad guy" is in this scenario, but right up until the whole asterisk thing, we had a person whom we could point to and request or demand an explanation from.
Then, it would be on them to pass the buck, call the police, whatever.
well, OK. I guess I should cease and desist from complimenting the Oracle DB. it is a great product, though it did always seem that they deliberately obfuscate documentation and make friendly tools and resources unavailable just to feed their army of dependent consultants.
BTW, I suppose Postgres is a perfectly adequate replacement?
BTW, I suppose Postgres is a perfectly adequate replacement?
If you're starting from zero, don't have any too obscure or extreme requirements and don't have to integrate with third party tools that don't support Postgres, then absolutely.
However if you already have a large Oracle based codebase and/or have to talk to third party apps that don't support Postgres then your migration costs can quickly swamp your license costs.
Postgres would be an adequate replacement for Oracle in many cases, or the enhanced EnterpriseDB which is not free but is less expensive. At the very high end, if you need what Oracle is capable of, not much else can replace it.
Oracle's M.O. is to pushing their newer product lines and preventing customers from keeping their investments (i.e., Fusion and surprisingly, still Peoplesoft).
While this is a business-as-usual dick move, it's also completely expected - see their legal actions against the TomorrowNow[1] organization purchased by SAP, and their now-infamous legal attacks against Google for independently implementing a JVM byte code interpreter.
There is no reason any site should shut down like this, if it is in fact a very valuable resource. The owner could/should just move the site to a tor hidden service. At very least offer up a dump of the data so someone else could run with it.
Unless they really-really think their docs are superior? (Oracle's docs for Middleware or Database usually are world-class, though I am not familiar if this is true for JDE).