Is een service geintroduceerd en is de inhoud actueel dan wordt men voor een volgende uitdaging gesteld, namelijk hoe ga jer ervoor zorgen dat de inhoud wordt hergebruikt. Daarbij zijn drie vragen van belang:

• Wie bepaald of een bepaalde service herbruikbaar is
• Wanneer wordt bepaald of een project van herbruikbare services gebruik gaat maken
• Wat heeft diegene nodig om de keuze te kunnen maken.

Over de eerste vraag kan ik kort zijn, als je deze analyse laat doen door een ontwikkelaar dan ben je te laat. Al in een vroeg stadium van een ontwikkeltraject zul je moeten gaan kijken naar de herbruikbaarheid van services. Services zijn uiteindelijk business resources en analyse hiervan moet dus of bij een business analist of bij een enterprise architect liggen.

Op de tweede vraag is hierdoor het antwoord ook al duidelijk, namelijk zo vroeg mogelijk in het proces, dus of bij het doen van de analyse of bij het opstellen van de  architectuurdocumenten voor een project of programma. Zeker omdat  er inhoudelijke
kennis nodig is om te kijken naar wat de informatiebehoefte is van de functionaliteit in het project, daarnaast wat de informatie inhoud is van de bestaande reeds aanwezige services.

De laatste vraag is te relateren aan de eerste twee. Het gaat om functionele personen in de eerste stadia van een project. Dat betekent dat men met name op zoek is naar functionele besschrijvingen van de services of componenten. Aan XSD's, WSDL's en WS-Policy bestanden hebben deze mensen veelal weinig omdat deze te technisch van aard zijn. Er zijn wat mogelijkheden om ervoor te zorgen dat er in deze XML bestanden documentatieregels zijn opgenomen of men kan zoeken naar een goede viewer voor deze bestandsformaten. Punt blijft dat een functionele beschrijving gewenst is voor de juiste ondersteuning.

In grote organisaties betekent dit dat er veelal ontwerpdocumenten of servicebeschrijvingen opgesteld worden die gebruikt kunnen worden. Andere oplossing is dat gewerkt wordt met een wiki opzet waarin beschrjving van de services is opgenomen. Laatste te noemen scenario is de inzet van architectuur tools waarin naast de services ook de andere enterprise elementen beschreven worden.

Als voorbeeld van de eerste variant zijn een aantal sjablonen opgenomen van voorbeelden van ontwerpdocumenten onder het document register menu, op de tweede variant en derde variant kom ik later terug.