I do disagree with Anne on "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."
Who has defined, when and how that "SOA is an IT architectural style" and not an architectural style applicable to both Business and Technical (IT) architecture? Yes, 'IT people are responsible for designing the architecture of the IT systems' but this does not mean that "SOA must be driven by IT". I believe, SOA must be driven by Business and cascaded into IT. Only in this case SOA, actually SO or Services, can produce maximum efficiency if implemented. By my book, SOA in Business leads to the SO business requirements for IT and this resolves well-known problem in the Business-IT relationship. - Michael ________________________________ From: Gervas Douglas <[email protected]> To: [email protected] Sent: Friday, May 29, 2009 8:13:09 PM Subject: [service-orientated-architecture] Re: Anne again on SOA's Mortality --- In service-orientated- architecture@ yahoogroups. com, Anne Thomas Manes <atma...@... > 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) This raises a couple of questions: (a) Do you think it will soon be a universally accepted practice for enterprise-level packaged software vendors to apply SOA principles to all their products? (b) Will this practice percolate down to vendors catering to the SME/SMB market? Gervas > > Anne > > > On Thu, May 28, 2009 at 11:57 PM, Rob Eamon <rea...@...> wrote: > > > > > > --- In service-orientated- architecture@ yahoogroups. com, "htshozawa" > > <htshozawa@> 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 > > > > >
