An Integrated Enterprise Architecture and SysML Baseline
01
Project Background
From scattered documents to a unified review baseline.
In projects involving multiple subsystems, requirements, architecture viewpoints, interface tables, and design diagrams are often maintained separately. The same objects have different names, functional allocations and system structures lack mutual traceability, and reviewers must find supporting evidence manually. We start with one representative task chain and organize these materials into a reviewable model baseline, rather than merely adding diagrams.
Start with the questions the review must answer: which systems deliver a capability, whether key interfaces are complete and which verification activities a requirements change affects. Assign unresolved data and metrics to responsible reviewers for confirmation.
02
Technical Approach
Link architecture viewpoints and system models across layers.
The architecture layer expresses capabilities, activities, resources, and collaborative relationships; the system layer expresses requirements, functions, structures, interfaces, and behavior. Stable object identifiers and allocation relationships link the two layers, avoiding a single oversized diagram that mixes architecture with system design. Select the necessary viewpoints first, then define naming, units, relationship types, and package structures so different modelers use the same semantics.
Build traceability along the task chain from requirements to functions, functions to structures, and structures to interfaces and verification items. For each interface, record the provider, receiver, data or physical quantities, direction, and timing constraints. Model links express design responsibilities; whether requirements are met still needs evidence from simulation, analysis, or testing.
03
Implementation Process
Build a representative slice before expanding model scope.
In phase one, organize the source-material inventory and object dictionary, then select a task containing both normal and exception paths. In phase two, build architecture activities and system structures, checking functional allocations, ports, and behavior. In phase three, business and design owners walk through the task step by step, recording missing objects, conflicting constraints, and interfaces with unclear responsibility.
Expand to adjacent subsystems only after reviewing the initial slice. Each delivery retains model versions, relationship changes, and issue-resolution records, preventing models and reports from diverging. Finally, freeze the relationships among the model, referenced libraries, tool versions, and external materials so the recipient works from the same baseline.
04
Deliverables
Editable projects and traceable evidence.
Recommended deliverables include architecture viewpoint products, the SysML model project, object and interface dictionaries, a requirements traceability matrix, review issues, and a baseline description. Wherever possible, document diagrams should be exported from the model and retain their corresponding object or view locations. Standalone screenshots do not replace an editable, inspectable project.
If model-library reuse or tool integration is included, also hand over dependency versions, import/export examples, and operating instructions. State usage conditions separately for license-restricted plugins, external repositories, and third-party models. We do not promise to transfer licenses for tools we do not own with the project.
05
Acceptance Method
Spot-check complete relationship chains and change impacts.
The recipient opens the project in the agreed tool environment and spot-checks a requirement's path from its source through design objects, interfaces, and verification items, then selects a change to check its impact. Check orphan requirements, parameters without sources, and broken references, and confirm that issue-closure records match the current baseline.
Acceptance assesses whether the model supports the agreed review, rather than using diagram or connection counts as the sole criterion. Model completeness does not establish satisfactory performance; metrics without verification evidence must be clearly marked. Additional viewpoints, algorithm co-simulation, or full migration require separate scope confirmation.
06
Engineering Refinement Recommendations
For similar integrated modeling work, begin with package organization, element identifiers, shared interfaces, and review checklists. Link requirements, behavior, structure, and verification records for one mission thread before extending to the agreed scope, rather than creating many views without context.
Recommended additions include coverage definitions, a broken-link register, model inspection records, and report templates. At acceptance, the receiving team should independently trace a requirement change and confirm that regenerated reports match the model version. These are refinement and acceptance recommendations, not additional measured outcomes of this case.
07
Method Recommendation · Cross-Tool Model Exchange Checks
For similar architecture work involving cross-tool exchange, begin with a teaching example containing types, cross-package relationships, and library dependencies. Map source and target element identities and check whether relationships and properties survive a round trip. Explicitly mark unsupported extensions as skipped or unresolved.
Validate model conversion on a small sample first. Use the actual tool versions and mapping rules to confirm support for objects, relationships and traceability information.
08
Implementation Outcomes
Shorten design checks and change reviews.
We deliver an accessible, traceable architecture and system model baseline that lets reviewers follow requirements to design objects and verification evidence.
Efficiency evaluation uses the same set of review questions and one representative change, recording information retrieval time, missing relationships, identification of affected objects, and issue-closure time.