Model RACI

Model RACI de la plataforma EventHub

Navegació

⬅️ Cicle de vida dels recursos	Model de decisió i escalat ➡️

---

Marc general

El model RACI estableix de manera formal la distribució de responsabilitats entre els diferents rols implicats en la gestió dels recursos de la plataforma EventHub.

Aquest model garanteix claredat en l’execució, validació i comunicació de les activitats crítiques.

Nota sobre l’operació segons entorn

La columna Operadors recull la responsabilitat tècnica d’execució i suport. Segons el Model de Govern, aquest rol l’assumeix:

• CPD4 en entorns on-premise.
• La Oficina EventHub en entorns cloud (AWS i Azure).

Per simplicitat, el valor de la cel·la a la matriu és el mateix per a tots dos entorns: el que canvia és qui executa físicament la tasca, no la responsabilitat assignada.

La columna Oficina EventHub recull exclusivament el rol de govern, validació i coordinació transversal, independentment de l’entorn.

Nota sobre activitats desdoblades

Les activitats de gestió de recursos (topics, schemes, connectors, ksqlDB/Flink) es desdoblen en dues files complementàries per evitar ambigüitats:

• Sol·licitud funcional (Xa): el propietari defineix què necessita i per què. És el responsable funcional del recurs.
• Execució tècnica (Xb): l’operador executa físicament el desplegament. El propietari queda com a consultat per confirmar requisits.

L’Oficina EventHub és l’Accountable a totes dues files perquè manté la responsabilitat de govern sobre el cicle complet del canvi.

---

Matriu de responsabilitats

#	Activitat / Recurs	Propietaris (equip d’aplicació)	Operadors (CPD4 on-prem / Oficina EventHub cloud)	Oficina EventHub	Seguretat / Ciberseguretat	CTTI – Arquitectura corporativa
1	Definició funcional de l’esdeveniment	R/A	I	C	I	I
2a	Alta de topics – sol·licitud funcional	R	I	A	C	I
2b	Alta de topics – execució tècnica	C	R	A	I	I
3a	Modificació / versionat de topics – sol·licitud funcional	R	I	A	C	I
3b	Modificació / versionat de topics – execució tècnica	C	R	A	I	I
4a	Baixa / deprecació de topics – sol·licitud funcional	R	I	A	C	I
4b	Baixa / deprecació de topics – execució tècnica	C	R	A	I	I
5a	Definició i evolució d’esquemes – sol·licitud funcional	R	I	A	C	C
5b	Definició i evolució d’esquemes – execució tècnica	C	R	A	I	I
6a	Alta i configuració de connectors – sol·licitud funcional	R	I	A	C	C
6b	Alta i configuració de connectors – execució tècnica	C	R	A	I	I
7	Desenvolupament ksqlDB / Kafka Streams / Flink	R	I	A	I	I
8a	Alta / modificació / baixa de ksqlDB / Flink – sol·licitud funcional	R	I	A	C	C
8b	Alta / modificació / baixa de ksqlDB / Flink – execució tècnica	C	R	A	I	I
9	Gestió de productors i consumidors	R	I	A	I	I
10	Gestió d’accessos a recursos	C	R	A	C	C
11	Monitoratge tècnic de la plataforma	I	R/A	C	I	I
12	Anàlisi i resolució d’errors funcionals	R/A	I	C	I	I
13	Gestió d’incidències tècniques	C	R	A	I	I
14	Validació de canvis i excepcions	C	I	R/A	C	C
15	Auditoria i compliment de seguretat	I	I	R/C	A	I

---

Llegenda

• R — Responsible
  Executa la tasca i assegura la seva correcta implementació.

• A — Accountable
  Té la responsabilitat final de validació. Tota activitat ha de tenir exactament un A.

• C — Consulted
  Ha de ser consultat abans de prendre una decisió o executar l’activitat.

• I — Informed
  Rep informació sobre l’activitat un cop finalitzada.

ℹ️ Quan un mateix rol assumeix l’execució i la decisió final, s’indica com R/A (per exemple, en activitats internes al propi equip propietari).