Activity & Artifact Recognition
High-yield artifacts
| Artifact | Recognize it by |
|---|---|
| Data Architecture Design | Master blueprint describing enterprise structures/plans. |
| Enterprise Data Model (EDM) | Enterprise concepts, relationships, rules, critical attributes across linked abstraction levels. |
| Subject Area Model | Conceptual model scoped to one semantic subject area. |
| Data Flow | Lineage/movement among processes, systems, stores, roles, locations, transformations. |
| Data Value Chain | Dependency/order view showing how data produced by one capability feeds others. |
| Implementation Roadmap | Roughly 3–5 year development path with milestones, dependencies, resources, costs, capability streams. |
Activity recognition map
Establish the Data Architecture practice
Cue: frameworks, work streams, organization, culture, methods, and useful results.
Evaluate existing specifications
Cue: determine whether current documentation is accurate, complete, and detailed enough; update it.
Develop the roadmap
Cue: actual conditions + business requirements + technical assessment → target path over time.
Manage enterprise requirements within projects
Cue: scope, requirements, design, buy/reuse/build, alignment to EDM, standards, dependencies, and feedback.
Integrate with Enterprise Architecture
Cue: portfolio/application/integration planning and proactive influence on project priorities/scope.
Project-stage recognition
| Stage | Architecture question |
|---|---|
| Scope | What enterprise model, reuse opportunity, project contribution, and downstream dependency matters? |
| Requirements | Which entities, sources, availability, quality, pain points, and business value matter? |
| Design | Which enterprise constructs, target specifications, standards, authoritative sources, and lifecycle rules apply? |
| Implement | Are we buying, reusing, or building, and what mappings/gaps/standards are required? |
| Feed back | What project knowledge should improve enterprise architecture? |
Buy / Reuse / Build
- Buy: vendor/COTS → map vendor structures; reverse engineer if needed; document gaps.
- Reuse: existing internal capability → map common structures/processes, CRUD, authority/system of record, gaps.
- Build: new implementation → implement agreed structures and standardized/designed integration.
Lifecycle status recognition
- Current — supported/used now.
- Deployment Period — planned nearer-term deployment.
- Strategic Period — longer-horizon expected availability/use.
- Retirement — exit/end-of-use direction.
- Preferred — recommended broadly.
- Containment — restrict expansion.
- Emerging — research/pilot.
- Reviewed — evaluated, not another status.
Governance recognition
- oversee projects,
- manage designs/lifecycle/tools,
- define standards,
- create data-related artifacts.
Metric recognition
- Compliance: did projects follow architecture/process?
- Implementation trends: are reuse/replace/retire and efficiency moving as intended?
- Business value: did architecture improve agility, quality, cost, risk, or other enterprise outcomes?