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]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jerry Zhu
Sent: Monday, April 02, 2007 8:42 AM
To: [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/>
