Definition Project-centric ERP architecture is a system design approach that organises all data models, transaction flows, business logic, and reporting structures around the project as the primary entity. In this architecture, the project is not an attribute attached to financial transactions—it is the core object from which all other structures derive meaning and context. In project-centric architecture: Data models are designed with project as the root entity, with Bill of Quantities (BoQ), Work Breakdown Structure (WBS), and cost codes as native structures Transactions are captured in project context from origination, not tagged with project codes as an afterthought Business logic enforces project-based controls—budget checks, commitment tracking, progress validation—at transaction time Reporting provides project-lifecycle visibility by default, with financial period views derived rather than primary This stands in contrast to finance-centric architecture—the design approach of generic ERPs—where the general ledger is the core, projects are subsidiary ledgers or dimensions, and project visibility requires aggregation and reconciliation of financial data. The architectural distinction is not cosmetic. It determines what questions the system can answer natively, what controls can be enforced automatically, and what visibility is available without manual intervention. Project-based businesses require project-centric architecture because their economic unit is the project, not the product, the period, or the department. Context in Project-Based Industries Architecture matters because it determines what is easy and what is hard—what the system does naturally and what requires workarounds. In construction, project-centric architecture enables contractors to manage scope through BoQ, organise work through WBS, and classify costs through cost codes as integrated, native functions. Progress measurement, interim valuations, variation management, and final account reconciliation flow naturally from project-centric data structures. Finance-centric systems require these capabilities to be bolted on, integrated externally, or managed through spreadsheets. In marine and offshore, project-centric architecture supports the phased, multi-location nature of offshore execution. A platform project spanning engineering offices, multiple fabrication yards, and offshore installation can be managed as a single project entity with visibility across all locations and phases. Finance-centric systems fragment this visibility across cost centres and legal entities. In shipbuilding, project-centric architecture aligns with the vessel as the economic unit. Each ship is a project with its own BoQ equivalent (priced specification), WBS (block and zone structure), and cost accumulation. Production planning, material procurement, and progress measurement all reference the vessel project. Finance-centric systems designed for repetitive manufacturing cannot model this project-based production. In mining, project-centric architecture supports the multi-year, multi-discipline nature of mining development. A mine development project spans feasibility, engineering, procurement, construction, and commissioning—potentially over a decade. Project-centric architecture maintains continuity across this lifecycle; finance-centric systems that reset annually lose project context. In project-based manufacturing, project-centric architecture enables engineered-to-order production control. Each customer order is a project with unique specifications, cost tracking, and delivery milestones. Project-centric systems manage this complexity; generic manufacturing ERPs assume repetitive production. Architecture as Competitive Infrastructure For project-based organisations, ERP architecture is not a technical decision—it is competitive infrastructure. Organisations with project-centric systems can: Detect cost deviations earlier and respond faster Value variations accurately and substantiate claims Forecast outcomes with greater precision Report to stakeholders with confidence Learn from projects and improve estimating Organisations fighting finance-centric systems spend effort on data reconciliation, manual workarounds, and spreadsheet maintenance—effort that does not create value and may mask problems until they become crises. Why This Concept Exists Project-centric ERP architecture exists because the fundamental design of generic ERP systems conflicts with the operational requirements of project-based industries. Generic ERPs evolved from manufacturing and distribution. The major ERP platforms—SAP, Oracle, Microsoft Dynamics—emerged from manufacturing resource planning (MRP) and distribution requirements planning (DRP) environments. Their architecture reflects these origins: bills of materials for products, production orders for manufacturing, inventory for stockholding, and financial periods for reporting. Projects were added later as subsidiary structures, not reimagined as the core. Finance-centric architecture serves financial reporting. Generic ERP architecture centres on the general ledger—the authoritative record of financial transactions. All other structures (projects, cost centres, departments) are dimensions or attributes that enable analysis of financial data. This design serves financial reporting excellently but cannot support operational project control, which requires forward-looking visibility rather than historical accounting. Project-centric architecture serves project control. Project-centric architecture inverts the relationship: the project is primary, and financial reporting is derived. Transactions originate in project context with full scope and cost code detail. Financial views are aggregated from project data, not the reverse. This design enables the operational control that project-based industries require. Architecture determines data model. The ERP data model—the structure of entities, attributes, and relationships—reflects architectural assumptions. Finance-centric data models lack native structures for BoQ, WBS, and the relationships between them. Project-centric data models include these structures as first-class entities with defined relationships, constraints, and behaviours. Architecture determines transaction logic. How transactions are captured, validated, and processed depends on architecture. Finance-centric systems capture transactions against accounts, then tag them with project attributes. Project-centric systems capture transactions against project structures with inherent validation—budget checks, commitment limits, progress constraints—that finance-centric systems cannot enforce natively. Architecture determines reporting capability. What questions a system can answer depends on how data is structured. Finance-centric systems answer financial questions: What did we spend? What is our balance? Project-centric systems answer project questions: What will this project cost at completion? Where are we versus plan? What is our exposure? These questions require different data structures; architecture determines which structures exist. Configuration cannot change architecture. Generic ERP vendors claim that configuration and customisation can address project requirements. Configuration can add fields, screens, and reports—but cannot change the underlying data model. A finance-centric system cannot be configured into a project-centric system because the fundamental organising principle is embedded in the architecture. Project-centric ERP architecture exists because project-based industries need systems designed around their economic reality—the project—not systems adapted from architectures designed for different industries. How It Works Conceptually Project-centric ERP architecture operates through data models, transaction flows, control logic, and reporting structures designed around the project entity. Project as Core Entity In project-centric architecture, the project is the root entity from which other structures derive: PROJECT ├── Contract (commercial terms, payment mechanisms) ├── Bill of Quantities (scope definition) │ ├── BoQ Sections │ ├── BoQ Items (quantity, rate, value) │ └── BoQ Versions (baseline, current, forecast) ├── Work Breakdown Structure (execution organisation) │ ├── WBS Levels │ ├── Work Packages │ └── Activities ├── Budget (cost baseline) │ ├── Budget Lines (by cost code, WBS, BoQ mapping) │ └── Budget Versions ├── Commitments (POs, subcontracts) ├── Actuals (costs incurred) ├── Progress (quantities installed, milestones achieved) ├── Variations (scope changes) ├── Valuations (payment applications) └── Forecasts (estimate to complete, estimate at completion) Every transaction—purchase order, timesheet, invoice, progress entry—references this project structure. The project context is not an optional tag; it is a required attribute that determines processing logic and control validation. Native BoQ-WBS-Cost Code Integration Project-centric architecture implements the BoQ-WBS-Cost Code relationship as a native data structure: BoQ Items define contractual scope with: Measured quantities and units Unit rates and values Mapping to WBS work packages Mapping to cost codes WBS Work Packages define execution organisation with: Scope boundaries and deliverables Allocated budget (from BoQ) Schedule links (activities, milestones) Cost code classification Cost Codes define analytical classification with: Company-wide standardised definitions Resource type breakdown (labour, material, equipment, subcontractor) Roll-up hierarchy for reporting Benchmarking linkage across projects These relationships are maintained by the system—not through external integration or manual reconciliation. A change to a BoQ item propagates to affected WBS work packages and cost code budgets automatically. Transaction Capture in Project Context Project-centric architecture captures transactions with full project context from origination: Procurement transactions: Purchase Requisition ├── Project: PRJ-2024-001 ├── WBS Work Package: 1.3.2.1 Structural Steel - Zone A ├── BoQ Reference: 2.3.1 Structural Steel Supply ├── Cost Code: 05.12.10 Structural Steel - Beams ├── Quantity: 45 tonnes ├── Value: $112,500 └── Delivery Required: 2024-06-15 The requisition is created in project context with all required references. Approval workflows, budget validation, and commitment creation all operate against project structures. Labour transactions: Timesheet Entry ├── Project: PRJ-2024-001 ├── WBS Work Package: 1.3.2.1 Structural Steel - Zone A ├── Cost Code: 05.12.10.L Structural Steel - Labour ├── Hours: 8 ├── Rate: $65/hour ├── Value: $520 └── Date: 2024-05-20 Timesheet entries reference project, WBS, and cost code. Labour cost accumulates against all three structures simultaneously. Progress transactions: Progress Entry ├── Project: PRJ-2024-001 ├── BoQ Item: 2.3.1 Structural Steel Supply ├── WBS Work Package: 1.3.2.1 Structural Steel - Zone A ├── Quantity This Period: 12 tonnes ├── Cumulative Quantity: 32 tonnes ├── Percentage Complete: 71% └── Earned Value: $80,000 Progress entries update BoQ, WBS, and earned value calculations as integrated operations. Control Logic Enforcement Project-centric architecture enforces controls at transaction time: Budget control: Commitment cannot exceed available budget Budget transfers require approval workflow Over-budget alerts trigger before commitment Progress validation: Progress cannot exceed installed quantities Earned value cannot exceed budget value Progress requires verification/certification workflow Change control: Variations require approval before budget impact BoQ changes create auditable version history Baseline changes are controlled and traceable Commercial control: Valuations derive from certified progress Retention calculations apply automatically Variation values flow to payment applications These controls are native to project-centric architecture—not configurations layered on generic systems. Derived Financial Reporting Project-centric architecture derives financial views from project data: Project-to-GL mapping: Project Cost Code → GL Account 05.12.10.L Structural Steel Labour → 510200 Direct Labour 05.12.10.M Structural Steel Materials → 520100 Direct Materials 05.12.10.S Structural Steel Subcontract → 530100 Subcontract Costs Project transactions flow to the general ledger through defined mappings, providing financial reporting without losing project detail. The GL is a derived view, not the source of truth. Period-based reporting: Financial period reports aggregate project data by date range—monthly, quarterly, annually. The project-lifecycle view remains available; period views are calculated as needed. Consolidated reporting: Multi-project portfolios aggregate to enterprise views. Each project maintains full detail; consolidation provides executive visibility without losing project-level control. Tier-1 Enterprise System Requirements Large project-based organisations—international contractors, major shipyards, global mining companies, and infrastructure developers—require enterprise systems that meet Tier-1 standards: the capability, scalability, reliability, and governance characteristics expected of mission-critical business platforms. Project-centric ERP architecture must satisfy Tier-1 requirements while maintaining the project-focused design that generic Tier-1 ERPs cannot provide. Defining Tier-1 Enterprise Systems Tier-1 enterprise systems are characterised by: Enterprise scale: Capability to support thousands of concurrent users, millions of transactions, and petabytes of data across global operations Mission-critical reliability: Uptime guarantees, failover capability, and disaster recovery that ensure continuous business operations Global deployment: Multi-language, multi-currency, multi-entity, and multi-jurisdictional support for international operations Integration breadth: Comprehensive APIs, standard interfaces, and middleware support for ecosystem connectivity Vendor stability: Financial strength, market presence, and long-term viability of the software provider Support infrastructure: Global support coverage, professional services capability, and partner ecosystem Traditional Tier-1 ERP vendors—SAP, Oracle, Microsoft—meet these requirements for generic enterprise operations but fail to deliver project-centric architecture for project-based industries. Functional Requirements for Project-Based Tier-1 Project-based organisations require Tier-1 systems that combine enterprise capability with project-centric functionality: Comprehensive project control: Native BoQ, WBS, and cost code structures with full BoQ-WBS-Cost Code integration Commitment tracking from requisition through final payment Progress measurement with earned value calculation Variation management with baseline versioning Forecasting with estimate-to-complete and estimate-at-completion Multi-currency project accounting with exchange rate management Full financial management: General ledger with multi-entity consolidation Accounts payable and accounts receivable Fixed asset management Cash management and bank reconciliation Financial reporting and statutory compliance Revenue recognition (IFRS 15, ASC 606) for project-based contracts Procurement and supply chain: Strategic sourcing and supplier management Purchase requisition and purchase order processing Subcontract management with back-to-back terms Material management and inventory control Logistics and delivery tracking Supplier performance evaluation Human resources and payroll: Employee master data and organisational structures Time and attendance capture Payroll processing with multi-jurisdiction compliance Resource planning and allocation Skills and competency management Training and development tracking Document and information management: Document control with version management Drawing and specification management Correspondence tracking and workflow Transmittal management Integration with document management systems Long-term archival and retrieval Business intelligence and analytics: Executive dashboards and KPI monitoring Ad-hoc reporting and analysis Cross-project portfolio analytics Predictive analytics and forecasting Data warehouse integration Self-service reporting capability Scalability Requirements Tier-1 systems for project-based industries must scale across multiple dimensions: Transaction volume: Thousands of timesheets per day Hundreds of purchase orders per day Continuous progress updates from multiple sites Month-end processing peaks without degradation Data volume: Years of project history maintained online Document attachments and correspondence archives Audit trails and transaction logs Benchmarking data across completed projects User concurrency: Headquarters users in finance, procurement, and management Project site users in cost control, planning, and supervision Field users capturing time, progress, and quality data External users (subcontractors, partners, clients) with controlled access Geographic distribution: Operations across multiple time zones Users on multiple continents Data centres in multiple regions Network latency tolerance for remote sites Organisational complexity: Multiple legal entities with consolidation Joint venture structures with partner accounting Matrix organisations with project and functional reporting Acquired companies integrated into common platform Integration Requirements Tier-1 systems must integrate with the broader technology ecosystem: Scheduling tools: Bi-directional integration with Primavera P6, Microsoft Project, and other scheduling platforms WBS synchronisation between ERP and scheduler Resource-loaded schedule import/export Progress update synchronisation Building Information Modelling (BIM): Quantity extraction from BIM models Cost loading to model elements (5D BIM) Progress visualisation in 4D BIM Change impact analysis through model integration Estimating systems: Import of estimates as project budgets Export of actuals for estimating database updates Productivity data exchange Cost code mapping and synchronisation Document management: Integration with SharePoint, Aconex, Asite, and other platforms Document linking to transactions and records Transmittal workflow integration Archive and retrieval synchronisation Geographic Information Systems (GIS): Spatial data integration for linear projects Asset location tracking Progress mapping and visualisation Environmental and permit boundary management IoT and field systems: Equipment telematics integration Environmental monitoring data Access control and safety systems Quality inspection and testing data Corporate systems: Human resources information systems (HRIS) Corporate financial consolidation Business intelligence platforms Customer relationship management (CRM) Governance and Compliance Requirements Tier-1 systems must support enterprise governance: Audit and controls: Complete audit trail of all transactions Segregation of duties enforcement Approval workflows with delegation Change logging with user attribution Regulatory compliance documentation Financial compliance: GAAP and IFRS accounting standards Revenue recognition requirements (IFRS 15, ASC 606) Percentage of completion accounting Multi-jurisdiction tax compliance Transfer pricing documentation Industry compliance: Construction industry reporting standards Mining industry codes (JORC, NI 43-101) where applicable Maritime classification society requirements Government contract compliance (FAR, DFARS for US federal work) Corporate governance: Board reporting and executive dashboards Risk register integration Policy compliance tracking ESG metric capture and reporting Cloud Architecture, Data Sovereignty, and Security Project-centric ERP architecture must be supported by cloud infrastructure that meets the demanding security, compliance, and data sovereignty requirements of capital project delivery. The sensitivity of project data—commercial terms, cost structures, bid information, contractual positions—requires infrastructure that provides isolation, protection, and verifiable security. Private Dedicated Cloud Environments Enterprise project-centric ERPs should be deployed in private dedicated cloud environments rather than shared multi-tenant infrastructure: Dedicated compute resources: Each client organisation operates on dedicated virtual machines, containers, or compute instances—not shared with other tenants. This isolation prevents resource contention and eliminates risks of cross-tenant data leakage. Dedicated database instances: Project data resides in dedicated database instances, not shared databases with logical separation. Dedicated instances provide: Complete data isolation from other organisations Independent backup and recovery Customisable performance tuning Clear data ownership boundaries Network isolation: Dedicated virtual networks, firewalls, and security groups isolate each client environment. Network traffic does not traverse shared infrastructure where interception or monitoring by other tenants could occur. Independent scaling: Dedicated environments scale independently based on client workload—not constrained by or affecting other tenants. Peak periods (month-end closings, bid submissions, progress reporting) receive necessary resources without contention. Sovereign Cloud and Data Residency Project-based organisations operate under diverse regulatory requirements governing where data can be stored and processed: Data residency requirements: Many jurisdictions require that certain data—particularly for government contracts, defence projects, and critical infrastructure—remain within national borders. Sovereign cloud deployment ensures data residency compliance: Data stored in specified geographic regions Processing occurs within jurisdictional boundaries No data transfer to other countries without explicit authorisation Regulatory compliance: Different regions impose different data protection requirements: GDPR in the European Union Data protection laws in the Middle East (UAE, Saudi Arabia) Privacy regulations in Asia-Pacific (Singapore, Australia) Sector-specific requirements for defence, energy, and government projects Government and defence requirements: Projects involving government clients or classified information may require sovereign cloud infrastructure operated by locally-approved providers, subject to national security clearance and oversight. Cloud deployment models supporting sovereignty include: Public cloud with regional deployment: Major cloud providers (AWS, Azure, Google Cloud) offering region-specific deployment with data residency guarantees Sovereign cloud partitions: Dedicated cloud regions operated under national oversight for government and regulated workloads Private cloud on-premises: For organisations requiring complete control, private cloud infrastructure within client data centres Database Encryption and Data Protection Project data requires comprehensive encryption at multiple layers: Encryption at rest: All data stored in databases, file systems, and backups is encrypted using strong cryptographic standards: AES-256 encryption for database storage Encrypted file systems for document and attachment storage Encryption key management through hardware security modules (HSM) or key management services Client-controlled encryption keys where required Encryption in transit: All data moving between components is encrypted: TLS 1.3 for all network communications Encrypted connections between application servers and databases Encrypted API communications Secure file transfer protocols Field-level encryption: Sensitive data elements—financial values, bid amounts, commercial terms—can be encrypted at field level, providing additional protection even if database access is compromised. Data masking and anonymisation: Non-production environments (development, testing, training) use masked or anonymised data, preventing exposure of production data in less-controlled environments. Backup and Disaster Recovery Project data represents significant accumulated value—years of project history, commercial records, and operational knowledge. Protection against loss is essential: Automated backup: Continuous database backup with point-in-time recovery capability Regular full backups with configurable retention periods Encrypted backup storage in geographically separate locations Backup verification and restoration testing Disaster recovery: Recovery Point Objective (RPO): Maximum acceptable data loss, typically measured in minutes or hours Recovery Time Objective (RTO): Maximum acceptable downtime, typically measured in hours Documented disaster recovery procedures with regular testing Geographic redundancy to protect against regional disasters Business continuity: Failover to secondary sites for critical systems High availability configurations eliminating single points of failure Incident response procedures for security events Communication protocols for stakeholder notification ISO 27001 and Security Certifications Enterprise project-centric ERPs should maintain internationally recognised security certifications: ISO 27001 (Information Security Management System): ISO 27001 certification demonstrates that the organisation has implemented a comprehensive information security management system (ISMS) covering: Risk assessment and treatment Security policies and procedures Access control and identity management Cryptographic controls Physical and environmental security Operations security Communications security Incident management Business continuity Compliance management ISO 27001 certification requires: Independent audit by accredited certification bodies Annual surveillance audits Triennial recertification Continuous improvement processes SOC 2 (Service Organisation Control): SOC 2 reports provide assurance on controls relevant to security, availability, processing integrity, confidentiality, and privacy: SOC 2 Type I: Controls designed appropriately at a point in time SOC 2 Type II: Controls operating effectively over a period (typically 12 months) Additional certifications relevant to specific sectors or regions: ISO 27017: Cloud security controls ISO 27018: Protection of personal data in the cloud CSA STAR: Cloud Security Alliance certification Regional certifications as required by jurisdiction Access Control and Identity Management Project-centric ERPs must implement robust access control aligned with project-based organisational structures: Role-based access control (RBAC): Access permissions defined by role, not individual Roles aligned with project functions (project manager, cost controller, quantity surveyor) Segregation of duties enforced through role design Least-privilege principle limiting access to required functions Project-based access: Access granted by project, not just by function Users see only projects they are assigned to Cross-project access controlled and audited Subcontractor and partner access limited to relevant scope Multi-factor authentication (MFA): Required for all users accessing the system Support for authentication apps, hardware tokens, and biometrics Conditional access policies based on location, device, and risk Single sign-on (SSO): Integration with enterprise identity providers SAML and OAuth support for federated authentication Centralised user provisioning and deprovisioning Audit logging: Comprehensive logging of all user actions Tamper-evident audit trails Long-term log retention for compliance and forensics Alerting on suspicious activities Compliance and Regulatory Requirements Project-centric ERP architecture must support compliance with industry and regulatory requirements: Financial regulations: Audit trail requirements for financial transactions Revenue recognition compliance (IFRS 15, ASC 606) Tax authority reporting requirements Anti-money laundering (AML) controls where applicable Industry standards: Construction industry data standards Integration with classification society requirements (marine/offshore) Mining industry reporting codes (JORC, NI 43-101) where applicable Contract compliance: Document retention requirements Discovery and legal hold capabilities Confidentiality controls for commercially sensitive information Export control compliance for international projects ESG reporting: Data capture for environmental metrics Supply chain transparency requirements Governance and ethics compliance documentation Why Generic Approaches Fail Generic ERP architecture fails in project-based industries because the fundamental design assumptions conflict with project-based requirements. Finance-first data model cannot support project control. Generic ERP data models centre on the general ledger with projects as attributes: GL Transaction ├── Account: 520100 Direct Materials ├── Cost Centre: CC-100 Operations ├── Project: PRJ-2024-001 (optional dimension) ├── Amount: $50,000 └── Period: May 2024 The project is a tag, not a context. The transaction has no inherent relationship to BoQ, WBS, or cost codes. Project visibility requires post-hoc aggregation of GL transactions—which cannot provide the forward-looking control that project-based industries require. No native BoQ capability. Generic ERPs have no Bill of Quantities entity. Organisations must: Use spreadsheets outside the system Create custom objects with limited functionality Adapt inappropriate structures (sales orders, bills of materials) None of these approaches provides true BoQ capability: versioning, remeasurement, variation tracking, and integration with WBS and cost codes. WBS as reporting hierarchy only. Generic ERPs may offer WBS-like structures, but typically as reporting hierarchies rather than operational control structures. The WBS does not: Link natively to BoQ items Drive schedule integration Control budget at work package level Enable earned value calculation Cost codes as GL extensions. Generic ERPs treat cost codes as extensions to the chart of accounts or as analysis dimensions. This design: Limits cost code structure to GL constraints Prevents company-wide standardisation across projects Cannot support the productivity templates and cost recipes that enable benchmarking Post-factum rather than forward-looking. Generic ERP architecture captures transactions after the fact. By the time a cost appears in the system, the economic decision has been made. Project-based industries need: Commitment tracking when POs are issued Budget validation before approval Forecast visibility throughout execution Finance-centric architecture provides historical record; project-centric architecture provides predictive control. Tier-1 generic ERPs compound the problem. Major Tier-1 ERP vendors (SAP, Oracle) have attempted to address project-based industries through modules and extensions. These attempts fail because: Project modules are add-ons to finance-centric cores Data models remain organised around GL, not projects Integration between project and finance modules requires reconciliation True project-centric functionality requires extensive customisation Customisation creates upgrade barriers and technical debt Organisations selecting Tier-1 generic ERPs for project-based operations face a choice: accept compromised project control or invest heavily in customisation that undermines the benefits of standardisation. Integration complexity. Organisations using generic ERPs in project-based industries typically require: Separate estimating systems Separate scheduling systems Separate BoQ/QS systems Separate progress measurement Extensive spreadsheet workarounds These point solutions must be integrated—creating data duplication, reconciliation effort, and traceability loss. Project-centric architecture provides these capabilities natively, eliminating integration complexity. Security architecture not designed for project sensitivity. Generic ERPs designed for manufacturing or retail do not address the security requirements of project-based industries: Bid data requiring strict confidentiality Commercial terms affecting competitive position Joint venture data with partner access restrictions Government and defence project classification requirements Project-centric ERPs with purpose-built cloud architecture address these security requirements natively. Customisation creates technical debt. Attempts to adapt generic ERPs for project-based industries through customisation create: Custom objects that do not integrate with core functionality Custom logic that breaks with upgrades Custom reports that require ongoing maintenance Technical debt that accumulates over time Project-centric ERPs deliver fit-for-purpose functionality without customisation burden. Where It Applies Enterprise Project Control. Project-centric architecture for organisations managing portfolios of capital projects—providing integrated control across all projects with enterprise-level visibility. Multi-Entity Operations. Project-centric architecture supporting projects that span legal entities, geographies, and currencies—maintaining project integrity across organisational complexity. Joint Venture Projects. Project-centric architecture enabling JV cost sharing, partner reporting, and commercial reconciliation while maintaining sponsor-level control. Programme Management. Project-centric architecture supporting programmes comprising multiple related projects—with programme-level consolidation and project-level detail. Owner Project Controls. Project-centric architecture for owner organisations managing capital programmes—providing visibility across multiple contractors and delivery models. Contractor Operations. Project-centric architecture for contractors delivering multiple concurrent projects—enabling resource optimisation, cross-project benchmarking, and portfolio management. Government and Defence Projects. Project-centric architecture with sovereign cloud deployment for projects requiring data residency, security clearance, and regulatory compliance. International Operations. Project-centric architecture with regional deployment supporting data sovereignty requirements across multiple jurisdictions. Architecture Evaluation Criteria Organisations evaluating ERP architecture should assess whether systems are genuinely project-centric with appropriate security infrastructure or finance-centric with project additions. Data Model Assessment Criterion Project-Centric Finance-Centric Project entity Core/root entity Dimension/attribute BoQ structure Native first-class object Custom object or external WBS structure Integrated with cost and schedule Reporting hierarchy only Cost codes Company-wide with project mapping GL account extension BoQ-WBS-Cost Code relationship Native and maintained Manual or non-existent Transaction Flow Assessment Criterion Project-Centric Finance-Centric Transaction origination In project context In financial context Project reference Required at entry Optional/added later Budget validation At transaction time Post-hoc or none Commitment capture At PO/subcontract creation At invoice receipt Progress integration Native workflow External or manual Control Logic Assessment Criterion Project-Centric Finance-Centric Budget control Enforced at commitment Reported after fact Change control Integrated workflow Separate system/process Progress validation System-enforced Manual verification Forecast calculation Native function Spreadsheet/external Reporting Assessment Criterion Project-Centric Finance-Centric Default view Project lifecycle Financial period Cost-to-complete Native calculation Manual/external Earned value Integrated with progress Calculated externally Variance analysis Drill-down to root cause Aggregate only Cross-project benchmarking Native capability Custom development Cloud and Security Assessment Criterion Enterprise-Grade Basic/Shared Deployment model Private dedicated Multi-tenant shared Data isolation Dedicated database instances Logical separation only Data residency Configurable by region Limited options Encryption at rest AES-256 with key management Basic encryption Encryption in transit TLS 1.3 enforced TLS supported Security certifications ISO 27001, SOC 2 Type II Limited or none Backup and recovery Defined RPO/RTO with testing Basic backup only Access control Project-based RBAC with MFA Basic role-based Audit logging Comprehensive, tamper-evident Basic logging Common Misconceptions Misconception: Architecture is a technical concern for IT, not a business consideration. Reality: Architecture determines what the business can do with the system—what questions can be answered, what controls can be enforced, what visibility is available. Architecture is a business decision with technical implementation. Business leaders must understand architectural implications to make informed ERP decisions. Misconception: Modern generic ERPs have solved project management through add-on modules. Reality: Add-on modules cannot change core architecture. A finance-centric system with a project module remains finance-centric. The module may provide screens and reports, but cannot change the underlying data model, transaction logic, or control philosophy. Architectural limitations persist regardless of module additions. Misconception: Cloud delivery eliminates architectural differences. Reality: Cloud delivery changes how systems are deployed and accessed but does not change architecture. A finance-centric ERP delivered via cloud remains finance-centric. A project-centric ERP delivered via cloud remains project-centric. Delivery model and architecture are independent considerations—though cloud architecture for security and sovereignty matters significantly. Misconception: Multi-tenant cloud is always more cost-effective than private dedicated environments. Reality: Multi-tenant cloud may have lower entry costs but creates risks for project-based organisations: data co-mingling concerns, limited customisation, shared resource contention, and compliance challenges. Private dedicated environments provide isolation, security, and control that justify incremental cost for organisations managing sensitive project data. Misconception: Data sovereignty only matters for government projects. Reality: Data sovereignty affects any organisation subject to regional regulations (GDPR, local data protection laws), operating in multiple jurisdictions, or managing commercially sensitive information. International contractors, joint ventures, and organisations with diverse client bases all benefit from sovereign cloud deployment options. Misconception: Security certifications are just marketing; all cloud systems are secure. Reality: Security certifications like ISO 27001 and SOC 2 Type II require independent audit, documented processes, and demonstrated controls. Not all cloud systems achieve these certifications. Organisations should verify certifications, review audit reports, and assess security architecture rather than assuming equivalent security across providers. Misconception: Integration platforms can connect finance-centric ERPs with project tools to achieve project-centric capability. Reality: Integration can move data between systems but cannot create architectural capability. Integrating a finance-centric ERP with project tools creates data synchronisation challenges, reconciliation requirements, and traceability gaps. Native project-centric architecture provides integrated capability that integration cannot replicate. Misconception: Project-centric architecture sacrifices financial reporting capability. Reality: Project-centric architecture derives financial views from project data—providing full financial reporting capability while maintaining project detail. Financial reports are produced from project-centric systems; they simply derive from project data rather than requiring project data to be subordinate to financial structures. Misconception: Smaller organisations do not need project-centric architecture or enterprise-grade security. Reality: Smaller organisations have less capacity to manage workarounds, manual reconciliation, and spreadsheet processes that finance-centric systems require. They also have less capacity to recover from security incidents. Project-centric architecture with appropriate security may be more valuable—not less—for smaller organisations that cannot absorb inefficiency or risk. Related Topics What Is an Industry-Specific ERP? — The category of systems that employ project-centric architecture. What Is Finance-Led vs. Project-Led ERP? — The strategic distinction between architectural approaches. What Is a Project-Based Business? — The economic model that project-centric architecture supports. What Is a Project-Based Operating Model? — The operational framework that project-centric architecture enables. What Is the BoQ-WBS-Cost Code Relationship? — The structural integration native to project-centric architecture. What Is Post-Factum Accounting? — The limitation of finance-centric architecture that project-centric architecture overcomes. What Is a System of Prevention vs. a System of Record? — The control philosophy enabled by project-centric architecture. RELATED ASSETS Related Industries Construction Project-based Manufacturing Marine and Offshore Construction Mining and Quarrying Shipbuilding and Repairs RELATED ASSETS Related Stakeholders Owner/Developer E&P Owners Mine & Quarry Owner Consultants General Contractors Marine Contractor Shipbuilders Mining Contractor RELATED ASSETS Related Roles C-level Executives Project Manager Bidding Manager Cost Estimator Cost Controller Go to Previous Topic Previous Topic Return to What is? Go to Hub Go to Next Topic Next Topic