Skip to content

PAB

| | 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. This content is build on content from http://wiki.community.objectware.no

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

Content is moved to Service Categories

SOA Design rules

Policy Rules for Human to Application Services (H2A)

P1. A service shall have one named owner P2. A service shall provide documented business value P21. A service shall be categorized (OW SOA category) P3. A service shall do one only thing, and one thing well 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 P6. A H2A service shall not have internal workflow 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

Policy Rules for Application to Application Services (A2A)

P1. A service shall have one named owner 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) 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 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

Policy Rules for Aggregated Core Services (ACS)

P1. A service shall have one named owner 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) 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 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
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 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) 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 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 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