IT is broken. The question is how much are you willing to spend this
year to fix it, and how soon does the company need to see a return on
investment to justify the expenditure.
I think the situation is a lot worse that this in more companies than we
imagine, so much so, that ROI is no longer an issue. It's a flat-out
expense related to the cost of staying in business.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anne Thomas Manes
Sent: Tuesday, April 03, 2007 6:35 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Kaufman on Reuse
& SOA
Ahhh... but how much does it cost the company each year to
maintain a bunch of redundant ERP systems? In many large companies it is
measured in hundreds of millions of dollars. Application consolidation
pays for itself quite quickly. That's why people are doing it.
Organizations spend way to much just keeping the lights on. They
have very little money left to spend on new projects and innovation. And
a significant portion of every new project is spent on integrating with
the legacy systems. The argument in favor of application rationalization
is academic once you establish the metrics to measure that cost and
value of your applications.
IT is broken. The question is how much are you willing to spend
this year to fix it, and how soon does the company need to see a return
on investment to justify the expenditure.
Anne
On 03 Apr 2007 02:24:53 -0700, Steve Jones
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote:
Ahhh the vision of "one ERP" there is another angle here
which is "if it ain't broke don't fix it". The cost of doing an ERP
rationalisation strategy can be measured in the hundreds of millions,
its a nice idea that SAP or Oracle would do the rationalisation for free
but until I see a case study where that happened I'm not going to
believe that it is possible. Shifting to a global vanilla (or standard
configured) instance is a major programme of work, both in terms of
operations and in terms of training and "buy-in", treating it as a pure
technology exercise is a sure way to have some fairly major problems
down the road (and ERP is littered with massive numbers of high cost
failures).
So surely the SOA approach is "if it works for you then
fine, we need to wrap it and expose it in a standardised way so it plays
nicely in the enterprise playground" that way it is up to the business
whether, and when, rationalisation happens and the rationalisation can
be "hidden" from the rest of the business via business services and
their ultimate technical implementation. Big bang ERP upgrade is on its
way out, the future is incremental upgrade, and its the business service
view that will enable that to happen.
Steve
On 02 Apr 2007 09:07:13 -0700, Bill Barr <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote:
The solution is remote integration that
integrates 50
disparate ERPs in each distributor site. ESB is
best
way to go as of today.
No, there's a much easier way. Discover which of
those 50 share the same vendor and if there are 2 or more, call up each
vendor and have them come do the integration/consolidation of their own
systems, free of charge. Then, pit the vendors against each other for
the best and lowest-cost migration path to one ERP system; the
efficiency and effectiveness of their first-round consolidation will
weigh heavily when selecting the final, sole ERP vendor. Astute vendor
management is a better solution than technology.
--
email: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
________________________________
From:
[email protected]
<mailto:[email protected]>
[mailto:service- [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Jerry
Zhu
Sent: Monday, April 02, 2007 8:42 AM
To:
[email protected]
<mailto:[email protected]>
Subject: Re:
[service-orientated-architecture] Kaufman on Reuse & SOA
Shared infrastructure... interesting.
What about a manufacturer having 50
plants all over
the world distributing their products to
large
retailers such as Home Depot and Lowe's
and 60
independent distributors. There are 50
ERPs. One
business goal is to have distributors
directly
participating inventory management to
achive real time
order fufilment across the world.
The solution is remote integration that
integrates 50
disparate EPRs in each distributor site.
ESB is best
way to go as of today.
How your shared infrastructure concept
fit into this
scenario? Factor out from 50 ERP systems
and
construct one ERP infrastructure hosted
in the Corp
headquater?
I think that there are three
requirements to have a
shared infrastruture: shared business
process,
Separation of business logic from data
logic, and
separation of content from presentation.
Jerry
--- Todd Biske < [EMAIL PROTECTED]
<mailto:todd.biske%40gmail.com> > wrote:
> This is a pretty good article,
however, they miss
> out on one
> important factor: Marketing. I still
refer back to
> a presentation I
> heard at SD East way back in 1998.
Unfortunately, I
> don't recall the
> speaker, but he had established reuse
programs at a
> variety of
> enterprises, some successful and some
not
> successful. He indicated
> that the factor that influenced
success the most was
> marketing. If
> the groups that had reusable
> components/services/whatever were able
> to do an effective job in marketing
their goods and
> getting the word
> out, the reuse program as a whole
would be more
> successful.
>
> This article focuses in on governance,
which is
> clearly an important
> aspect, but focusing in on governance
alone still
> means those service
> owners are sitting back and waiting
for customers to
> show up. While
> the architectural governance committee
will
> hopefully catch a good
> number of potential customers and send
them in the
> direction of the
> service owner, that committee should
be striving to
> reach "rubber
> stamp" status, meaning the project
teams should have
> already sought
> out potential services for reuse. This
means that
> the service owners
> need to be marketing their services
effectively so
> that they get
> found in the first place. I imagine
the potential
> customer using
> Google searches on the service
catalog, but then
> within the service
> catalog, you'd have a very Amazon-like
feel that may
> say things like
> "30% of other customers found this
service
> interesting..." Service
> owners would be monitoring this data
to understand
> why consumers are
> or are not using their services.
Interestingly,
> this is exactly what
> companies like Flashline and
ComponentSource were
> trying to do back
> in the 2000 timeframe, with Flashline
having a
> product to establish
> your own internal "marketplace" while
> ComponentSource was much more
> of a hosted solution intended at a
community broader
> than the
> enterprise. With the potential to
utilize hosted
> services always on
> the rise, this makes it even more
interesting,
> because you may want
> your service catalog to show you both
internally
> created solutions,
> as well as potential hosted solutions.
Think of it
> as amazon.com on
> the inside + with amazon partner
content integrated
> from the outside.
>
> This is a great conceptual model,
however, I don't
> know what the
> potential of this would be today. How
many
> enterprises have a
> service library large enough to
warrant establishing
> this rich of a
> marketplace-like infrastructure? If
you go beyond
> service reuse,
> however, and include shared libraries,
and even
> shared
> infrastructure, now the inventory may
be large
> enough to warrant an
> investment.
>
> Now time to copy and paste this into a
blog entry.
> -tb
>
> On Mar 30, 2007, at 4:06 AM, Gervas
Douglas wrote:
>
> > <<Improving the reusability of
business process
> and technology assets
> > helps businesses get to market
faster, reduce
> costs and achieve more
> > consistent results. This important
concept has
> recently been receiving
> > attention because Service Oriented
Architectures
> (SOA) are enabling
> > businesses to achieve much more
frequent and
> extensive reuse of
> > business services, software and
data.
> >
> > One of the main drivers for the
adoption of SOA is
> the business need
> > to be more flexible and responsive
to change.
> Change is part of the
> > business ecosystem. A long time
business partner
> can suddenly become a
> > fierce competitor as the result of a
merger. The
> dynamic between
> > partners, suppliers and customers is
in constant
> flux. A business
> > loses the ability to adapt if its
software and
> supporting IT
> > infrastructure is inflexible. And to
become more
> flexible, a
> > comprehensive strategy for reuse is
needed.
> >
> > The Nature of Reuse
> > Reuse is by no means a new concept
in IT. It has
> been tried in various
> > ways and at many levels from the use
of source
> code libraries to the
> > building of software components
within object
> oriented architectures.
> > When left to their own devices,
experienced
> developers usually find
> > ways to reuse the code they have
previously
> written or even use open
> > source code that is freely available
on the
> Internet. But such reuse
> > is never consistent throughout
software
> development teams and the IT
> > industry has never implemented reuse
effectively
> in this way.
> >
> > Within the SOA environment reuse is
different
> because it is woven into
> > the architecture. Components of
models, software,
> rules, and data are
> > made available for reuse in a way
that ensures
> their accuracy,
> > consistency and predictability. This
amounts to
> the business
> > governance of all the reusable
assets. It isn't
> easily achieved, but
> > it is a worthwhile goal.
> >
> > The reuse of IT assets is not so
different from
> the reuse of
> > components in manufacturing.
Automobile
> manufacturers do not make a
> > different engine for each model of
car they sell;
> they make a small
> > range of engines and install them in
a wide
> variety of models. Once a
> > new engine has been tested and
documented, its
> reuse in a wholly new
> > model gets the new car to market
much faster. The
> same is true of even
> > quite small components. Nowadays
cars are designed
> to maximize reuse
> > at every level-and to everyone's
benefit. And just
> as the reuse of
> > components in a production facility
needs to be
> managed carefully, so
> > must the reuse of business services
in a SOA
> environment. Reuse
> > without governance can be more
destructive to the
> business than no
> > reuse at all.
> >
> > Hurwitz & Associates has identified
three major
> risks to the business
> > associated with reuse:
> >
> > * Poor Process. This typically
occurs when the
> level of
> > collaboration between business and
IT is
> inadequate. Within SOA the
> > business and data services should
accurately
> represent the business
> > processes followed by the
organization.
> Collaboration between business
> > and IT needs to result in the
business having a
> clear understanding of
> > which definitions of data make sense
and when to
> use them, how to
> > apply rules and what level of
granularity is
> appropriate for business
> > services. Effective reuse will be
much harder to
> achieve unless there
> > is a framework in place that ensures
that business
> and IT are singing
> > from the same song sheet.
> > * Poor Management of Code. Business
processes
> are nearly always in
> > a state of flux, so it goes without
saying that
> the software code that
> > codifies a specific business service
may also
> change frequently. When
> > software components are changed then
the changes
> apply
> > everywhere-often resulting in
unintended
> consequences.
=== message truncated ===
__________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at
Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
<http://autos.yahoo.com/green_center/>
