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]> 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]> 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] > > > > ------------------------------ > *From:* [email protected] [mailto:service- > [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] <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/ > >
