Sorry, you are right! The article can be found at: http://www.ebizq.net/blogs/service_oriented/2009/05/who_has_to_lead_soa_efforts_business_or_it.php
Gervas --- In [email protected], "htshozawa" <htshoz...@...> wrote: > > Hi Gervas. Seems you've posted the article twice instead of providing us with > the URI. :-) > > I've tried the common EA approach, but moving on to creating a model with > combined FR, NFR, and architecture instead of treating them separately - it > offer more convincing arguments to some decision conflicts. (I'm still > collecting more data on this.) > > H.Ozawa > > --- In [email protected], Gervas Douglas > <gervas.douglas@> wrote: > > > > > > > > <<This week I had an interesting discussion with Anne Thomas Manes of > > Burton Group <http://www.burtongroup.com/> and Rob Eamon > > <http://www.linkedin.com/in/reamon> about where SOA has to be - in > > Technology/IT, or in Business, or anywhere else. I would like to > > represent the arguments and contra-arguments of this debate for you to > > make your own opinion. > > > > The discussion has been started by Anne's recent post that once again > > explained her almost revolutionary statement: "/SOA is Dead; Long Live > > Services/" made in January, 2009. Many architects, managers, and bolgers > > responded that time because the statement was misread initially. Finally > > the discussion pacified due to the context of the statement that was > > very clear: "/"SOA" as a term has lost its luster, but "SOA" as a > > practice is essential for all organizations going forward/". It is > > almost obvious that the SOA term has been obfuscated in the industry by > > the details of implementations that did not in fact grasp the concept of > > service orientation. In reality, *service orientation is very powerful > > and highly permissible concept of modelling actual life*. > > > > Among others, Anne has quoted John Rymer who said: "/SOA died a > > marketing death/", "/When a technology becomes vital, it dies in a > > marketing sense/," he explained. "I/t's time for SOA to 'die' since it's > > not distinguishable anymore since everybody's using it./" I do not think > > that Anne's based her conclusion on the marketing trends; there is a > > fact that many organisations started to cut their investments in to SOA > > projects in IT because those IT failed to provide for their promises > > made about SOA economic efficiency. At the same time, we also have many > > examples of SOA success in other organisations. The question is: why SOA > > projects in IT have lost business trust to the degree that this become > > almost an industry trend? > > > > In the comments to the Anne's post, Rob outlined that IT reached the > > stage where isolated individual "SOA initiative" (that I called 'SOA > > projects' ) have demonstrated their incapability to reach the value of > > service-oriented solution in "/organically growing SOA/", i.e. SOA must > > be treated at the enterprise level to be productive and should be driven > > by the Business. > > > > I usually promote similar approach to *SOA *explaining it as *a > > business-oriented consumer-centric architectural model*. *Any violations > > of mentioned characteristics lead to SOA failure*. This, IMO, is the > > reason of multiple failures in SOA area - use of Web Services for > > integration of applications somewhere in the IT depth has a very far-off > > effect to the business, if any; composing existing legacy applications > > to satisfy immediate business needs without any perspective view on the > > changes that come tomorrow leads to the waist of IT resources and only > > increases the cost of IT efforts; disconnection between IT projects > > disallows appropriate project funding and planning of implementation of > > service oriented solutions (SOS); and, finally, still process-oriented > > nature of low-level business operations constantly conflicts with > > potential service-oriented technical solutions (because an effective IT > > solution can overcome the operational process while, instead, the > > process downgrades the SOS to the level of process actions and nothing > > more, i.e. potential efficiency of SOS is constantly compromised by > > inefficiency of the process). > > > > Anne's response was a bit unexpected: "/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/." The essence of my position is that *business > > requirements derived from non-service oriented business implementation* > > (i.e. business operational processes) *kill SOA in IT*; does not matter > > what IT does, SOS is not needed for such requirements. > > > > *For SOA to succeed in mass, Business has to be deeply involved in SOS > > and, correspondingly, has to influence system architecture design*. > > Despite SOA was initially defined as "/an IT architectural style/", in > > nowadays we have achieved the understanding that /service-oriented > > principles can drive Business even more effectively than IT/; that _SOA > > must be driven by Business and than cascaded into IT if an organisation > > wants to gain maximum efficiency from its service-oriented initiatives. _ > > > > Only in the situation described above, IT will get service-oriented > > requirements and will be able to respond with service-oriented technical > > solutions. IMO, SOA, more accurately, service orientation, moves from IT > > into Business. I think, Anne and me were closing our positions when Anne > > said: "/SOA must be business-driven (i.e., the goals of the SOA effort > > should be focused on generating positive business outcomes), but it > > should not be driven by business people. > > (Business people don't grok the necessity of SOA, and therefore they > > will not be good leaders for the effort.)/" > > > > This is the crucial pint of the discussion - in my opinion, if SOA has > > its 'ceiling' in process-centric low-level business operations and > > locked in IT, there is 'no-go' for SOA. But it is not clear to me why it > > should be this way. In my findings, business people who are in direct > > contact with IT don't, indeed, '/grok the necessity of SOA/' while the > > business people at a layer above, actually, do. At the top of the > > business hierarchy, people operate primarily in services, they deal with > > WHAT, WHY and WHO does the business, the lower business layers have to > > figure out HOW the business tasks may be relaised. If IT is not treated, > > at least, equally to these lower business layers and cannot really > > contribute into HOW technical capabilities can innovate business > > solutions, there is very little chance for SOS to be effective and, > > thus, survive at all (currently, IT is positioned UNDER the lower > > business layers and plays the role of 'forever follower'). > > > > Finally, who has to lead SOA efforts? Anne says: "/I agree that senior > > business managers understand "services", but even they won't be > > motivated to lead SOA efforts. If you want to./" Yes, if IT wants to. My > > work is to make SOA the need of senior business managers, and I believe, > > IT can accomplish this task, especially, if consider there is be no > > resistance from the 'service' understanding senior business managers... > > > > Anne has concluded: "/Improve the architecture of your IT systems by > > adopting SO principles, the effort must be led by EAs/". If we use > > meaning of EA (Enterprise Architecture) as defined in TOGAF 8/9, i.e. > > where *EA = Technical Architecture (in IT)+ Business Architecture (in > > Business)*, I think, we all have got the common and solid agreement on > > the subject.>> > > > > You can read this at: > > > > This week I had an interesting discussion with Anne Thomas Manes of > > Burton Group <http://www.burtongroup.com/> and Rob Eamon > > <http://www.linkedin.com/in/reamon> about where SOA has to be - in > > Technology/IT, or in Business, or anywhere else. I would like to > > represent the arguments and contra-arguments of this debate for you to > > make your own opinion. > > > > The discussion has been started by Anne's recent post that once again > > explained her almost revolutionary statement: "/SOA is Dead; Long Live > > Services/" made in January, 2009. Many architects, managers, and bolgers > > responded that time because the statement was misread initially. Finally > > the discussion pacified due to the context of the statement that was > > very clear: "/"SOA" as a term has lost its luster, but "SOA" as a > > practice is essential for all organizations going forward/". It is > > almost obvious that the SOA term has been obfuscated in the industry by > > the details of implementations that did not in fact grasp the concept of > > service orientation. In reality, *service orientation is very powerful > > and highly permissible concept of modelling actual life*. > > > > Among others, Anne has quoted John Rymer who said: "/SOA died a > > marketing death/", "/When a technology becomes vital, it dies in a > > marketing sense/," he explained. "I/t's time for SOA to 'die' since it's > > not distinguishable anymore since everybody's using it./" I do not think > > that Anne's based her conclusion on the marketing trends; there is a > > fact that many organisations started to cut their investments in to SOA > > projects in IT because those IT failed to provide for their promises > > made about SOA economic efficiency. At the same time, we also have many > > examples of SOA success in other organisations. The question is: why SOA > > projects in IT have lost business trust to the degree that this become > > almost an industry trend? > > > > In the comments to the Anne's post, Rob outlined that IT reached the > > stage where isolated individual "SOA initiative" (that I called 'SOA > > projects' ) have demonstrated their incapability to reach the value of > > service-oriented solution in "/organically growing SOA/", i.e. SOA must > > be treated at the enterprise level to be productive and should be driven > > by the Business. > > > > I usually promote similar approach to *SOA *explaining it as *a > > business-oriented consumer-centric architectural model*. *Any violations > > of mentioned characteristics lead to SOA failure*. This, IMO, is the > > reason of multiple failures in SOA area - use of Web Services for > > integration of applications somewhere in the IT depth has a very far-off > > effect to the business, if any; composing existing legacy applications > > to satisfy immediate business needs without any perspective view on the > > changes that come tomorrow leads to the waist of IT resources and only > > increases the cost of IT efforts; disconnection between IT projects > > disallows appropriate project funding and planning of implementation of > > service oriented solutions (SOS); and, finally, still process-oriented > > nature of low-level business operations constantly conflicts with > > potential service-oriented technical solutions (because an effective IT > > solution can overcome the operational process while, instead, the > > process downgrades the SOS to the level of process actions and nothing > > more, i.e. potential efficiency of SOS is constantly compromised by > > inefficiency of the process). > > > > Anne's response was a bit unexpected: "/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/." The essence of my position is that *business > > requirements derived from non-service oriented business implementation* > > (i.e. business operational processes) *kill SOA in IT*; does not matter > > what IT does, SOS is not needed for such requirements. > > > > *For SOA to succeed in mass, Business has to be deeply involved in SOS > > and, correspondingly, has to influence system architecture design*. > > Despite SOA was initially defined as "/an IT architectural style/", in > > nowadays we have achieved the understanding that /service-oriented > > principles can drive Business even more effectively than IT/; that _SOA > > must be driven by Business and than cascaded into IT if an organisation > > wants to gain maximum efficiency from its service-oriented initiatives. _ > > > > Only in the situation described above, IT will get service-oriented > > requirements and will be able to respond with service-oriented technical > > solutions. IMO, SOA, more accurately, service orientation, moves from IT > > into Business. I think, Anne and me were closing our positions when Anne > > said: "/SOA must be business-driven (i.e., the goals of the SOA effort > > should be focused on generating positive business outcomes), but it > > should not be driven by business people. > > (Business people don't grok the necessity of SOA, and therefore they > > will not be good leaders for the effort.)/" > > > > This is the crucial pint of the discussion - in my opinion, if SOA has > > its 'ceiling' in process-centric low-level business operations and > > locked in IT, there is 'no-go' for SOA. But it is not clear to me why it > > should be this way. In my findings, business people who are in direct > > contact with IT don't, indeed, '/grok the necessity of SOA/' while the > > business people at a layer above, actually, do. At the top of the > > business hierarchy, people operate primarily in services, they deal with > > WHAT, WHY and WHO does the business, the lower business layers have to > > figure out HOW the business tasks may be relaised. If IT is not treated, > > at least, equally to these lower business layers and cannot really > > contribute into HOW technical capabilities can innovate business > > solutions, there is very little chance for SOS to be effective and, > > thus, survive at all (currently, IT is positioned UNDER the lower > > business layers and plays the role of 'forever follower'). > > > > Finally, who has to lead SOA efforts? Anne says: "/I agree that senior > > business managers understand "services", but even they won't be > > motivated to lead SOA efforts. If you want to./" Yes, if IT wants to. My > > work is to make SOA the need of senior business managers, and I believe, > > IT can accomplish this task, especially, if consider there is be no > > resistance from the 'service' understanding senior business managers... > > > > Anne has concluded: "/Improve the architecture of your IT systems by > > adopting SO principles, the effort must be led by EAs/". If we use > > meaning of EA (Enterprise Architecture) as defined in TOGAF 8/9, i.e. > > where *EA = Technical Architecture (in IT)+ Business Architecture (in > > Business)*, I think, we all have got the common and solid agreement on > > the subject. > > > > Gervas > > >
