I follow Davenport's idea that business process is defined along three dimensions: entity, object, and activity. Entity can be people or computer programs and are called actors. Objects are what are operated by softare such as a letter, a file, or a representation of something such as a billing method (electronic or paper) etc. Business process has start point as actor actions (begin by customers) and end points (end with customers). The three dimensions give us opportunity to find abstractions in each of the three dimension. Business process contains itself so we have atomic business processes and composite processes. Atomic business processes are composed of business activities that can be a hierarchy also. So we have atomic business activities and composite activities. As such we have a hierarchy business process model with business activities at lower level and business processes at higher level. Both activities and processes are unique so they are reused at all levels.
Once we have this business process modeling in place, we need to define services. I define services as business processes but not activities. All services are business processes. Highest composite business processes are not services but may become services in the future. busincess activities and atomic business processes are implemented as COM(or EJBs) objects. Services will group relevent COM objects as executable agents. Here is the benefits to build SOA on component technology. If activities in a business process are not shared any where even in the future then the executable agent of the services don't have to be implemented in Object or Component technologies. have to go. Will be back later. Jerry --- Michael Poulin <[EMAIL PROTECTED]> wrote: > Ann, I have to points: > 1) you are absolutely right - business object is > not the right thing to talk business. I, actually, > mean a bisiness unit of work, which may have its > own 'capabilities' including data and operations > with the data. > 2) I have difficulties to imagine a business > service which includes business process because > both are derived from the business model. To my > understanding (the model I follow), an interaction > of business services constitute business processes. > > - Michael > > > Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > I prefer > the term "capability" to "activity and process". A > service implements a shared capability -- it may be > an activity or a process, but it may also simply > provide access to data, or it may implement > non-business functionality, such as authentication > or auditing. > > Michael said, "The business has to stop talking IT > language and get back to the business terms and > tasks." (and I heartily agree). But then he > contradicted himself by saying, "business processes > are performed by business objects." I caution > against this type of terminology if you intend to > speak to business people. If you say "business > object" to a business person, s/he's likely to think > of some sort of document, like a purchase order or > an insurance claim. A business object represents > the state of a business process, but it doesn't > perform it. > > Anne > > > On 10/20/06, Michael Poulin <[EMAIL PROTECTED]> > wrote: > > Jerry wrote:" Services are activities and processes > shared accross." I guess, it is the statement from > the Davenport's work. > > Actually, this is the crucial point to me. In such > definition, almost any activities in an enterprise > may be considered as business service because > "shared across" is a quite fuzzy definition. I think > (based on to date IT practice in its variety, which > is different from 15 years old IT practice > described by Davenport), it was and it is very > convenient definition for an IT because it covers > modern state of applications and related > operations. The problem is only in that this state > is not sufficient to handle fast and frequent > changes required by the business to agile to the > market trends. As it's appeared, inflexibility of > applications is caused by the fact they implement > only elements of business operations some of which > are frequently based on the previous generation of > applications; the applications reflect patched > business needs, not real business model of the > enterprise. It works OK until market demands quick > changes and en enterprise cannot meet this > demand because of misdirected IT resources. > > In my proposal, business services and business > processes are derived from the enterprise business > model irrespective to current IT (applications) > state. The business has to stop talking IT language > and get back to the business terms and tasks. Each > business model has its scope it can evolve in. This > evolvement is the subject for SOA, not more. SO, > the IT has finite spectrum of business activities > to support. > > I do distinct between business processes and > business operations inside the business services. > Business services comprise business objects, i.e. > business processes are performed by business > objects. The latter has its own behaviour (look, it > is almost OO model) expressed in business > operations. The operations performed by entities > and deal with things that may be irrelevant to the > enterprise business (like legal things in the food > retail business) but needed to run the business. > > All this helps me to define what services to > implement and which services are SOA service and > which are just convenient model of application > implementation. > > - Michael > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > To navigate thro business process > literature, just go > to a local university library to search for popular > texts and look at the index for business process. > Google search is also a good way. It wont take you > a > dozen hours to do this. > > Services are activities and processes shared > accross. > They have owners as entities (service providers) > and > are used by other entities (consumers). Entity is > one > of three dimensions defined by Davenport. I think > the > debate whether SOA is OO or not is meaningless. OO > and SO are at different levels with SO at one level > above so SO include OO. OO principle is about > abstraction that can also be used in SO along the > three dimensions defined by Davenport such as > open/close principle and stable dependencies > principle. Viewing the world as levels not only > allow > us to see more but also to understand rich > information > in the interactions between levels. > > Jerry > > --- Michael Poulin < [EMAIL PROTECTED]> wrote: > > > Jerry, > > > > I was not able to read through "all literatures > > related to business process" but read a few > > Davenport's articles for this time. Mr. Davenport > > > defines a business process as "simply how an > > organization does its work" while I see more > > structure (business activities based on the > > enterprise business model that split into > operations > > and operational flows of the business objects > > manipulating business data) and constrains > > (particular business model limitations) in the > > business service and process definitions. > > > > The consequence of the difference is that I > do > > not consider a business services as an entity, > > which can be adequately described with OO > principles > > only but rather within a combination of OO and > > functional model. That is why SOA to me is not > OO > > model but this is, probably, a different > discussion > > thread (running now). > > > > Anyway, I am truly thankful to you for the > > reference and, probably, I will contact Mr. > Thomas > > H. Davenport for more discussions. > > > > > > Cheers, > > - Michael Poulin > > > > > > > > Jerry Zhu < [EMAIL PROTECTED]> wrote: > > > Michael, > > > > thanks for the text. Human organizations are > > things > > you can see anything you want to see according > to > > your > > theory. Reality tend to reveal us based on our > > perspective we bring to it. A perspective > > consists of > > experience and conceptual apparatus. When we > > change > > the conceptual apparatus we change the nature > of > > the > > problem. You have presented a conceptual > apparatus > > what business processes/services are. Good > try. > > I > > think you are doing the right thing that needs > to > > be > > understood first and foremost if we want to > build > > an > > enterprise information systems that are low > cost, > > effective, and adaptive. Without high quality > > business process theory, we can not build a > good > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
