Architecting with Cross-Project Relationships

As teams adopt model-based approaches, a commonly cited challenge is model management – for navigation, for collaboration, for access control, and for reuse. CORE introduces the ability to create relationships between elements in different projects providing project teams and enterprise efforts great flexibility to partition their models as they see fit. Whether addressing process needs, reuse, contractual obligations, or any other concept, cross-project relationships enable teams to architect, manage, baseline, and reuse their models in a highly modular manner.

With the same drag-drop ease of connecting one element to another, you can drag an element from one project onto an element in another to link the two projects. If you prefer to work via list and dialog, the target window and diagram palette include a project selector at the bottom allowing you to quickly access the project and element of interest. You can create as many or as few cross-project relationships as desired; resulting in highly linked or loosely coupled projects. And it doesn’t stop with just two projects - you can link one project to as many other projects as you desire.

Once the cross-project relationships are established, you decide how you want them to operate. You can specify whether the relationships should be traversed seamlessly so that the project borders become blurred - in effect creating a mega-project. Or you can specify that the relationships should stop with the element you have linked, operating as a black box through which you can only see the defined interface point. Or you can specify that relationships to the other project are hidden from view. Diagrams, reports, and even simulations honor your specification. When combined with project-level permissions, this provides wonderful flexibility and power to architect your solution.

The beauty of cross-project relationships is in their simplicity – the simplicity of creating them, the ease of managing them, and the transparency (if desired) of using them. Once you establish a relationship, CORE displays a new project in the Related Projects section of the Project Explorer. From this view, you can see all of the cross-project relationships and the elements they involve. You can also quickly redefine the connection characteristic.

With cross-project relationships, you have more power than ever to tackle challenging problems including:

• Enterprise Architecture - in this scenario, a governing architecture has been developed and is owned by a given team. As deficiencies are identified and capabilities proposed, those solutions must be developed within the framework of the enterprise architecture. Ownership of the solution architecture is separate from the ownership of the enterprise architecture.
• System of Systems - in this scenario, the solution architecture is comprised of a federated system of systems – some existing andsome under development. In a federated scenario, different organizations have ownership and authority over different systems, yet there is a solution architect trying to integrate to deliver a new capability.
• Contractor Boundaries - in most systems of note, there are two or three different levels of organizations involved, each with their own responsibilities and ownership. The customer may own the operational analysis and source requirements development. The prime contractor may own the system-level analysis. The subcontractors may own individual components. In many cases, to some degree work will proceed in parallel across these groups. Regardless, visibility and permissions across the boundaries are tightly controlled.
• Systems Integration - more and more, systems engineering is tasked with leveraging existing solutions – be that capabilities, systems, or components – and integrating them in different ways to deliver new value. The existing solutions are under different control and may often continue to evolve while the architect is required for developing the new capability.
• Baselining / Product Revision - as a system moves through the development lifecycle, there is often a need to baseline and lock down prior work, though the work must remain available for extension. Related is the issue of iterative development when a product is incrementally released to the marketplace - either as successive versions or as related products in a product family.
• Reuse. Many times, there is a common seed that is reused by multiple projects. This seed is developed and owned by one organization with dependent projects owned by different organizations. The common seed can continue to evolve over time (e.g., a software library for reuse, a process framework, or a common architecture).

Additional Information

• Related Projects
• Jump to Element
• Edit Connection Settings
• Remap Project ID
• Disconnect Permanently