Workshop: Principles and Tools for SOA Governance

El rol de l'arquitecte:

• L'arqutecte és el rol que uneix [Desenvolupament] --- Arq --- [Negoci]
  

SDA (Software Development Asset)

• És software, models, codi, etc. + metadades associades: atributs, versions, etc.
• Distribució dels SDAs:
  [Application specificic Layer] 85%-100% ==> No adequat per reutilitzar
  [Domain dependant (negoci)] 20%-85% ==> Actius de gran valor
  [Domain independant layer (login per exemple)] 0%-20% ==> Actius de poc valor (implementats ja en .NET Enterprise Solution Patterns).

SOA (Service Oriented Architecture):

• SOA utilitza SDAs
• Granularitat de SOA?
  No ha de ser massa global (app layer). Exemple: Fer_Tancament_Anual.
  No ha de ser massa granular (domain layer). Exemple: crides a RPC.
  Per tant:
  El valor de SOA està al domain dependant.
  Per tant SOA no significa que haguem d'implementar totes les funcions orientades a servei.
  
• SOA no és exclusivament Web Services, pot haver-hi altres tecnologies (per exemple message based).
• Per especificar SOA utilitzarem, preferentement: Diagrames de classe, Casos d'ús, Diagrames d'activitat.
  Per gestionar SOA crearem models:
  Performance Reference Model.
  Service Components RM.
  Biz RM
  Data Access RM
  Technological RM
• El model inclourà una base de dades de SDA (SDA metadata library), que permeti:
  Guardar les definicions d'SDA i les metadades associades:
  Artifacts: work products, code, schemas, models, executables, etc.
  Classifiers: keywords, development efford, owner, language, etc.
  Relationships to other assets: Dependencies, prerrequisites, other assets versions
  Cercar-les
  Gestionar polítiques d'ús

Best practice 1: Sigueu pragmàtics quan definiu models/defincions de serveis

• Orientació bottom-up (des dels serveis més bàsics): masa específic, acabaríem creant massa serveis específics que serien codi spaguetti
• Orientació up-down (tot definit abans de fer res): caurem en la paràlisi per anàlisi
• Cal seguir un model en espiral on:
  Top-down: ens ajuda a prioritzar el que és més important pel negoci
  Bottom-up: ho subtituirem en la mesura que poguem per Software Patterns ja existents.
• Es recomana crear un equip d'arquitectes d'SDA en matriu a l'empresa:
  Cada equip té un responsable d'SDA
  Les seves responsabilitats són: identificar candidats, revisar proposats, publicar aprovats i recomanar futurs.

Best practice 2: Reviseu els serveis al llarg del clicle de construcció

• Cal crear "checkpoints" per alinar espectitatives entre els diferents actors implicats.
• Compte amb crear un procés poc complert (insuficient) o massa burocràtic (lent, impràctic o senzillament no se segueix). Equilibri a "just enough process".

Best practice 3: Gestioneu els serveis com si fossin productes

• Cal crear un release cycle ben definit
• S'ha de fer releases backward compatible
• Cal fer una presa de requeriments amb els clients actuals i potencials + Defect tracking
• Ha d'existir un rol de product manager, que alínia: [Developers] --- Product Manager --- [Biz]
• Cal fer versionatge
• Cal orientar-ho a gestió d'SDA (en desenvolupament, production, retired, obsolete).
• Recomanació: Branch as long as you can (http://www.perforce.com/perforce/bestpractices.html)

Best practice 4: Distribuïu mitjançant una gestió d'actius en una base de dades

• Cal utilitzar una eina ja que:
• Les spreadsheets i webs estàtiques queden obsoletes
• "Call the architect" crea un coll d'ampolla
• UDDI no és adequat per als desenvolupadors

Best practice 5: Traceu qui utilitza els components

• A nivell de projecte i rol dins el projecte.

Eines recomanades:

• Rational Architect (?) i Java Session Bean Modeler (?) per les especificacions
• Logidex per gestionar els SDAs.
• Tot i que crec que no ho he reflexat, la presentació va tenir un petit to comercial.