> <<The way I introduce organizational change is bottom-up, first creating clarity as to the source of problems in all the people involved>>
> - this is not quite clear to me What I'm saying is that the people involved need to have clarity themselves on what the source is. > Why do you conclude that the people who cause the problems are not at the top of the management hierarchy, or at its middle? I absolutely expect that those people are at least part of the problem, given their stake in the current organizational structure. Changing those peoples perspective requires a great deal of leverage - one that I find a bottom-up approach facilitates with minimal risk. > I have seen too many cases when the problem was down-streamed Me too - that's why I start with getting clarity on how far upstream the source is. > How do you deal with such cause of the organisational change? Sometimes I try the 5-whys, or "what can we do to prevent the inevitable mistakes that people make from causing bigger problems?", in other words, I try to take what's been identified as a people problem and rephrase it as a process problem - that helps me move the discussion upstream. Thoughts? -- Udi Dahan From: [email protected] [mailto:[email protected]] On Behalf Of Michael Poulin Sent: Monday, June 08, 2009 10:20 PM To: [email protected] Subject: Re: [service-orientated-architecture] Re: Anne again on SOA's Mortality <<The way I introduce organizational change is bottom-up, first creating clarity as to the source of problems in all the people involved>> - this is not quite clear to me. Do you, Udi, say that "the source of problems" IS "in all the people involved"? According to your reference to Toyota, it is. But how can you conclude that from this that it is a bottom-up path? Why do you conclude that the people who cause the problems are not at the top of the management hierarchy, or at its middle? If you mean that you start with the problem in hands (to facilitate an organisational change) and moving 'along' people involved, I probably, get it. However, I have seen too many cases when the problem was down-streamed (in the search of the last one in the queue to beat). How do you deal with such cause of the organisational change? - Michael _____ From: Udi Dahan <[email protected]> To: [email protected] Sent: Monday, June 8, 2009 7:53:32 AM Subject: RE: [service-orientated-architecture] Re: Anne again on SOA's Mortality > Is there a need for each project in an initiative to show some benefit I believe so. As a consultant often brought in to solve other problems, organizational service-orientation is my compass, for the simple reason that the source of so many of the problems I'm brought in to solve is organizational structure. Unclear boundaries and processes between departments lead to many destructive behaviors that ultimately appear as problems like performance, stability, scalability, etc. As in the Toyota way, every problem is a people problem and a process problem - both rooted in a non SO organization. However, for me to have the time and maneuvering space to deal with the organizational issues, I need to show benefit and ROI on each project, as well as sell myself into the next project. The way I introduce organizational change is bottom-up, first creating clarity as to the source of problems in all the people involved. Once there's enough inertia around that, I take the relevant leaders and bring it up the organizational chain along with several solutions that have been brain-stormed by the group. At that point, upper management after having their key people describe that the problems were actually symptoms, what the root cause was, and possible solutions, it's fairly easy for management to get on board. Of course, this process can take months, but serves as the grease to further change. At every point, benefit is shown, as well as the potential for more benefit in taking the next step. All this is done without any explicit connection to SO - it's business, bottom-line, time to market, etc which drive everything. SOA is a thinking tool for identifying root cause problems as well as pointing out solutions, but doesn't need to take center stage. In this kind of work, the organization is the "system", and the goal is to identify loosely-coupled autonomous services, and their collaborations. In this model, people are often the implementation of these services, though it is quite common to see a mix of people and automation. Granted - organizational change doesn't happen easily, and often it's only on the back of severe crisis that it happens. Luckily (?) we're in a good time for that :-) Would love to hear others' experiences. -- Udi Dahan From: service-orientated- architecture@ yahoogroups. com [mailto:service- orientated- architecture@ yahoogroups. com] On Behalf Of Hitoshi Ozawa Sent: Sunday, June 07, 2009 3:48 PM To: service-orientated- architecture@ yahoogroups. com Subject: Re: [service-orientated -architecture] Re: Anne again on SOA's Mortality Hi, Rethought about your question. Bottom-up, top-down, middle-out are usually terms we use when designing a service in a project. Initiative usually span several projects with the goal of reorganization the organization. IMHO, SO principles used in EA may be seen as a sustaining technology while SOA may be seens as a disruptive technology to something like EA, which usually require high initial investment and long span to obtain ROI. I view SOA as offering lower initial investment and shorter time to obtain ROI. The downside is that it will require higher total investment and longer total time, but there is less risk and an organization can get started in a money strapped economy as we have now and with new services being offered to stay competitive. As an example, I can pay my gas bill, water bill, electric bill, property taxes at a corner convenience store in Japan that's open 24 hours a day, 365 days a year. There is also a ATM where I can deposit, withdraw, transfer payments from banks that has agreement with the convenience store. The convenience stores actually competes on offering more services than the other local convenience stores. In banking, there were merger were repeated several time within few years. Regulation changed enabling companies to start Internet banks. Now, it's possible to buy items from my mobile phone and to pay for the item from my bank account. It used to be that I needed my normal banking account, another account for Internet banking, and yet another for the mobile phone. However, when a bank offered a service to have a single account that is able to be used in all these "devices", the other banks were forced to offer the same service. SOA as an disruptive technology allows new organizations to enter a market with lower initial cost and low operational cost to support new services. The question you've posted brought another interesting question. Is there a need for each project in an initiative to show some benefit compared to the old ways, or it is sufficient to just show the total benefit at the end of the initiative. :-) H.Ozawa 2009/6/6 Udi Dahan <thesoftwaresimplist @gmail.com <mailto:thesoftwaresimplist%40gmail.com> >: > > > Hitoshi, > > > > I wasn't being prescriptive on how we service-orient the organization > (bottom-up, top-down, middle-out, whatever), that's a different discussion. > > I just wanted to see if we could get clarity on the need. > > > > Best regards, > > > > -- Udi Dahan > > > > From: service-orientated- architecture@ yahoogroups. com <mailto:service-orientated-architecture%40yahoogroups.com> > [mailto:service-orientated- architecture@ yahoogroups. com <mailto:service-orientated-architecture%40yahoogroups.com> ] On Behalf Of > Hitoshi Ozawa > Sent: Friday, June 05, 2009 4:22 PM > > To: service-orientated- architecture@ yahoogroups. com <mailto:service-orientated-architecture%40yahoogroups.com> > Subject: Re: [service-orientated -architecture] Re: Anne again on SOA's > Mortality > > > > > Hi Udi, > > This is one of the topic that's come up often. > Unfortunately, I'm on the disagreeing side from Anne. It's nice to see > EA initiative start from the top, but I see it too often to start from > a single successful project and to spread to other projects. I see SOA > as more of a concept that will allow a system to evolve with new > requirements as it spreads through the enterprise rather than > initially creating a fixed set of rules. I agree that each business > unit operates like a little fiefdom. I see SOA as a concept that will > gradually enable these little fiefdom to better work together rather > than requiring a sudden drastic organizational change to create one > harmonious community. > > Well, since Anne stated that SOA is dead, does this mean she's given > up on trying to revolutionize the entire enterprise and decided to > focus just on the service between these silos? :-) > > H.Ozawa > > 2009/6/5 Udi Dahan <thesoftwaresimplist @gmail.com <mailto:thesoftwaresimplist%40gmail.com> >: >> >> >> On Anne's comment: >> >> >> >> " Most large organizations are NOT especially service oriented >> >> internally. Each business unit operates like a little fiefdom. They >> >> all do things their own way. That use their own special processes, and >> >> they implement redundant, incompatible systems to support their >> >> unique, special processes. It's this "I'm special" way of thinking >> >> that has led to the application silos of today." >> >> >> >> Pulling in Rob's analysis: >> >> >> >> " SO is simply another way to modularize a system into components. (The >> "system" might be an entire company.)" >> >> >> >> And the oft-stated goal of aligning IT with business - because if it isn't >> aligned we run into serious problems as Steve mentions: >> >> >> >> " I find IT to be reactionary and protectionist. .." >> >> >> >> And given the diversity in each of our backgrounds and experiences, in >> order >> to deal with the issues Anne raises above, it sounds like if we don't >> service-orient the organization, we're in trouble anyway. >> >> >> >> Thoughts? >> >> >> >> -- Udi Dahan >> >> >> >> From: service-orientated- <mailto:service-orientated-architecture%40yahoogroups.com> architecture@ yahoogroups. com >> [mailto:service-orientated- <mailto:service-orientated-architecture%40yahoogroups.com> architecture@ yahoogroups. com] On Behalf Of Anne >> Thomas Manes >> Sent: Thursday, June 04, 2009 3:56 PM >> To: service-orientated- architecture@ yahoogroups. com <mailto:service-orientated-architecture%40yahoogroups.com> >> Subject: Re: [service-orientated -architecture] Re: Anne again on SOA's >> Mortality >> >> >> >> >> Most large organizations are NOT especially service oriented >> internally. Each business unit operates like a little fiefdom. They >> all do things their own way. That use their own special processes, and >> they implement redundant, incompatible systems to support their >> unique, special processes. It's this "I'm special" way of thinking >> that has led to the application silos of today. >> >> From an organizational perspective, most IT groups emulate (i.e., are >> aligned with) these business units. Alignment (from an organizational >> perspective) is not what IT needs. The more successful SOA initiatives >> are those that begin with a reorganization of IT -- moving away from >> business organization alignment. The IT group either creates a general >> pool or it aligns to business capabilities (billing, procurement, >> fulfillment, etc). >> >> I just can't see a SOA initiative being run by "the business" (i.e., >> business people). If it is run by a particular business unit, then it >> would focus only on the needs of that business unit -- and they would >> perpetuate the application silos that exist today. They only model >> that might fit is if the CEO established a new unit that manages >> cross-enterprise operations -- the equivalent of an EA group on the >> business side. >> >> Anne >> >> On Wed, Jun 3, 2009 at 11:56 PM, htshozawa <htshoz...@gmail. com <mailto:htshozawa%40gmail.com> > wrote: >>> >>> >>> External and internal are relative terms. It depends on a company, but >>> many >>> large companies having several departments have well defined interfaces >>> between departments (in appearances anyways. :-)) Well, we could say >>> internal to the department, to section, to group, to team, to a person? >>> :-) >>> >>> One of the goals of SOA is to better align business and IT. If we are >>> talking about just applying SO on a business side, what is the goal? What >>> is >>> the difference between it with BPR? >>> >>> H.Ozawa >>> >>> --- In service-orientated- <mailto:service-orientated-architecture%40yahoogroups.com> architecture@ yahoogroups. com, Nick Gall >>> <nick.g...@.. .> wrote: >>>> >>>> While SO may not be a new concept for some businesses EXTERNAL >>>> relationships, it is a NEW concept for internal relationships. For >>>> example, >>>> even though most banks have seen themselves for many years as >>>> financial *services >>>> *companies on the outside, they have failed to apply SO on the inside. >>>> >>>> So it IS a new concept for how to organize the INTERNAL capabilities of >>>> the >>>> enterprise for MOST businesses. >>>> >>>> -- Nick >>>> >>> >>> >> >> > >
<<image001.jpg>>
<<image002.jpg>>
