The following definition is from the same source (wikipedia.org) SOA provides methods for systems development<http://en.wikipedia.org/wiki/Systems_development>and integration <http://en.wikipedia.org/wiki/System_integration> where systems package functionality as *interoperable*<http://en.wikipedia.org/wiki/Interoperability> *services* <http://en.wikipedia.org/wiki/Service_%28systems_architecture%29>. A SOA infrastructure<http://en.wikipedia.org/wiki/Service_Oriented_Infrastructure>allows different applications to exchange data with one another.
Service-orientation <http://en.wikipedia.org/wiki/Service-orientation> aims at a *loose coupling* of services with operating systems, programming languages and other technologies that underlie applications[1]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-0>. SOA separates functions into distinct units, or services[2]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-Bell-1>, which developers make accessible over a network in order that users can combine and reuse them in the production of applications[3]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-Erl-2>. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA can be seen in a continuum<http://en.wikipedia.org/wiki/Continuum_%28theory%29>, from older concepts of distributed computing<http://en.wikipedia.org/wiki/Distributed_computing> [2]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-Bell-1> [3]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-Erl-2>and modular programming <http://en.wikipedia.org/wiki/Modular_programming>, through to current practices of mashups <http://en.wikipedia.org/wiki/Mashup>, SaaS<http://en.wikipedia.org/wiki/SaaS>, and Cloud Computing <http://en.wikipedia.org/wiki/Cloud_Computing> (which some see as the offspring of SOA [4]<http://en.wikipedia.org/wiki/Service-oriented_architecture#cite_note-3> ). *Service-orientation* is a design paradigm<http://en.wikipedia.org/wiki/Design_paradigm>that specifies the creation of automation logic in the form of services <http://en.wikipedia.org/wiki/Service_%28Systems_Architecture%29>. It is applied as a strategic goal in developing a service-oriented architecture <http://en.wikipedia.org/wiki/Service-oriented_architecture>(SOA). Like other design paradigms, service-orientation provides a means of achieving a separation of concerns<http://en.wikipedia.org/wiki/Separation_of_concerns> . I think we need an architecture principles before a design model. Also, if someone doesn't agree with definitions, please provide a clear definitions instead. All the best Ashraf Galal On Fri, May 29, 2009 at 1:41 PM, Anne Thomas Manes <[email protected]>wrote: > > > Given that the business (i.e., non-IT people) rarely gets involved in > system architecture design, it doesn't really make sense to argue that > SOA should be driven by the business. SOA is an IT architectural > style. IT people are responsible for designing the architecture of the > IT systems. Hence, SOA must be driven by IT. > > BUT: IT *should* direct its SOA initiative based on business > requirements. IT implements projects in response to business requests, > and those requests should be analyzed from an EA perspective as part > of a demand management practice. Every project in the demand queue > should be evaluated in terms of the project's investment potential. IT > has limited resources. Where are those resource best spent? Every > project should have a business plan that articulates the expected > business outcomes from the project. Each project plan should include > metrics that can be used to measure the success of the project in > attaining those expected business outcomes. Projects should be > prioritized based on the value and exigencies of the expected business > outcomes. (btw -- "business outcomes" = ROI) > > Circling back to Rob's initial response to this thread, I think I > agree that we've reached the stage where organizations should no > longer pursue a "SOA initiative". > > I think it *was* necessary for organizations to pursue a SOA > initiative during the past 5+ years. We all needed education. We > needed to grok service orientation, and the excessive hype of an > "initiative" has helped make SO thinking a bit more pervasive. > > Now we've reached the stage where IT has to talk less about SOA > initiatives and instead focus on applying SO principles to its > projects. I'm not confident that the majority of developers really > grok SO principles, but I'm hopeful that practice will improve the > situation. > > As I've repeatedly stated since I published the obituary, IT should no > longer talk to the business about "SOA". The mantra going forward > should be, "just do it". i.e., apply SO principles in all projects. > (but not to the exclusion of other architectural principles) > > Anne > > > On Thu, May 28, 2009 at 11:57 PM, Rob Eamon > <[email protected]<reamon%40cableone.net>> > wrote: > > > > > > --- In > > [email protected]<service-orientated-architecture%40yahoogroups.com>, > "htshozawa" > > <htshoz...@...> wrote: > >> > >> Should IT not think about SOA at this stage because it's too late? > I > >> would say no. > > > > The double negative is throwing me off--are you saying that IT should > think > > about SO? I think you're say that they should. Correct me if my brain is > > misfiring. > > > > If IT is tasked with architecting and designing a solution, following SO > > principles would seem to be okay. There would seem to be some increased > risk > > that the segmentation of services might be off but maybe not. > > > >> Now, this brings us back to the question that's been repeated here - > >> should SOA be initiated by a business or IT. > > > > If IT is part of the business, is there a distinction? :-) > > > > I'd offer that this isn't a question of which organizational unit drives > an > > architecture effort. Should business or enterprise architecture, in > whatever > > style, be driven by business or technology concerns? These forums have > > explored this in many ways and I think there is at least some consensus > that > > while business concerns should dominate (especially in a BA), technology > > needs to be part of the picture as well (perhaps even in a BA). > > > > The decision to follow SO principles is one to be made by the architect > (or > > architecture team), at whatever level the architect is working at. I > agree > > with the several folks here that probably the best level at which to > start > > is the business architecture level. Where some may disagree is if it > starts > > at a lower level (presumably less business focused and more technology > > focused), that's okay too. > > > > A big part of the role of the architect is consensus building. Balancing > the > > constraints and sometimes competing interests of the groups involved. > This > > isn't "selling" per se but it does involve the ability to persuade when > > necessary. > > > >> IMHO, it doesn't matter too much as long as both parties become > >> involved as time goes along. > > > > If IT is part of the business, isn't there just one party? :-) > > > >> IMHO, SOA is a concept which has some best practices suitable for > >> many organizations but no one fixed implementation guideline > >> that's suitable all organizations (as is the same for most > >> concepts involving human factor). > > > > Agreed. And that's a big source of contention and frustration. Some want > > that fixed, guaranteeed to work guideline. Some say that without it, SO > is > > useless. > > > > -Rob > > > > > >
