In the ArchiMate language, advanced relationships serve as the essential connectors that bridge different architectural layers and capture the nuances of how elements depend on or impact one another. While basic structural relationships define how elements are composed, these advanced dependency and structural links are critical for modeling Business-IT alignment and impact analysis. They allow architects to move beyond static structures to describe the dynamic support and motivational drivers within an enterprise.
1. The Serving Relationship
The Serving relationship (formerly known as “Used By”) represents a control dependency where one element provides its functionality to another. In alignment with service-orientation, it typically models how external behavior elements (services) or interfaces are utilized by entities in their environment. It is denoted by a solid line with an arrowhead pointing toward the element being served.
- Usage: It is commonly used to show how lower layers support higher layers, such as an Application Service serving a Business Process.
- Practical Example: A “Payment Service” is modeled as serving a “Pay Invoices” business process. Similarly, an “Application Hosting” technology service might serve a “Financial Application” component, illustrating the infrastructure’s support for the software layer.
2. The Realization Relationship
The Realization relationship is a structural link indicating that a more tangible or concrete element plays a critical role in the creation, achievement, or operation of a more abstract element. It effectively maps the “how” (physical or logical execution) to the “what” (abstract requirement or service). It is represented by a dashed line with an unfilled arrowhead.
- Usage: This relationship is the primary tool for cross-layer alignment, such as a Technology Artifact (like a database table) realizing an Application Data Object.
- Practical Example: A “Transaction Processing” business function realizes a “Billing Service”. In a more technical context, a “Web Archive” artifact realizes an “Application Component”, showing how a physical file implements a logical software unit.
3. The Influence Relationship
The Influence relationship represents an impact dependency, modeling how an element affects the implementation or achievement of a motivation element, such as a goal or principle. It is the weakest type of dependency and can be quantified using attributes like plus (++) or minus (–) to indicate the strength and sign of the effect.
- Usage: It is vital for trade-off analysis, allowing architects to visualize how a single action might positively influence one goal while negatively impacting another.
- Practical Example: Modeling the decision to “Assign Personal Assistant” may show a strongly positive (++) influence on the goal “Reduce Workload of Employees” but a strongly negative (–) influence on the goal “Decrease Costs”.
Practical Examples of Cross-Layer Integration
By combining these advanced relationships, architects can create a comprehensive view of enterprise dependencies:
- Traceability Chain: A “Customer Database Table” (Artifact) realizes “Customer Data” (Data Object), which realizes the “Customer Information” (Business Object). If the underlying database table experiences a failure, architects can use this chain of realization to perform impact analysis on the business layer.
- Service Delivery: An “Authentication Service” (Technology Service) serves a “Policy Administration” application component. This component, in turn, realizes an application service that serves a business role, ensuring that the technology infrastructure is explicitly linked to the end-user’s needs.
- Motivational Alignment: A “Mobile App” (Application Component) may realize a requirement to “Provide self-service,” which influences the goal of “Increased Customer Satisfaction”. This traces technical deployment directly to strategic outcomes.
