Nella discussione sull'allineamento del business dei servizi nella linea guida Linea guida:
Servizio è stata discussa la connessione tra i modelli del business e l'identificazione del servizio. In generale,
questo approccio fornisce una connessione molto stretta tra gli stackholder/utenti e l'organizzazione IT che implementa
i servizi consentendo alle operazioni del servizio di supportare direttamente le attività identificate nei modelli del
processo. In generale, i modelli del processo del business si focalizzano su attività eseguite da ruoli e/o da risorse
in un'organizzazione per realizzare alcuni obiettivi, di solito per fornire il valore in forma di prodotto o di
servizio ad una parte esterna come un utente o un partner. Il processo generale è quindi un insieme ordinato di tali
attività, possibilmente scomposte in sottoprocessi. Ha modelli di organizzazione, risorse e dati associati, per
catturare tutti gli aspetti del processo includendo non solo i ruoli in esecuzione, ma risorse richieste/utilizzate,
proprietà di risorse, contabilità, definizioni di elementi passati all'interno ed all'esterno delle attività e così
via. LaConcetto: Decomposizione del processo di business descrive come raggiungere un
livello di descrizione di un modello del processo di business al quale è possibile identificare i servizi candidati,
come mostrato nell'esempio di seguito riportato. In base al livello di granularità di Risorsa:Modello del caso d'uso del business, potrebbe essere
necessario raffinare i casi d'uso del business, per essere in grado di raggiungere il
livello di decomposizione nel quale può essere prodotto un modello utile del processo.
Quanto segue illustra un modello di processo molto semplice utilizzando WBIM (WebSphere Business Integration Modeler)
IBM.
In questo caso, ogni corsia orizzontale rappresenta un ruolo particolare che esegue le attività nel processo. Il
processo inizia con un cerchio verde, termina con il cerchio rosso e con i dati che fluiscono tra alcune attività (in
forma di richiesta di prestito). Questo processo, se ovviamente è futile e inventato, dimostra però l'alto livello
delle attività. Dal punto di vista del business potrebbero essere azioni atomiche, ma ovviamente richiederebbero alcuni
passi se scomposte al livello IT. In generale, nello sviluppo sul componente, si tratterebbe poi ciascuna attività
singola dalla vista del business come un caso d'uso nella vista IT e la si scomporrebbe in insiemi di componenti e
classi per formare l'implementazione del caso d'uso.
In una soluzione orientata al servizio, il servizio viene identificato ad un livello simile di granularità. Si suppone
comunemente che le operazioni su una specifica di servizio corrisponderanno a 1:1 con le attività atomiche identificate
in un modello di processo del business. Se questo è un approccio attraente e potrebbe, se eseguito con attenzione,
realizzare i giusti risultati, tende anche a condurre all'ipotesi che una volta identificati i servizi, potrebbero
essere direttamente implementati come descritti nel modello del processo. In modo specifico ogni ruolo (corsia)
diventerà un servizio denominato con ogni attività all'interno di uno corsia creata come un'operazione sul servizio
corrispondente, come può essere visualizzato nel seguente diagramma.
Ciò che questo approccio sbaglia a prendere in considerazione è che vi sono dei requisiti non funzionali che
influenzano il tipo di servizio da sviluppare, le operazioni di modo vengono identificate sui servizi e così via. Il
livello di dettaglio di solito catturato da tali tool non riesce in modo soddisfacente a catturare sicurezza, qualità
del servizio e politiche di gestibilità, ad esempio. Trasformando il processo in un insieme di specifiche di servizio
candidate in un modello di servizio si fornisce un punto di partenza, ma dovrebbe essere considerato solo come
punto di partenza da cui viene eseguita un ulteriore analisi prima che il modello di progettazione venga sviluppato,
che descrive l'implementazione reale. Quindi tutti questi servizi dovrebbero avere lo stato impostato su 'candidate',
come è possibile vedere nella vista delle proprietà di Rational Software Modeler.
Rappresentazione alternativa
Quando viene utilizzato un formato più incentrato sul documento per il modello del servizio, potrebbe essere più
appropriato catturare l'associazione tra le attività del processo ed il servizio utilizzato un modulo tabulare.
L'esempio di seguito riportato dimostra questo possibile formato.
|