SOA Governance

1
The Value of SOA Delivered
Microsoft Application Platform Conference 11.
April 2007 Mads Nissen Totto Objectware AS
2
SpeakerBio

• Totto

• Mads Nissen

• President i javaBin siden 1998
• Sun Java Champion
• Community Leader, java.net
• Sjefskonsulent i Objectware
• Arkitekt, utvikler, mentor
• J2EE siden 1997, J2SE/J2ME, AOP, Jini/JavaSpaces,
  UML, RUP, Agile
• Programmert professionellt i over 25 år
• Sivilingeniør fra NTH/NTNU
• ... og mye mye mer... ?

• Teamleder i Objectware
• Arkitekt, utvikler, teknologisk kverulant
• MOSS (Sharepoint)
• SOA
• .NET C
• Workflow
• Microsoft Most Valuable Professional 05/06
• Bachelor Computer Science

3
Agenda

• Justification for SOA
• Integration strategy and the challenge SOA might
  bring
• Categorizing Services
• Gain control and overview
• How about products?
• Governance Policy
• Guidelines Examples
• Case to test your attention
• Demo to prove the value

4
SOA in Objectware

• Objectwares approach to Service Orientation and
  Architecture

5
What is Enterprise Design Architecture?

• No non-sense
• Enterprise Architecture
• Domain Driven Design
• Service Oriented Architecture
• Enterprise SOA Patterns
• Code (reusable starting points)
• How IT fits together
• From EA, to SOA categorized services, realized
  using documented patterns and deployed on both
  .NET and Java in real projects.

6
SOA i Objectware

• Vi har utviklet tjeneste-orienterte systemer i
  lang tid
• SOA hypen gikk fra arkitektur til XML og WS-
  fokus (definisjon)
• Ingen ser ut til å vite hva en tjeneste var..
• Så vi fokuserte på atomet i SOA, nemlig
  tjenesten....
• ..og det var ikke lett å få på plass....

The Eight Fallacies of Distributed Computing
7
Justification FOR SOA

• Some points to the challenge for successful SOA
  today

8
Integration challenges
Product
Product
Customer
Customer
9
(No Transcript)
10
Maturing SOA - Problems

• Gartner Strategic Planning Assumption
• In 2006, lack of working governance mechanisms in
  midsize to large (more than 50 services),
  post-pilot SOA projects will be the most-common
  reason for project failure (0.8 probability).

10
11
Categorizing Services

• The Service Manifest and the Categorization
  Framework

12
The Service Manifest

• I shall do one thing and one thing well.
• I shall never fail and if I do I will do it
  gracefully.
• I shall provide great service.

13
(No Transcript)
14
(No Transcript)
15
Categorizing products

• Services never walk alone

16
Product focus vs. Service focus

• A common challenge when doing Service
  categorization is how to align products into the
  model
• Products are often dominant in discussions around
  integration architecture
• Makes it hard to establish clear policy for
  services
• And sometimes products even exposes their own
  services!
• Products in a SOA context tend to grasp too much
  of the domain
• What processes should a product support?
• Should my CRM system store my Invoices or
  Documents?
• Should my document management system be the
  master of Products?
• We must harvest as much value from products as
  possible
• Accounting work very efficiently in the ERP
  system!
• Sales get great support from the CRM system!
• We need a clear understanding and separation of
  what is solved by products and what is solved by
  services

17
Microsoft CRM 3.0 in SOA Context
Service Context
Product Context
KundeOversikt
18
Governance

• Some words on the value of governing

19
Governing the Universe

• Governing the service universe requires
• A referenceframe (i.e. the categories)
• A clear definition of the responsibility of your
  pawns (services service owners)
• Strategies for capturing new land and nations
  (new markets)
• Remember that complex laws are more often broken.
  School and adapt not police
• Example
• Services not in compliance must use A2A layer for
  interaction (i.e. Context-Crossover)

20
Policy

• Policy are the laws that regulate your service
  universe
• Legislative authority establishes the policies
• For example a Policy Advisory Board (Center Of
  Excellence)
• Policy is enforced by a judicial authority
• For example with Policy Audits (manual/automatic)
• Legislature must enable judicial authority to
• Locate possible policy violations
  (manually/automatic)
• Judge wether or not it is a violation
• Efficient policy is required to enable efficient
  government

21
Governing the Run-Time

• Often referred to as Application Management or
  SOA Service Management
• Governing the run-time services requires
• Some base monitoring policy for services at each
  category
• Proper tooling which must adapt to the universe
• Monitoring clients interaction with the service
  is valuable
• Example
• All Core Services must interface agains Microsoft
  Operations Manager for health monitoring

22
How to Govern
23
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..

24
Your size and resources matter

• Small/Midsized
• 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

25
Policy per category

• Example rules per service category

26
Example Policy Rules for H2A services

• Alle tjenester må ha EN navngitt eier
• Alle tjenester skal gi forretningsverdi
• Alle tjenester skal gjøre en ting og en ting godt
  
• En tjeneste (webpart/portlet) skal være en
  selvstendig komponent
• En tjeneste (webpart/portlet) skal være en del av
  et større fellesskap, ikke forsøke å diktere
  andre.
• H2A arbeidsflyt er portalen/arbeidsflytsmotoren
  sitt ansvar, og ikke webparten/portletten/tjeneste
  n sitt ansvar
• Webparts/portlets som er for generiske flytter
  bare kompleksiteten ut i konfigurasjon som
  reduserer kvalitet og skal unngås

27
Example Policy Rules for A2A services

• Alle tjenester må ha EN navngitt eier
• Alle tjenester skal ligge i en tjeneste katalog
• Alle tjenester skal gi forretningsverdi
• Alle tjenester skal gjøre en ting og en ting godt
  
• Alle tjenester skal være kategorisert (OW SOA
  kategori)
• Alle tjenester skal ha ett "authentication/authori
  sation/endpoint strategi"
• Alle tjenester skal dokumenteres med en Service
  Level Agreement SLA innenfor lag (respons tid,
  oppe tid)

28
Example Policy Rules for Aggregated Core services

• Alle tjenester må ha EN navngitt eier
• Alle tjenester skal gi forretningsverdi
• Alle tjenester skal gjøre en ting og en ting godt
  
• Alle tjenester skal ha en versjonerings strategi
  (ACS, CS)
• Skal etableres en prosess for monitorering av
  bruk av tjenester
• Alle tjenester skal ha ett "authentication/authori
  sation/endpoint strategi"
• Alle tjenester skal dokumenteres med en Service
  Level Agreement SLA
• respons tid lt30ms
• oppe tid 99.995)

29
Example Policy Rules for Core services

• Alle tjenester skal gjøre en ting og en ting godt
  
• Alle tjenester må ha EN navngitt eier
• Alle tjenester skal ha minst et Evolving Service
  Endpoint
• Alle tjenester skal ha både heartbeat og
  trafikkrapportering
• Alle tjenester skal ha ett "authentication/authori
  sation/endpoint strategi"
• Alle tjenester skal dokumenteres med en Service
  Level Agreement SLA
• respons tid lt30ms
• oppe tid 99.995)
• Core services skal ha sterk ortagonal
  funksjonalitet

30
Techology per Category

• Suggestions and guides

31
Summary technology/strategy(Java technology)
32
Summary technology/strategy (Java technology)
33
Summary technology/strategy(.NET technology)
34
Summary technology/strategy (.NET technology)
35
Policy enforcement quiz

• Real-world example problem resolution

36
Case Prosjekt-tjeneste med behov for ressurser

• Man har en ProsjektRepositoryService (CS) som
  leverer prosjekter fra prosjektdatabasen
• Nytt krav En ny klient/tjenste ønsker å vise
  prosjektene med tilhørende ressurser.
• Alternativ 1 Man utvider ProsjektRepositoryServi
  ces med metoder som returnerer prosjekter med
  tilknyttede ressurser
• Alternativ 2 Man lager en ProsjektRessurs
  ACS-tjeneste som kobler sammen informasjon fra
  ProsjektRepositoryService og ResourceRepositorySer
  vice

37
Case diskusjon

• Alternativ 1 er raskeste vei til mål men
• Policy brudd
• En tjeneste skal gjøre en ting og en ting godt
• Her vil man potensielt få duplisering av
  ResourceRepositoryService funksjonalitet i
  ProjectRepositoryService
• Vil en resource fra ProjectRepositoryService være
  kompatibel med en ressurs fra ResourceRepositorySe
  rvice?
• Hva blir ansvarsfordelingen mellom
  ProjectRepositoryService og ResourceRepositoryServ
  ice når det gjelder tilgangstyring/cache
  strategier m.m.?
• CS tjenester skal ha orthogonal funksjonalitet.

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.
38
Case videre diskusjon

• ResourceRepositoryService har ikke naturlig
  tilgang til prosjektdatabasen, men
  ProjectRepositoryService har.
• Alternativ 1 La prosjekt-domene objektet
  inneholde en id-liste
• Alternativ 2 La ResourceRepositoryService spørre
  i projectdatabasen
• Alternativ 3 La ProsjektRepositoryService være
  ansvarlig knytningene mellom de to CoreServicene.
• Og hva med kilder som ikke har fornuftige IDer,
  f.eks
• Kun interne GUIDs
• Konstruere logiske IDer?

39
DEMO

• Categorized Services in Action

40
Lorentzen Stemoco Arkitektur
Invoice
41
Form for contract management (H2A)

• Advanced form based on ASP.NET
• Attached to K2.net process
• Validation and dynamic rendering
• Advanced AJAX controls for better user experience

42
Sharepoint Workspace for Fixture
43
Process for contract registration

• Process in compliance with ISO certification
  standards
• Approved by Veritas
• K2.net Workspace
• Reports
• Status
• Same view as in process designer
• Timing on task execution against baseline
• Starting point for process optimization and
  measurement of ROI

44
A2A Invoicing
45
Key Takeaways

• Make a concious decision about your integration
  strategy
• Consider Service Categorization seriously if SOA
  is your current strategy, or might be in the
  future
• Consider your size and resources
• Have clear ROI goals
• Observe that a SOA strategy might have potential
  for your business if you do it right. The
  potential is in the processes and loosely
  coupled, high cohesive services

46
Takk for oppmerksomheten!

• Totto totto_at_objectware.no
• Mads mads_at_objectware.no
• Øystein oystein.garshol_at_objectware.no

Få med dere neste SOA Sesjon Developers have
always known how to deliver successful SOA!
47
Appendix