When I started designing Enterprise Data Models about 10 years ago they had lots and lots of Entities, (usually around 50 or more) and were understandable only by other Data Modellers and with great difficulty.
Over the last 5 years, I have favoured an approach that has a Top-Level Model with a number of Subject Areas - not more than ten.
The objective of the Top-Level Model is to establish communication with senior management.
This Top-Level EDM is then the starting-point for creation of an EDM for each Subject Area.
Hopefully it doesn't look like an ER model. In my personal experience, over-reliance on ER diagrams and related techniques is largely to blame for the failure of many (possibly even most?) data models. By "failure" I mean models that satisfy the data architects but are incomprehensible to business customers and irrelevant or too late for the developers.
I much prefer ORM (NOTE: never to be confused with O/RM)
Here is an example for Investment Banking on my Database Answers Web Site
Accounts have "account_id" but not an account number? What are the business keys in the other tables? If the business owner / domain expert can't work out what identifies each fact in the business process then she can't honestly tell you whether the model is correct or not. Neither can anyone else.