On 20/01/07, Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > > > > Steve wrote: > > Or of course there is the other option. That they are using large > > amounts of new technologies which have large associated license fees > > and are therefore having to train lots of staff which again has bigger > > costs and adds to the cost of projects as there is more uncertainty. > > Agree, this is also possible. However, in two cases I mentioned, it was > not about new technologies and about " swallowed the vendor kool-aid".
Fair enough, I've just found the two go together, "SOA is expensive because we had to buy 10 new products and now they don't work" > > > This is why I always recommend that people switch their > > governance and organisation first (which is cheap) before really > > moving on to doing enterprise wide SOA. > > 100% agree. We, probably, have to issue a recommendation (including > wining-and-dining) for IT on how to switch their organisations and > governance onto thinking in services. It is not a joke or sarcasm. Can we > come up with a list of first-hand recommendations? The SOA Anti-patterns piece @ Infoq might be a good start. There are a couple of advisory pieces I've done in the last few years around aligning organisational structures and governance to a business service architecture before you embark on transformation using SOA. My day-job concentration at the moment is mainly on that side with technology projects being the secondary part. 1) Define your business Service architecture 2) Define your governance structure aligned to the BSA 3) Build th heatmap 4) Align the organisation to the BSA and the heatmap 5) Move away from project based delivery to service based programmes 6) Consider new build in the same structure as existing support and development Those are my top six. > > - Michael > > > > > > Steve Jones <[EMAIL PROTECTED]> wrote: > > > Or of course there is the other option. That they are using large > amounts of new technologies which have large associated license fees > and are therefore having to train lots of staff which again has bigger > costs and adds to the cost of projects as there is more uncertainty. > > So this doesn't mean that they were doing well, just that they've > swallowed the vendor kool-aid and suprise, suprise it isn't delivering > the benefits. This is why I always recommend that people switch their > governance and organisation first (which is cheap) before really > moving on to doing enterprise wide SOA. Lobbing a WS on a project is > cheap, its when people try and do things at an enterprise level on a > purely technology basis that things don't work. > > On 20/01/07, Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > So, at least, two big companies in financial industry, IBT and Fidelity, > > claim that "SOA'ziation" IS more expensive and takes longer time to build > > than regular applications used in this industry. Why? My guess, it is > > because they are doing well already, without SOA. Or, their systems are > > already service-oriented enough for the corporate tasks(!?). > > > > I understand that "it is much much harder to make sure they are > conceptualized , design and coded to stay qualified as re-useable"; this is > because SOA mentality has not been accepted "down the line", to the > development. We know, this will take time and efforts. However, when we are > talking that SOA requires "more $$'s", I am curious, in comparison to what? > > > > From enterprise perspectives (not from individual project, however), > counting just development expenses is close to cheating because the cost > rocketing up in the maintenance and modification. SOA addresses the very > latter part and overall cost gets lower with SOA, for the enterprise. > > > > The concept of a "system in which various GUI's consume services that we > build as part of SOA", if quite rich and lucrative. I am working on this > right now as well. However, I found that it can be implemented iteratively, > i.e. not everything behind GUI should be a service right away. I am talking > about 'transition' layer of proxies that to be replaced when the services > are ready. As a result, investment into analysis and estimates gets spread > over multiple projects for certain period of time and appears as a strategic > roadmap. This also wins some time to make up the development minds to think > in services. > > > > - Michael Poulin > > > > > > > > > > "Sarode, Prashant" <[EMAIL PROTECTED]> wrote: > > > > > > > > Interesting comment-'SOA is a lifestyle' > > > > I just came out of an big program estimation mtg in which I was pointed > that the SOA'ziation of program was an expensive life-style and how using > 2007 technology we still need all those big hrs to build an system in which > various GUI's consume services that we build as part of SOA. > > > > It is easy to identify re-useable business services w/n an enterprise but > it is much much harder to make sure they are conceptualized , design and > coded to stay qualified as re-useable after the initial reuse discovery. > > > > Hence, long and expensive estimates and surprise to non-tech savy as to > why it will take longer and more $$'s to do SOA'ization of business > solutions. > > > > Prashant Sarode > > > > ----- Original Message ----- > > From: [email protected] > <[email protected]> > > To: [email protected] > <[email protected]> > > Sent: Fri Jan 19 07:29:37 2007 > > Subject: Re: [service-orientated-architecture] Schurter on BPM, SOA & > Software > > > > Hmmm. BPM is something you do, not something you buy. Sounds an awful > lot like SOA to me. I have plenty of examples of companies that have saved > lots of money, improved time-to-market, and reduce application maintenance > through proper application of SOA principles.In the process, they also > consolidated their application portfolio and gotten a much better handle on > their data. But in order to do so, you have to do a fair amount of > enterprise planning, pick the right projects, deploy a shared > infrastructure, institute a governance program, and change the way people > design and build systems. > > > > SOA is NOT about technology, but technology can facilitate its adoption. > SOA is a set of design principles, and to be successful with SOA, you must > adopt those principles. SOA is a lifestyle. > > > > Anne > > > > > > On 1/19/07, Gervas Douglas <[EMAIL PROTECTED] <mailto:[EMAIL > PROTECTED]> > wrote: > > > > There are some comments on SOA and its business value which may > > interest you here: > > > > > http://tech.groups.yahoo.com/group/business-process-management/message/270 > <http://tech.groups.yahoo.com/group/business-process-management/message/270> > > > > Gervas > > > > > > > > > > > > > > > > > > > > ________________________________ > Check out the all-new Yahoo! Mail beta - Fire up a more powerful email > and get things done faster. > > > > > > > > > > > > ________________________________ Have a burning question? Go to Yahoo! Answers and get answers from real people who know. > > > >
