IT4IT Functional Components and Data Objects
Domain 3 tests functional components and data objects as the architecture's building blocks. A functional component is a logical capability that performs activities and manages one or more data objects. It is not automatically an application, a team, or a process; one tool may support several components, and one component may be implemented by several tools. Data objects are the durable business entities exchanged between components, and they carry lifecycle states and relationships. The exam expects you to trace how a data object moves across value streams and which component is accountable for each state.
Core rules
- Components expose and consume data objects through interfaces; integration is defined at the data level.
- Common objects include Service, Service Offering, Service Contract, Requirement, Change, Configuration Item, Release, Deployment, Incident, Problem, Event, and Knowledge Article.
- Data objects have identities, states, and links; for example, an incident links to a service and affected CIs.
- The service is the anchor object: offerings, contracts, requirements, changes, incidents, and costs should trace back to it.
- A component may own a data object's lifecycle without owning every activity that references it.
Worked example
An incident is raised against a service. The Incident Management component records the incident and links affected CIs. Problem Management consumes related incidents to create a problem. Change Management links the resulting change to the CIs and release. The reasoning: each component adds or updates a data object while preserving traceability, rather than creating isolated records.
Traps
Do not equate a functional component with a product name. Do not model data objects as unstructured tickets. Do not ignore state transitions and ownership. Do not assume every component needs its own database; shared data and interfaces are central.