Oh, the AIG that just sold their building in front of the Imperial palace. :-)
I think it's because we're in the different market. In general, Japanese companies are slower in adoption. I don't want to wait many years when it's finally beginning to pick up (but slowly). I understand the problem with differences in "service" from business perceptive and IT perceptive, and it has been one of the major hurdle that we had cross mapping business defined process/service to IT. We can map a business process onto a diagram and improve it, but the improvement was mostly confined to be just on the business side and not too much from business/IT alignment. Likewise, "flexibility" has also been a problem because the notation of flexibility differs between business and IT. SOA was an abstract concept, but I think we are finally getting to be able to define more concretely in terms that both business and IT can both understand. I see it more as a chick hatching from a egg rather than SOA needing a bailout. It's hard to describe a chicken by showing an egg, but it becomes much easier with a chick. :-) H.Ozawa --- In [email protected], Anne Thomas Manes <atma...@...> wrote: > > Hitoshi, > > My insurance company just changed its name from AIG to 21st Century. > My guess is that they lost many customers when AIG took the bail-out. > Sometimes changing names is the right thing to do. > > Please be aware that I have never advocated that we come up with a new > name to replace "SOA". My point is that we should never have attempted > to sell "SOA" to the business. It is a mistake to try to sell a vague, > abstract, IT architectural concept to business people. It's like > trying to sell Web 2.0 to business people. That doesn't mean that > architects should stop doing SOA, just stop trying to "sell" it. As > Nike would say, "Just do it." > > Michael, no doubt, will assert that business people get service > orientation. And perhaps they do from a business perspective -- but > these folks don't necessarily understand how service orientation > applies to IT systems, and trying to explain it to them will most like > result in confusion and frustration. Their definition of "service" is > different from what architects/developers think of as a "service", > e.g., "billing" vs an application that prints bills. > > If you have to sell something to business people, sell them the actual > "services" that will deliver value to them (i.e., their definition of > "service"). From an IT perspective, a service equates to a project. > "Doing SOA" means applying SO principles in the design and > implementation of that project. > > Anne > > On Mon, Jun 8, 2009 at 6:36 PM, htshozawa<htshoz...@...> wrote: > > > > > > That's exactly why we should stick with SOA instead of changing names. > > Changing names seems like we were defeated or worse, that we are just trying > > to sell the same of stuff under a different name. The point is there were > > some (many?) initiatives/projects that went sour but if we were a used car > > dealer, would we change the name because the dealership across the street is > > selling lots of lemons? > > > > I think it's just a matter of being able to explicitly show the benefits and > > show the differences between failed initiatives and our approaches like we > > always have been doing with proposals. IMO, sticking with the same name > > makes it easier to compare between those who really don't have any idea and > > those who do. It's easier to explain what's went wrong with the current > > initiative/project rather than not make users think that we are trying to > > pitch them the same thing under a different clothing. :-) > > > > H.Ozawa > > > > --- In [email protected], Anne Thomas Manes > > <atmanes@> wrote: > >> > >> Hitoshi, > >> > >> When I say SOA is dead, I mean that (in most organizations) business > >> people no longer believe the hype about SOA. The general attitude is > >> that SOA costs a lot and does not deliver value; therefore, funding > >> for SOA initiatives has dried up in most organizations. This is a > >> tragic development, because all organizations should be working to > >> optimize and improve their applications architecture. (Note, though, > >> that few so-called SOA initiatives were focused on architecture > >> improvement.) > >> > >> Given tight budgets and increased IT investment scrutiny, IT groups > >> should avoid putting forth proposals for "SOA" and instead focus on > >> developing proposals for concrete services with hard metrics that will > >> demonstrate quantifiable business value with rapid ROI. > >> > >> Anne > >> > > > > >
