General information from BPM you may get from http://www.slideshare.net/samarin/bpm-for-developers
Thanks,
AS
AS
Showing posts with label modelling procedure. Show all posts
Showing posts with label modelling procedure. Show all posts
2013-07-05
#BPM for business analysts: modelling procedure
A presentation about a modelling procedure from my book www.samarin.biz/book
General information from BPM you may get from http://www.slideshare.net/samarin/bpm-for-developers
General information from BPM you may get from http://www.slideshare.net/samarin/bpm-for-developers
2010-01-09
Linkedin: SOA or not?
<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
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
2009-05-05
Re: Five Fatal Errors for Business Analysts
<discussion ref="http://www.integrated-modeling-method.com/process-modeling/five-fatal-errors-for-business-analysts />
I use a modelling procedure which I think avoids some of these pitfalls. The purpose of the modelling procedure is to analyse a building block (what it is supposed to do) and to synthesise its implementation (how it does this) as the explicit coordination of other building blocks (processes or activities). It is an iterative procedure – we can apply it until we have left only indivisible building blocks (i.e. activities). During modelling, we collect and refine different artefacts (including data, rules, roles, KPI, etc). We consider that building blocks are constructed recursively, like Russian dolls, to avoid getting bogged down in detail.
More detail in section 6 of http://www.improving-bpm-systems.com/pubs/AS-BPMDS08.pdf
Thanks,
AS
I use a modelling procedure which I think avoids some of these pitfalls. The purpose of the modelling procedure is to analyse a building block (what it is supposed to do) and to synthesise its implementation (how it does this) as the explicit coordination of other building blocks (processes or activities). It is an iterative procedure – we can apply it until we have left only indivisible building blocks (i.e. activities). During modelling, we collect and refine different artefacts (including data, rules, roles, KPI, etc). We consider that building blocks are constructed recursively, like Russian dolls, to avoid getting bogged down in detail.
More detail in section 6 of http://www.improving-bpm-systems.com/pubs/AS-BPMDS08.pdf
Thanks,
AS
Subscribe to:
Posts (Atom)
Posts
