<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36604&discussionID=11868557&sik=1263034934834&trk=ug_qa_q&goback=.ana_36604_1263034934834_3_1" />
I agree that just defining all processes and then “converting” activities into services is not a good idea (e.g. because of potential absence of a good structure as mention in that anti-pattern). Also, I noticed that, just defining all services and “pushing” processes into them is a challenge.
I consider the following relationships between services and processes:
• all our processes are services,
• some operations of a service can be implemented as a process,
• a process includes services in its implementation.
To find out these relationships at a particular enterprise, I recommend a 4-phase modelling procedure
which incrementally structuring processes and services, as well as avoids diagrams like
“Services are not supposed to make assumptions about the context in which they are invoked. Driving service identification from the process risks making the service useful in only that process.”
Sure, no assumptions. Services are designed to work in context – the latter defines functional and non-functional characteristics of a service. The usage of the same modelling procedure increases probability that two different people will find similar services in the same context. Also, the high level of flexibility is necessary to quickly refactor slightly different services into one reusable service.
Thanks,
AS
More details are in my new book “Improving enterprise business process management systems” www.samarin.biz/book
2010-01-09
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment