Lesson 5 — Project Integration: Scope, Requirements, Design, Buy/Reuse/Build
Source focus: DMBOK Chapter 4, pp. 114–116.
Architecture becomes real inside projects
A blueprint that never influences project decisions is not enough. Chapter 4 makes enterprise requirements part of project delivery from early scope through implementation.
1. Scope
Architecture asks: - Is the project aligned to the EDM? - What enterprise constructs can be reused? - What new enterprise knowledge might this project contribute? - What external/downstream dependencies exist? - Which shareable artifacts should return to enterprise repositories?
A key principle is two-way learning: projects consume architecture and can improve it when they discover a valid enterprise need.
2. Business requirements
The source expects projects to consider data requirements such as: - entity, - source(s), - availability, - quality, - pain points, - business value of satisfying the requirement.
Architecture is not merely a late technical design review.
3. Design
Conceptual, logical, and physical project models should be reviewed for: - consistency with enterprise meaning, - long-term strategy support, - applicable standards, - reusable enterprise structures, - authoritative source expectations, - integration and lifecycle rules.
Avoid two opposite mistakes
Blind enforcement: “The enterprise model can never change.”
Wrong. A project can discover a genuinely enterprise-relevant concept; the enterprise artifact should improve.
Unreviewed divergence: “The project is local, so it can redefine Customer.”
Wrong. Local schedule pressure is not sufficient reason to create semantic drift.
4. Implement — Buy
When acquiring COTS/vendor software: - understand its internal data model, - reverse engineer when necessary, - map vendor structures to enterprise concepts, - identify definition/rule gaps, - document conflicts, - negotiate for model documentation where possible.
Buy never means “accept vendor semantics as enterprise semantics.”
5. Implement — Reuse
When reusing existing enterprise/application data: - map application models to common enterprise structures/processes, - understand CRUD behavior, - identify authoritative/system-of-record expectations, - document definition or structural gaps, - control unnecessary replication.
Reuse can still require significant mapping/integration work.
6. Implement — Build
When creating a new solution: - implement storage according to agreed data structures, - integrate according to standardized/designed specifications, - use applicable enterprise standards and architecture requirements.
Memory hook: Buy learns vendor; Reuse maps existing; Build creates new.
7. Replication: architecture governs the requirement, not a slogan
Replication can improve performance and availability, but uncontrolled copies can create inconsistency.
Chapter 4 does not say every copy must be perfectly synchronized at every instant. Different applications can tolerate different consistency levels. Architecture should define the actual business requirement and choose/control the mechanism accordingly.
8. Waterfall, incremental, and Agile all still need architecture
Waterfall
Architecture can align to phases/tollgates. The risk is treating architecture as a separate document rather than an enterprise requirement guiding those phases.
Incremental
Repeated releases still need early initiation and enough comprehensive data design to keep increments compatible.
Agile / iterative
Sprints still need appropriate specifications for: - models, - capture, - storage, - distribution, - shared standards.
Detailed implementation can emerge iteratively while enterprise intent remains stable enough to prevent local incoherence. Close architect/programmer collaboration matters.
The correct frame is architecture with agility, not architecture versus agility.
9. Project architecture loop
Scope → Requirements → Design → Implement → Feed Back
Under Implement: Buy | Reuse | Build.
Feed Back means reusable project knowledge and assets improve the enterprise architecture rather than disappearing inside one application.
Stop and check
Vendor refuses to provide a Customer model. Force the vendor to redesign?
Not necessarily. Reverse engineer/map the package as needed, document semantic/rule gaps, and design governed integration within practical constraints.
An Agile team says architecture is incompatible with sprints.
Incorrect. Delivery method changes how architecture is applied, not whether enterprise data requirements exist.