Notes on Scale

Because Peter's original question specifically asked for module counts, transaction-code counts, and table counts, it's worth being precise about what is and is not publicly knowable:

• Modules: DoD program documentation reliably describes systems in terms of functional business-process areas (7 for DAI; 9 for Navy ERP; 9 Army GFEBS process areas) rather than raw SAP/Oracle “module” counts, because a single business-process area typically draws on several underlying SAP modules (FI, CO, MM, PM, PS, SD, HCM) configured together. This paper reports the officially documented process-area counts above rather than inventing a module tally that no DoD source publishes.
• Transaction codes (T-codes): SAP ECC as a base commercial product ships with on the order of 100,000+ transaction codes across all possible industry configurations; any single DoD deployment (GFEBS, Navy ERP, GCSS-Army, LMP) uses a configured operational subset, generally organized around role-based access (GFEBS documentation cites 150+ distinct user roles, each scoped to a specific T-code set). No GFEBS-, Navy ERP-, GCSS-Army-, or LMP-specific T-code count is published in unclassified open sources.
• Data tables: the same logic applies — SAP's standard data dictionary spans tens of thousands of tables (e.g., BKPF/BSEG for FI documents, COEP for CO line items, EKKO/EKPO for purchasing) before any Z-table customization; DoD deployments add Service-specific extension tables (for SFIS chart-of-accounts elements, real property, etc.) that are not separately enumerated in public documentation.
• Where hard numbers do exist in the record, they describe migration/reconciliation scale rather than system architecture — for example, the SPAWAR-to-Navy ERP conversion validated 20,195 general ledger accounts across 568 trial balances for 14 appropriations, and GFEBS's 2007 SAFE study catalogued 198 legacy Army systems assessed for consolidation.