INFOSYS 220 Chap.8 Architecture and Data Modelling
Architecture and Data Modelling
Allocate responsibilities across the solution
Architecture translates requirements into major components and their connections. A layered view can separate presentation, application logic and data responsibilities, making deployment and integration choices visible. Centralised and distributed arrangements create different consequences for performance, resilience, security, administration and change.
An architectural diagram should explain responsibilities and interfaces rather than display unconnected technology logos.
Model data from business meaning
Data design identifies the entities, attributes, identifiers and relationships needed to support requirements. Names and rules should come from stakeholder meaning and process evidence.
Cardinality expresses how instances can relate, while keys distinguish records and connect them. Redundant storage can create inconsistent updates; overcompressed models can hide real distinctions. Architecture and data must be reviewed together because integration, privacy, retention, access and migration depend on where information is created, stored and exchanged.
What this chapter covers
- 01
Presentation, application and data responsibilities
- 02
Centralised and distributed architecture tradeoffs
- 03
Components, interfaces, deployment and integration boundaries
- 04
Entities, attributes, identifiers and relationships
- 05
Cardinality, keys and data integrity
- 06
Privacy, access, retention and migration consequences
Worked example · free
Place responsibilities for a booking service
- 3Separate presentation, logic and data responsibilities.
- 2Treat identity as an integration boundary.
- 2Ask relationship and privacy questions.
- 1Name one architectural risk.
Key terms
- Architecture
- The major solution components, responsibilities, interfaces and deployment relationships that shape system operation.
- Presentation Layer
- The part of a solution responsible for user interaction and display.
- Application Logic
- Rules and coordination that transform input into system behaviour and outcomes.
- Entity
- A distinguishable business concept about which the system records data.
- Primary Key
- An attribute or set of attributes that uniquely identifies an entity instance.
- Cardinality
- A rule stating how many instances of one entity may relate to another.
- Data Integrity
- The accuracy, consistency and valid relationships of data throughout its lifecycle.
Architecture and Data Modelling FAQ
Why use architectural layers?
Layers make responsibilities and interfaces easier to reason about. They can reduce coupling and support different deployment or change decisions. They are not automatically beneficial; excessive separation can add complexity, latency and operational overhead without solving a requirement.
What belongs on an architecture diagram?
Show components or layers, their responsibilities, meaningful interfaces and relevant external systems or deployment boundaries. Add technology names only when they support the decision. Every line should express a relationship the reader can explain, not decorative connectivity.
How are entities found?
Begin with requirements, process language, documents and business rules. Candidate nouns can help, but meaning and persistence matter more than grammar. Confirm definitions with stakeholders, identify unique instances, and separate concepts that have different attributes, relationships or lifecycles.
Why review privacy with architecture and data?
Privacy depends on what data is collected, where it travels, who can access it, how long it remains and how it is removed. Those are architectural and data decisions. A general privacy statement cannot substitute for tracing sensitive information across components and interfaces.
Exam move
Take a small system and write responsibilities before drawing boxes. Separate interaction, business rules, data management and external services, then connect only interfaces required by a use case. For each connection, state the data exchanged, trust boundary, failure effect and owner. Compare a centralised and more distributed deployment using performance, resilience, security, maintainability and team capability.
Avoid claiming one is universally superior. Build a data glossary from the same requirements. Define each entity in one sentence, choose identifiers, add attributes and state relationship cardinalities in plain language. Test the model with creation, update and deletion scenarios, including what happens when a related record is absent.
Mark personal or sensitive fields and trace collection, access, transfer, retention and deletion. Then introduce a requirement change and identify affected components, interfaces, entities and migration work. Finish by explaining the diagram without naming technology products. If the design cannot be justified from responsibilities and constraints, the product label is hiding the reasoning.
Use peer walkthroughs to find ambiguous arrows, unowned rules and data duplicated without a clear source of truth.
Working through Architecture and Data Modelling in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Architecture and Data Modelling question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.