Typically, this should be
the rule rather than the exception, especially if the chosen strategy formulates an inclusive solution
for a number of services scheduled to start their life cycle at the same point in time. But the life
cycle timeframe aspect is not the only reason to bind services. An equally important motivation
is to take into consideration their affiliation within a business or technological environment and
their dependency on each other. These factors can contribute to service development during design
time, and later on, operation in production.
Exhibit 3.5 is an example of two services that share the same life cycle timeline because
their complementary functionalities bind them to the same life cycle. Without the client name and
address service it would be impossible to utilize the claims service when processing insurance
claims. Thus, the life cycle strategy should depict the services??™ mutual dependency by either
examining the context of their offerings or observing the timeframe they share.
Planning Service-Life Cycle Workflows 55
Run-Time Season
Service Life Cycle Timeline
Start End
Service Life Cycle Events S i L t
Service Life Cycle Continuous Disciplines yc vice C c v y Dis us D
u Design-Time Season
laims Servic C ce c
me and Address Service am Client Na C a s
ress r EXHIBIT 3.5 MULTIPLE WORKFLOWS STYLE
Workflow Decomposition Style. As in every software development project, the initial conceptual
solution is merely a business proposal that typically does not oblige development teams to
rubberstamp the initial business solution blueprints.
Pages:
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122