I recall in the not too distant past the claim that business and OO were a natural fit as well. We would do well to not get too carried away with our latest fad.
I just read an article in Wired about Google and the focus/view they have of their business. http://www.wired.com/culture/culturereviews/magazine/17-06/nep_googlenomics According to this article, they view as much as they can as auctions. "One key innovation was that all the sidebar slots on the results page were sold off in a single auction." (Referring to AdWords Select, as it was known at the time.) Given the success of AdWords auctions, they have applied the auction approach to other things. [quote] Google even uses auctions for internal operations, like allocating servers among its various business units. Since moving a product's storage and computation to a new data center is disruptive, engineers often put it off. "I suggested we run an auction similar to what the airlines do when they oversell a flight. They keep offering bigger vouchers until enough customers give up their seats," Varian says. "In our case, we offer more machines in exchange for moving to new servers. One group might do it for 50 new ones, another for 100, and another won't move unless we give them 300. So we give them to the lowest bidder—they get their extra capacity, and we get computation shifted to the new data center." [/quote] Is Google service-oriented? Object-oriented? Auction-oriented? All 3 and more? My take is that the auction orientation augments their approach to things. Would Google say they are SO? Or, as the article quotes Eric Schmidt: "All of a sudden we realized we were in the auction business." I'm sure parts of Google will state they follow SO principles, what with all the noise around so-called cloud computing and its tenuous link to SO. But is it *the* main style? Or one of many? Thoughts? -Rob --- In [email protected], Michael Poulin <m3pou...@...> wrote: > > The stupidity of the situation, Hitoshi-san, is in that SO is NOT a new > concept for Business, it is how all organisations have been started, it is a > core of Business. > > - Michael > > > > > ________________________________ > From: Hitoshi Ozawa <htshoz...@...> > To: [email protected] > Sent: Tuesday, June 2, 2009 10:39:53 AM > Subject: Re: [service-orientated-architecture] Re: Anne again on SOA's > Mortality > > > > > > 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 <jones.steveg@ gmail.com>: > > > > > > Not sure about this Anne. > > > > 2009/5/29 Anne Thomas Manes <atma...@gmail. com>: > > > >> > >> > >> 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 <rea...@cableone. net> 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 > >>> > >>> > >> > > > > >
