Personally I don't think anything beats just slogging through the code and learning it. There is not quick way to understand. When I go to a new job, I spend a week, doing almost nothing but understanding the design of the database (I'm a database specialist). If diagrams don't exist, I make them. I track things through from the top level of the queries all the way to the tables. I ask questions when something doesn't make sense. I look for the most critical of the queries to understand first (usually the search queries, they will give you a really good idea of the most important tables.). If possible get someone with some expertise to sit down with me for a good half a day and show me what he knows.
Since you are way past your first week (when it is easier to get this time) this is harder. But start with one module you have worked on or are getting ready to work on and read the code, following the paths in the code until you have gone down to the lowest level. Make notes. Make diagrams if you need to. Just work through one section at a time, but go through it thoroughly. Try to find someone who worked on the design to understand the design choices. Often they chose what was best at the time they did the design but something which five years later looks pretty awful to you. It helps to understand the constraints that caused the design to be the way it is.
Enterprise applications tend to be heavily database centric. Make sure to take the time to understand the database design as well as the structure of the application.
Are there requirements documents from the orginal design on out? Take the time to read some of them.
It is never easy to understand a large Enterprise system. There are alot of different little designs at different time periods involved in it so there is often very little consistency. It is likely that no one on the team understands the whole system completely. If you do have someone who is the acknowldeged expert in the system, listen to him or her very carefully, ask lots of questions, ask why they made the choices they did. BUt do it respectfully, nothing will shut the expert onteh system up faster than asking questions in a way that makes them feel defensive. While you may or may not agree with all the choices they made (about a 100% chance you won't agree with all of them in my experience) at least understanding the whys helps you start to see the pattern of how this group of people approach design which will clue you in to how they did the next thing you look at as well.