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.
