Policy Advisory Board

Policy Advisory Board is a specialized Center of Excellence organ, focusing on the round trip of keeping the design-time governance policies aligned with the company goals, people and competences.

See also [Governance] for more details on Governance.

P.A.B. Meeting

Participants

IT Manager
Company Chief Architect
Service Owner
Project Lead Architect
Central PAB-issue stakeholders

PAB Meeting Agenda

Intro PAB
Presentation of the PAB issue
Stakeholder analysis

Example Service Policy QA meeting

Agenda

Presentation of the H2A Services [MyCustomer H2A Services]
Policy QA of each of the services
- Design-Time Governance for H2A Services
- Design-Time Governance for A2A Services
- Design-Time Governance for ACS Services
- Design-Time Governance for CS Services
- If non conformance
  - if the team challenges the policy
    - register issue i Jira PAB project
  - if the team accepts the non-conformance as a design/implementation flaw
    - create plan for compliance
New policy suggestions
- Document as Jira PAB issue
- New rules is documented with the terms from RFC2119 (MUST/SHOULD/CAN etc)
Aggregated conclusion from the QA process

SOA Design rules

Policy Rules for Human to Application Services (H2A)

P1. A service shall have one named owner	P1. A service shall have one named owner	P2. A service shall provide documented business value	P2. A service shall provide documented business value	P20. All services shall be in the service universe
P21. A service shall be categorized (OW SOA category)	P3. A service shall do one only thing, and one thing well	P3. A service shall do one only thing, and one thing well	P4. A H2A service (webpart or portlet) shall be an independent component	P4. A H2A service (webpart or portlet) shall be an independent component
P41. A service shall provide heartbeat and traffic monitoring	P5. A H2A Service (webpart or portlet) shall be a part of a bigger whole, not trying to dictate other H2A services	P5. A H2A Service (webpart or portlet) shall be a part of a bigger whole, not trying to dictate other H2A services	P6. A H2A service shall not have internal workflow	P6. A H2A service shall not have internal workflow
P7. Too generic webparts or portlets shall be avoided	P7. Too generic webparts or portlets shall be avoided	P90. A service shall have a documented coupling to the contractual and requirement for service usage	P90. A service shall have a documented coupling to the contractual and requirement for service usage

Policy Rules for Application to Application Services (A2A)

P1. A service shall have one named owner	P1. A service shall have one named owner	P2. A service shall provide documented business value	P2. A service shall provide documented business value	P20. All services shall be in the service universe
P20. All services shall be in the service universe	P21. A service shall be categorized (OW SOA category)	P22. A service shall have an "authentication, authorisation, endpoint strategy"	P23. A service shall document its Service Level Agreement SLA (response time, availabillity++)	P3. A service shall do one only thing, and one thing well
P3. A service shall do one only thing, and one thing well	P30. A service shall have a versioning strategy (ACS, CS)	P31. A service shall provide for audit and monitoring of service usage	P31. A service shall provide for audit and monitoring of service usage	P41. A service shall provide heartbeat and traffic monitoring
P90. A service shall have a documented coupling to the contractual and requirement for service usage	P90. A service shall have a documented coupling to the contractual and requirement for service usage

Policy Rules for Aggregated Core Services (ACS)

P1. A service shall have one named owner	P1. A service shall have one named owner	P2. A service shall provide documented business value	P2. A service shall provide documented business value	P20. All services shall be in the service universe
P20. All services shall be in the service universe	P21. A service shall be categorized (OW SOA category)	P22. A service shall have an "authentication, authorisation, endpoint strategy"	P23. A service shall document its Service Level Agreement SLA (response time, availabillity++)	P3. A service shall do one only thing, and one thing well
P3. A service shall do one only thing, and one thing well	P30. A service shall have a versioning strategy (ACS, CS)	P30. A service shall have a versioning strategy (ACS, CS)	P31. A service shall provide for audit and monitoring of service usage	P31. A service shall provide for audit and monitoring of service usage
P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)	P32. A service shall document its Service Level Agreement SLA (response time=30ms, availabillity=99.995%)	P40. A service shall provide at least one Evolving Service Endpoint	P41. A service shall provide heartbeat and traffic monitoring	P41. A service shall provide heartbeat and traffic monitoring
P90. A service shall have a documented coupling to the contractual and requirement for service usage	P90. A service shall have a documented coupling to the contractual and requirement for service usage

Policy Rules for Core Services (CS)

P1. A service shall have one named owner	P1. A service shall have one named owner	P2. A service shall provide documented business value	P2. A service shall provide documented business value	P20. All services shall be in the service universe
P20. All services shall be in the service universe	P21. A service shall be categorized (OW SOA category)	P22. A service shall have an "authentication, authorisation, endpoint strategy"	P23. A service shall document its Service Level Agreement SLA (response time, availabillity++)	P3. A service shall do one only thing, and one thing well
P3. A service shall do one only thing, and one thing well	P30. A service shall have a versioning strategy (ACS, CS)	P30. A service shall have a versioning strategy (ACS, CS)	P31. A service shall provide for audit and monitoring of service usage	P31. A service shall provide for audit and monitoring of service usage
P32. A service shall document its Service Level Agreement SLA (response time=30ms, availability=99.995%)	P32. A service shall document its Service Level Agreement SLA (response time=30ms, availabillity=99.995%)	P40. A service shall provide at least one Evolving Service Endpoint	P40. A service shall provide at least one Evolving Service Endpoint	P41. A service shall provide heartbeat and traffic monitoring
P41. A service shall provide heartbeat and traffic monitoring	P42. A Core service shall have orthogonal functionality	P42. A Core service shall have orthogonal functionality	P90. A service shall have a documented coupling to the contractual and requirement for service usage	P90. A service shall have a documented coupling to the contractual and requirement for service usage

Home

Resources

Space Information

Page Operations

Browse Space