Anne said: << 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. >> I assume that "these folks don't necessarily understand how service orientation applies to IT systems" as well as "Their definition of "service" is different from what architects/developerrs think of as a "service", e.g., "billing" vs an application that prints bills". The question is: WHY there is a difference? Printing bills is a technical procedure that has very little in common with the business function of "billing". I assert that IT must have the same understanding of the business function with Business that IT supports by providing technical tools and automation. You, Anne, saying the same as me in your words - "sell them the actual "services" that will deliver value to them (i.e., their definition of "service")". But to build a business service, IT has to be 'permitted' to interfere with business processes and be called to solve business tasks (as a regular business unit). This is the shift in the business mindset required for full implementation of SO concept. Where I disagree with Anne, it is in: "From an IT perspective, a service equates to a project. "Doing SOA" means applying SO principles in the design and implementation of that project." To make SO successful, IT should stop doing Projects and shift onto doing Programmes. That is, IT has to start building technical SOLUTIONS based on SO principles where separate components, code, programmes are only parts of the solutions. Those solutions can and have to be treated as low-level business operational solutions that may include manual operations as well (the difference here is that it is Technology who shell define the workflow and its points where automation is inefficient today delegating such activities to the operational teams, not other way around). - Michael ________________________________ From: Anne Thomas Manes <[email protected]> To: [email protected] Sent: Tuesday, June 9, 2009 4:14:36 PM Subject: Re: [service-orientated-architecture] Re: Anne again on SOA's Mortality 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/develope rs 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...@gmail. com> 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 service-orientated- architecture@ yahoogroups. com, Anne Thomas Manes > <atma...@... > 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 >> > >
