I think it's just a matter of who's more willing to use the concept of SOA. If you can get more business people to SOA and have IT work with business, I think that's fine. Personally, it just seems that many business people are less likely to take a risk on a new concept then the IT - let IT try it out with us helping in case it succeeds. It's also much easier to hide a server in a corner closet than be faced with a failed business process. :-)
I was just about to write what happened to Steve because I haven't seen a post from you lately. Was worried that you might have caught the flu. :-) H.Ozawa 2009/6/2 Steve Jones <[email protected]>: > > > Not sure about this Anne. > > 2009/5/29 Anne Thomas Manes <[email protected]>: > >> >> >> 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. > > That to me is like arguing that engineers should be bus drivers. SOA > can work at multiple levels, and certainly far beyond the technical > level. I've worked on several SO business architecture pieces where > the real focus and ownership was around understanding the economic > models of the services rather than their technical implementation. > > That sort of SOA cannot be driven by IT but IT can help deliver the > realisation of the business services. > >> >> 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) > > Which for me is why SO should be business driven and why it should > start with Business Services, above EA (or at best within the > context/conceptual parts of EA) and why business ownership and > direction is key. > >> >> 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". > > This I agree with, I've never thought it was a good idea. I think > that businesses should _continue_ to look at their business services, > their economic models and the right realisation approach for IT within > those constraints. > >> >> 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. > > If people are just looking at SO as an IT piece then for me we still > don't know where our towel is. >> >> 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) > > I agree it should be standard, but not that the business shouldn't be > thinking in the same way and that the communication between IT and the > business should itself be SO. That is the real win for SO (for me) to > create a common way of communicating to more directly link the > business to solutions and bypassing much of the industry that has > grown up around obfuscating the conversation. > > Steve > >> >> Anne >> >> On Thu, May 28, 2009 at 11:57 PM, Rob Eamon <[email protected]> wrote: >>> >>> >>> --- In [email protected], "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 >>> >>> >> > >
