Oracle kills third-party JD Edwards reference website
jderef.com
jderef.com
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).
So, yeah, shutting down a site which promotes software not a the top of their list makes sense.
- regular HN reader.
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.
Having said that, I think SAP is rather more complex than AX.
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?
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.
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.
They were being pedantic about something in the original post, so I edited the post so the actual point wasn't lost.
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.
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.
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 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.
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.
http://en.wikipedia.org/wiki/Enterprise_resource_planning
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".
http://www.amazon.com/Enterprise-Resource-Planning-Bret-Wagn...
http://www.amazon.com/Concepts-Enterprise-Resource-Planning-...
If you wanted to get your hands dirty, there are some open source ERP systems out there. One well known one is OFBiz, which is now an Apache project:
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:
https://www.google.com/search?q=%22enterprise+resource+plann...
After that, you'll know ERP software.
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.
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.
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.
There's an interesting article about this by Scott Hanselman titled "Microsoft Killed My Pappy": http://www.hanselman.com/blog/MicrosoftKilledMyPappy.aspx
https://news.ycombinator.com/item?id=7281283
http://yro.slashdot.org/story/14/02/23/1628259/microsoft-kil...
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)
for ["Microsoft", "Oracle"]
{print "We hateses ~a. \n
Dirty nasty stinking ~a took our precious."}
"Oracle and Ellison never had enough popular culture mindshare to make the Slam Books"
I suspect with countless billions he doesn't much give a damn about your "slam book"
The opposite of love is not hate. It's apathy.
All this is anecdotal of course - but this is a good talk that gives a pretty nice perspective on the whole thing: http://www.youtube.com/watch?v=-zRN7XLCRhc&feature=player_de...
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.
Yes, yes we would.
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.
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.
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.
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.
Most complaints I've seen relate to stuff like this. Bad customer service and destructive behavior.
> 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.
Quite honestly, they're one of the worst anti-user companies ever.
Even better would be: "the most user-unfriendly company".
But joking aside, I was wondering whether to say 'best' or 'worst'; I didn't even think of saying 'most'.
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.
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.
Isn't that redundant? ERPs always come with buzzword-bingo sets, its like a defining feature of the product class.
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.
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.
Then, it would be on them to pass the buck, call the police, whatever.
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.
Good work Oracle.
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.