Operazione: Analisi processo del business
Questa attività identifica gli elementi di progettazione di una soluzione orientata al servizio in termini di servizi e partizioni e documenta la specifica iniziale di tali servizi.
Discipline: Analisi e progettazione
Scopo
  • Identificare gli elementi di progettazione di una soluzione orientata al servizio in termini di servizi e partizioni.
  • Documentare la specifica iniziale dei servizi.
  • Determinare le dipendenze iniziali e la comunicazione tra i servizi.
Relazioni
Descrizione principale

Questa attività utilizza i modelli di elaborazione del business come input e identifica un insieme di servizi candidati che sono inclusi nel portafoglio del servizio di progetto. Questi servizi candidati potrebbero ancora richiedere un altro raffinamento, tuttavia, le fasi qui incluse forniscono un metodo efficace nel quale produrre un insieme iniziale di Risorsa: Specifica del servizios.

Passi
Identificazione dei servizi candidati dal processo di business

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.

Il diagramma viene descritto nel contenuto testuale.

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.

 Illustrazione del formato tabulare



Ulteriori informazioni