SOA – Design Time Governance intro

1

Agenda

l Services recapl Design-time Governancel Quiz

2

3

4

The Value of SOA Delivered

Why is SOA Governance so special?

l Many more working parts than before l easy to lose track of, less secure.l SOA – building tomorrows legacy systems, today!

l Interoperability - no such thing as an isolated change.

l Reuse - we must avoid the 'build it myself' mentality - lack of trust and confidence.

l Other reasons?

5

Design-time governance

<footer>

Agenda

● Policies● H2A Policy Guideline Examples● A2A Policy Guideline Examples● ACS Policy Guideline Examples● CS Policy Guideline Examples

● Policy enforcement quiz

7

Policy per categoryExample rules per service category

8

Example Policy Rules for H2A services

● A service shall have one named owner● A service shall provide documented business value● A service shall do one only thing, and one thing well● A H2A service (webpart or portlet) shall be an

independent component● A H2A Service (webpart or portlet) shall be a part of a

bigger whole, not trying to dictate other H2A services● A H2A service shall not have internal workflow● Too generic webparts or portlets shall be avoided

9

Example Policy Rules for A2A services

● A service shall have one named owner● A service shall provide documented business value● A service shall do one only thing, and one thing well● A service shall be categorized (SOA category)● A service shall have an "authentication, authorisation,

endpoint strategy"● A service shall document its Service Level Agreement

SLA (response time, availabillity++)● A service shall have a documented coupling to the

contractual and requirement for service usage

10

Example Policy Rules for Aggregated Core services

● A service shall have one named owner● A service shall provide documented business value● A service shall do one only thing, and one thing well● A service shall be categorized (SOA category)● A service shall have a version strategy ● A service shall provide for audit and monitoring

of service usage● A service shall have an "authentication, authorisation,

endpoint strategy"● A service shall document its Service Level Agreement

SLA (response time, availability++)● (response time: <30ms, availability: 99.995%)

11

Example Policy Rules for Core services

● A service shall have one named owner● A service shall provide documented business value● A service shall do one only thing, and one thing well● A service shall be categorized (SOA category)● A service shall provide at least one Evolving Service

Endpoint● A service shall have a version strategy ● A service shall provide heartbeat and traffic monitoring● A service shall have an "authentication, authorization, endpoint

strategy"● A Core service shall have orthogonal functionality● A service shall document its Service Level Agreement SLA

(response time, availability++)● (response time: <30ms, availability: 99.995%)

12

Policy enforcement quizReal-world example: problem & resolution

13

Case: Project-service which need to add resource data

l Given a ProjectRepositoryService (CS) which deliver project data form the project database...

l New requirement: A new client/service wish to display the project along with its resources..

14

Case: Project-service which need to add resource data

l Given a ProjectRepositoryService (CS) which deliver project-data form the project database...

l New requirement: A new client/service wish to display the project along with its resources..

Alternative 1: Extend ProjectRepositoryServices with methods to return projects with its resources

l Alternative 2: Create a ProjectResource ACS-service which embed resources from ResourceReositoryService to the data from ProjectRepositoryService

15

Case: discussion

l Alternative 1 is the fastest and cheapest – but..l Policy violations:

l A service shall do one only thing, and one thing welll We might see duplication of ResourceRepositoryService functionality in

ProjectRepositoryServicel Will a resource form ProjectRepositoryService be compatible with a resource

fromResourceRepositoryService?l How do we split the responsibility between ProjectRepositoryService and

ResourceRepositoryService? (Look at access control, cashing, data mastering..)l A Core service shall have orthogonal functionality.

16

if(!Totto){ string explanation = HttpGet(http://en.wikipedia.org/wiki/Orthogonal); Console.Write(explanation);}

Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system. The emergent behavior of a system consisting of components should be controlled strictly by formal definitions of its logic and not by side effects resulting from poor integration Orthogonality reduces testing and development time because it is easier to verify designs that neither cause side effects nor depend on them.

Case: more discussions

ResourceRepositoryService does not have a “natural” access to the project database whereas ProjectRepositoryService has.

l Alternative 1: make the project-domainobject contain an id-list.l Alternative 2: make ResourceRepositoryService query the

projectdatabasel Alternative 3: make ProsjektRepositoryService be responsible for

coupling of the two Core Services.

l How do you approach data sources without “sensible” object IDs, i.e.

l Only internal GUIDs?l Construct logical IDs?

17

A Quick Note on Testing

• Without trust, SOA is doomed to fail: • People start creating their own services.• SOA Projects fail!

• Trust comes from reliability: • Reliability attained by validating and functionally verifying each

and every critical component!• Proper governance dictates that these tests must pass before

service promotion is allowed in the registry.

• Consider automated testing of services as a major part of SOA Governance.

18

Starting out?

● Start small!

● Know your SOA entry point and the associated strategy.

● Define your human roles.

● Set your rules up before you start deploying things into production!

● Remember that you cannot buy a SOA or SOA Governance!

19

Takk for oppmerksomheten!

20

How to Govern

21

Evaluate yourself first…

● What are you governing?● What integration strategy? ● What domain and system complexity?

● Who are in your legislative branch?● Internal Architect(s)?● Random consultant(s)?

● What are your resources for judicial enforcement?● Internal Architect(s) / IT Director / IT Department / Business Owner /

Process Owners?● Who are in your executive branch?

● Do developers change every 4 years or every project?● How often do YOU change?● You have self-service so all your end-users are executing..

22

Your size and resources matter

● Small/Mid-sized:● Hire external developers and/or architects● May suffer from ”every vendor – new solution”● Consider teaming up on verticals

● Enterprise:● Usually developers and architects in-house● May hire external developers ● Should establish own legislation● May hire external ”judicial branch” (QA)● Larger amount of services (100-600)● Greater domain complexity

23

Service Audit

● Monthly audit on all services● SLA● Brukshyppighet● Enkle sjekklister for tjenster på de forskjellige

tjenestekategoriene for at tjenestene overholder policy.● Gjennomgå road-map for tjenesten● Gjerne gjort med hjelp av 3rd party

● Evangilisere hvilken forretnings verdi policy reglene vil gi på tvers av organisasjon.

● Policyene må tilgjengeliggjøres dokumenteres på ett format som er lett å forstå og forholde seg til.

24

Common Governance Tips

● Organizational: ● Create a board of review. ● Communicate early and often. ● Establish COEs (centers of excellence).

● Architectural: ● Don’t get too granular.

● Technical: ● Develop an interoperability framework first. ● Create policies with teeth.

“..creating anSOA demands more than using SOA based tools. It requires that IT organizations make serious choices about design, which results in design rules.”

- Phillip J. Windley

25