Comments on: What does SOA mean for the process modeling world? http://www.rickgeneva.com/wp/posts/what-does-soa-mean-for-the-process-modeling-world/ Insightful information on business process modeling from Rick Geneva Sat, 10 Oct 2009 10:51:48 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: ilango.gurusamy http://www.rickgeneva.com/wp/posts/what-does-soa-mean-for-the-process-modeling-world/comment-page-1/#comment-5 ilango.gurusamy Wed, 20 Aug 2008 17:20:24 +0000 http://www.rickgeneva.com/wp/?p=10#comment-5 Interesting SOA post. Interesting SOA post.

]]> By: rickgeneva http://www.rickgeneva.com/wp/posts/what-does-soa-mean-for-the-process-modeling-world/comment-page-1/#comment-4 rickgeneva Sun, 10 Aug 2008 04:32:57 +0000 http://www.rickgeneva.com/wp/?p=10#comment-4 Dave, I'm not trying to imply that the business analyst is going to write a good diagram of a service. Creating IT services is a skill set that most people on the business side of an organization don't have. However, creating the need for a service can easily be illustrated in the diagram I showed. It's up to the IT engineer to figure out what's in that activity. What's important is that IT and business agree that it should be there, and generally what the interface should look like. For example, how many message types can be returned from this service? Are error responses embedded into the message body or does the service return a different message type for an error response? This approach means that the business side must learn that data exists, and messages exist. The main point of the post is that BA's need to stop thinking in terms of sending a message from one person directly to another. This no longer exists in the modern world. In some very few cases, we hand a piece of paper from one person to the next. If this is not the case, there is a system involved, and it would be foolish not to include the system participant into the process diagram. So again, in no way am I saying that a BA will write the specification for the system interface. I'm just saying that as a process modeler, it would be wise to start showing where people and systems interface, even if it's still very abstract. Dave,
I’m not trying to imply that the business analyst is going to write a good diagram of a service. Creating IT services is a skill set that most people on the business side of an organization don’t have. However, creating the need for a service can easily be illustrated in the diagram I showed. It’s up to the IT engineer to figure out what’s in that activity.

What’s important is that IT and business agree that it should be there, and generally what the interface should look like. For example, how many message types can be returned from this service? Are error responses embedded into the message body or does the service return a different message type for an error response?

This approach means that the business side must learn that data exists, and messages exist. The main point of the post is that BA’s need to stop thinking in terms of sending a message from one person directly to another. This no longer exists in the modern world. In some very few cases, we hand a piece of paper from one person to the next. If this is not the case, there is a system involved, and it would be foolish not to include the system participant into the process diagram.

So again, in no way am I saying that a BA will write the specification for the system interface. I’m just saying that as a process modeler, it would be wise to start showing where people and systems interface, even if it’s still very abstract.

]]> By: DFrench http://www.rickgeneva.com/wp/posts/what-does-soa-mean-for-the-process-modeling-world/comment-page-1/#comment-3 DFrench Mon, 21 Jul 2008 05:15:55 +0000 http://www.rickgeneva.com/wp/?p=10#comment-3 I think the goal of re-use that you allude to may be better achieved by thought upfront in the process analyst space rather than the hope that IT Engineer will magically infer the requirement for generic services [more here ... http://davethinkingaloud.blogspot.com/2008/07/with-emphasis-on-process-design-first.html] I think the goal of re-use that you allude to may be better achieved by thought upfront in the process analyst space rather than the hope that IT Engineer will magically infer the requirement for generic services [more here … http://davethinkingaloud.blogspot.com/2008/07/with-emphasis-on-process-design-first.html

]]>