--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > I am not sure that this Forum is for discussing business structures but, I think, that statement "the business is naturally divided into traditional siloes" requires more accurate analysis than from 20000 feet.
Michael, perhaps I should enlarge here and parachute down a bit: business are traditionally divided into distinct departments as we know, e.g. manufacturing, R&D, finance, sales and marketing, human remains and logistics. One of the major challenges of running any large organisation is getting these departments to communicate and cooperate constructively, as the departments often operate as semi-autonomous siloes. One way to get these distinct departments to cooperate is by implementing processes which operate across departments. An oft quoted example is the processing of a customer order which will typically involve sales, finance, logistics etc. I am not denying that processes link departments, I am merely pointing out the silo-like barriers which tend to arise naturally. > > 1) Business implements its daily operations siloes, this part is correct, but the higher you move along the business pyramid, the more it appears as service-oriented. This is the level the SOA has to be highlighted > > 2) Accepting that Service-first, Process-second at the top of the pyramid, I have identified two types of the business process at the lower levels in my to-be published book. They are: 5776.<SPAN id="misspell-6" class="mark" >indd</SPAN>Business Operational Processes are and 5776.<SPAN id="misspell-7" class="mark" >indd</SPAN>Operational Support Process. Technology usually dealing with the latter and misses the real business picture. > > 3) "SOA ... more disruptive and controversial at the business level" where the level is the Operational Support Process. Technology represents a threat to this level due to modern technical capabilities and ability to understand the business operations. Some Businesses keep IT in isolation deliberately. The opposite examples are a STP (straight-through process) in finance and an end-to-end automated trading transactions where majority of Operational Support Processes are eliminated. I guess STP is a fairly special case where critical commercial imperatives are imposed for obvious reasons. Gervas > > - Michael > > 5776.<SPAN id="misspell-15" class="mark" >indd</SPAN> > > > ________________________________ > From: Gervas Douglas <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, October 29, 2008 1:15:44 AM > Subject: [service-orientated-architecture] Re: Rhody tells you how to sell SOA > > > --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin > <m3poulin@ .> wrote: > > > > I prefer to calculate ROI instead of cost, and two values - > short-term and long-term ROI. A lot of current problems in the > companies is in that they calculated just the cost of > implementation. .. Do you know how to calculate potential benefits in > monetary metrics? > > Almost certainly not to any meaningful degree. One of the significant > problems to do with a strategic adoption of SOA is quantifying the > ROI. So what is the answer? Persuade them to adopt SOA as a business > strategy when the business is naturally divided into traditional > siloes, or else take a more tactical approach, hoping that this will > seep upwards as a methodology? The RDBMS comparison is very > interesting, and no doubt a historical study of its progression > through the IT infrastructure would provide some useful pointers. > That said, is not SOA more strategic and there more disruptive and > controversial at the business level? > > Steve/Anne, how much success have you had in persuading businesses to > remodel their business structures on a SOA basis? I presume to ask > this as you are probably two of the members of this Group who, more > than most, have had to persuade people to understand the implications > of SOA in IT terms in a way which could provide strategic business > benefits. > > Contributions from others always welcome as well, of course! :) > > Gervas > > > > > - Michael > > > > > > > > > > ____________ _________ _________ __ > > From: htshozawa <htshozawa@ ..> > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Monday, October 27, 2008 9:59:17 PM > > Subject: [service-orientated -architecture] Re: Rhody tells you how > to sell SOA > > > > > > Understood. The definition of flexibility isn't ambigous. > > > > Also want to point out the there is a cost associated with obtaining > > flexibility. I think it's better to calculate the benefit that may be > > obtained from flexibility to see if it is more than the cost > > associated with it. > > > > H.Ozawa > > > > --- In service-orientated- architecture@ yahoogroups. com, Michael > > Poulin <m3poulin@ .> wrote: > > > > > > Exactly, it "does not equal profit", and may be not good for every > > process. If I look at the Business with Service Eye (where process is > > just an implementation) , flexibility is what is needed in frequently > > changing external environment. If the latter does not change or > > changes slowly, flexibility is not that crucial. > > > > > > So, the first is a requirement for flexibility that comes from the > > business needs/market/ external environment; which business > > service/process has to be made flexible is the second. > > > > > > I tried to point that flexibility is not that ambiguous. > > > > > > - Michael > > > > > >
