Standardized infrastructure is probably the better way of putting it, rather than shared infrastructure, although it's not a big stretch to go from one to the other. As for the ERP scenario you provided, there any a number of things to consider, without which, I wouldn't go on the record for recommending any particular solution. For example, are these company owned plants or manufacturing partners? If they are partners, there are few companies (e.g. WalMart) that have the muscle to actually dictate infrastructure standards. You can dictate integration standards, but it's all about boundaries of control. If they are company-owned, you do have to take geography into account. What may make sense in the US may not make sense in India.
If I had to make some general statements, I'd start with standardizing (and sharing) infrastructure within each center. In other words, stay within the existing geographic boundaries. The next step would consolidation across like centers, such as sharing infrastructure across two US facilities. As reliability, availability, etc. improves globally, you could consider other consolidation. One thing I'll point out, however. My definition of "infrastructure" in my original email was the low level plumbing, i.e. physical servers, operating systems, networking appliances, etc., not applications. Standardization and sharing of infrastructure at this level, does not require standardized business processes. Sharing and standardization of applications, including ERP, clearly does require a level of standardization in the business processes supported by those systems. -tb On Apr 2, 2007, at 10:41 AM, Jerry Zhu wrote: > 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]> 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/ > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
