--- In [email protected], 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 [email protected], "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 > > > > >
