On this page
Projects and analysis scope
Define a project around a source platform and an assessment question, then account for shared dependencies and input revisions.
A project brings together a source platform, its input artifacts, and the analysis you use to investigate them. Define its scope around a question the team needs to answer: how a report is produced, what a set of jobs depends on, or which area could be modernized first.
Choose a useful boundary
Start from a recognizable output or capability. Include the processing that produces it and the definitions needed to interpret that processing. A boundary based only on a folder or file count can omit shared logic that sits elsewhere in the source system.
For the monthly-revenue example, a useful question is: “What would need to move to reproduce this report?” Its scope includes order preparation, exchange-rate selection, conversion, and aggregation. Other reports can remain outside the scope while still being consumers of shared preparation.
Separate project scope from source-system scope
The source system can be larger than the project. Keep three inventories distinct:
| Inventory | What it establishes |
|---|---|
| Intended scope | The outputs, programs, structures, and dependencies the team wants to assess |
| Supplied artifacts | The material actually available to the analysis |
| Represented assets | The objects and relationships visible in the resulting analysis |
A mismatch tells you where to investigate. If a required transformation is missing from the supplied artifacts, return to source preparation. If its artifact was supplied but the corresponding analysis is incomplete, inspect the available result and its limitations before drawing a conclusion.
Shared and external dependencies
A shared object can affect more than one candidate work package. For example, a currency routine may serve both monthly revenue and daily sales. Replacing it for one flow requires a decision about the other consumer: retain the current interface, move both consumers, or provide an agreed transition.
An external reference identifies a boundary in the available information. Record the owner and the artifact or explanation needed to resolve it. A reference to a database object does not by itself supply its definition, and a call to a routine does not supply the routine’s body.
Data systems and applications
Data-system investigations often begin with outputs, transformations, structures, and lineage. Application investigations can begin with programs, calls, and control flow. Use the source platform’s vocabulary when defining the question; the data-oriented examples in these guides do not establish identical asset coverage for every platform.
Keep an input revision
Associate the assessment with the source revision or extraction date and an inventory of supplied material. This can be an engagement document maintained alongside the project; it does not require a particular field in the UI.
When inputs change, identify which conclusions depend on the changed material and review the corresponding analysis. A newly discovered dependency can alter the proposed boundary even if the business output has not changed.