I think that it is helpful to apply Herbert Simon's Hierarchy theory where lower levels are more stable than higher levels. I see four gross levels, data (lowest), SW, Serivce, BMP. In this view there is no applications (no intergration) and all versons of technology evolution are played fully at various levels. What we see are SW components (re)assembled at service level which again are (re)assembled at the BPM level.
Jerry --- Michael Poulin <[EMAIL PROTECTED]> wrote: > I am taking a risk to cause a wave of critics on my > head but in a few words I would outline that SOA IS > AN IMPLEMENTATION OF BUSINESS SERVICES AND > PROCESSES EXPRESSED IN SW ARCHITECTURE. > > That is, it is difficult to imagine a separate > reuse of SW from the service. > > If you talk about SW reuse, it is a noble task on > its own. But it might be unrelated to the SOA. > > Certainly, if a SOA Service is not reused, it does > not prevent components comprising the Service to be > reused. This is one of the beauties of SOA - > re-usability of "building blocks". > > Finally, I am getting to the point where I can > say: a SOA differs from a non-SOA not in the > implementation (technologies) but in the subject > addressed by the technologies - if it is a > Business Service or a Business Process defined by > and/or derived from the enterprise Business Model, > it is the SOA. Otherwise, it is just a service-based > integration, and here is nothing wrong with it. > > - Michael Poulin > > Jerry Zhu <[EMAIL PROTECTED]> wrote: > I think that it is > beneficial to differentiate two > levels of reuse: SW level and Service level. SW > reuse > is SW implemented functionalities and best > technology > is Component technology for requirment of being in > network computing environment. Service reuse is > business processes enabled by service technology > accessible to a wide audience. Data > access/mamangent, > for example, should be treated as reuse at SW > level > not at service level. > > Therefore Service technology built upon component > technology will provide the convenience to > classifying > different levels of reuse and improve performance. > > > As for nonreusable services, my question is that > are > the services reusable in the future? if not, can > SW > instead of service component do the job? > > Jerry > > --- Brian Mikesell <[EMAIL PROTECTED]> wrote: > > > Thank you both for your feedback. I think we're > > mostly in-line with > > what you say. Our approach has been top-down > and > > bottom-up meeting > > somewhere in the middle where we'll use flexible > > layers to marry up > > business services to technology-enabled service > > components, probably > > using BPEL in that flexible layer. We have a > group > > that's focusing > > on business modeling at the top which leads to a > > solid business > > service portfolio. This portfolio is viewed as > the > > sweet spot as it > > should provide us the most reuse and benefit to > the > > business. At > > the same time, we're determining how to enable > > existing assets for > > reuse (which is what my original post was > > targeting), knowing that > > these cannot always be considered services. > > > > This discussion has initiated more questions in > my > > mind which I'll > > pose under a new subject. Thanks for the > feedback. > > > > Brian > > > > > > > > --- In > > [email protected], > > "Anne Thomas > > Manes" <[EMAIL PROTECTED]> wrote: > > > > > > A big +1 to Steve's comments. > > > > > > Keep in mind that not everything needs to be a > > service. Only > > reusable > > > functionality should be implemented as a > service. > > Also keep in > > mind that > > > integration is not the same thing as > > service-orientation. > > > > > > Integration focuses on bridging application > silos > > and, in the > > process, it > > > reinforces the silos. Service-orientation > focuses > > on refactoring > > duplicate > > > functionality into shared services, which > breaks > > down application > > silos. > > > > > > Obviously you can't refactor your entire > > environment overnight, so > > you will > > > be forced to do a fair amount of integration > while > > you are on the > > path to > > > SOA. But it's important to establish some > > enterprise-level > > oversight to > > > shepard the SOA initiative. You shouldn't > leave it > > to individual > > project > > > teams to make enterprise-wide strategic > decisions > > regarding what > > services > > > the business needs. The SOA oversight group > should > > conduct a > > number of > > > enterprise architecture activities (e.g., > > application > > rationalization and > > > business capability mapping) to get a better > > understanding of the > > business > > > and its requirements, and it should establish > > priorities for SOA > > projects. > > > > > > Anne > > > > > > On 9/27/06, Steve Jones <[EMAIL PROTECTED]> > wrote: > > > > > > > > Stage 1: Work out what the business > services > > should be > > > > > > > > Too often I've seen companies go at SOA as a > > technology solution > > and > > > > either really struggle or fail with aplomb. > > > > > > > > Once you understand what you want your IT > estate > > to look like in > > 3-5 years > > > > time, the business services it will supply, > > their heirachy and > > their owners > > > > you can then look both at the technical and > > integration services > > required to > > > > support this and the appropriate mechanisms > for > > communication > > between the > > > > various different service areas. > > > > > > > > Doing this creates the big picture and > vision > > for your > > Enterprise SOA and > > > > gives a firm base for the technology > questions. > > It also > > shouldn't take a > > > > long time (normally upto 2 months). The > most > > important element > > is what you > > > > expose, not how you expose it. > > > > > === 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/
