Redundancy is appropriate when the business value contributed by the redundancy exceeds the costs of maintaining the redundancy. (and that pertains to high availability use cases, too.)
Anne On 12/20/08, Todd Biske <[email protected]> wrote: > My post was independent of the thread on Yefim's post. It was inspired > by some recent work. In general, we strive to reduce redundancy, but I > wanted to present some thoughts on where redundancy is acceptable or > even preferable. I would like to hear other's thoughts. Is redundancy > (outside of the context of high availability) acceptable, and if so, > when? > > -tb > > Todd Biske > http://www.biske.com/blog/ > Sent from my iPhone > > On Dec 20, 2008, at 7:26 AM, Anne Thomas Manes <[email protected]> > wrote: > >> When I wrote about redundancy in my response to Yefim's "SOA is >> integration" post, I was talking about a different kind of redundancy. >> I was talking about redundancy in the application and data portfolios >> -- not about redundancy in the IT toolbox portfolio. Reducing >> redundancy is a useful exercise in both areas. >> >> Anne >> >> On Sat, Dec 20, 2008 at 7:39 AM, Gervas Douglas >> <[email protected]> wrote: >> > You can read Todd's blog at: >> > >> > http://www.biske.com/blog/?p=585 >> > >> > Gervas >> > >> > <<A common theme that comes up in architecture discussions is the >> > elimination of redundancy. Simply stated, it's about finding >> systems that >> > are doing the same thing and getting rid of all of them except >> one. While >> > it's easily argued that there are cost savings just waiting to be >> realized, >> > does this mean that organizations should always strive to >> eliminate all >> > redundancy from their technology architectures? I think such a >> principle is >> > too restrictive. If you agree, then what should the principle be? >> > >> > The principle that I have used is that if I'm going to have two or >> more >> > solutions that appear to provide the same set of capabilities, >> then I must >> > have clear and unambiguous policies on when to use each of those >> solutions. >> > Those policies should be objective, not subjective. So, a policy >> that says >> > "Use Windows Server and .NET if your developer's preferred >> language is C#, >> > and use if your developer's preferred language is Java" deosn't >> cut it. A >> > policy that says, "Use C# for the presentation layer of desktop >> > (non-browser) applications, use Java for server-hosted business-tier >> > services" is fine. The development of these policies is seldom cut >> and dry, >> > however. Two factors that must be considered are the operational >> > model/organizational structure and the development-time values/costs >> > involved. >> > >> > On the operational model/organizational structure side of things, >> there may >> > be a temptation to align technology choices with the organizational >> > structure. While this may work for development, frequently, the >> engineering >> > and operations team are centralized, supporting all of the different >> > development organizations. If each development group is free to >> choose their >> > own technology, this adds cost to the engineering and operations >> team, as >> > they need expertise in all of the platforms involved. If the >> engineering and >> > operations functions are not centralized, then basing technology >> decisions >> > the org chart may not be as problematic. If you do this, however, >> keep in >> > mind that organizations change. An internal re-organization or a >> broader >> > merger/acquisition could completely change the foundation on which >> policies >> > were defined. >> > >> > On the development side of things, the common examples where this >> comes into >> > play are environments that involve Microsoft or SAP. Both of these >> > solutions, while certainly capable of operating in a heterogeneous >> > environment, provide significant value when you stay within their >> > environments. In the consumer space, Apple fits into this category >> as well. >> > Their model works best when it's all Apple/Microsoft/SAP from top- >> to-bottom. >> > There's certainly other examples, these are just ones that people >> will >> > associate with this more strongly than others. Using SAP as an >> example, they >> > provide both middleware (NetWeaver) and applications that leverage >> that >> > middleware. Is it possible to have SAP applications run on non-SAP >> > middleware? Certainly. Is there significant value-add if you use >> SAP's >> > middleware? Yes, it's very likely. If your entire infrastructure >> is SAP, >> > there's no decisions to be made. If not, now you have to decide >> whether you >> > want both SAP middleware and your other middleware, or not. >> Likewise, if >> > you've gone through a merger, and have both Microsoft middleware >> and Java >> > middleware, you're faced with the same decision. The SAP scenario >> is bit >> > more complicated because of the applications piece. If we were >> only talking >> > about custom development, the more likely choice is to go all >> Java, all C#, >> > or all -insert your language of choice-, along with the appropriate >> > middleware. Any argument about value-add of one over the other is >> > effectively a wash. When we're dealing with out-of-the-box >> applications, >> > it's a different scenario. If I deploy a SAP application that will >> > automatically leverage SAP middleware, that needs to be compared >> against >> > deploying the SAP application and then manually configuring the >> non-SAP >> > middleware. In effect, I create additional work by not using the SAP >> > middleware, which now chips away at the cost reductions I may have >> gained by >> > only going with a single source of middleware. >> > >> > So, the gist of this post is that a broad principle that says, >> "Eliminate >> > all redundancy" may not be well thought out. Rather, strive to >> reduce >> > redundancy where it makes sense, and where it doesn't, make sure >> that you >> > have clear and unambiguous policies that tells project teams how >> to choose >> > among the options. Make sure you consider all use cases, such as >> where the >> > solution may span domains. Your policies may say "use X if in >> domain X, use >> > Y if in domain Y," but you also need to give direction on how to >> use X and Y >> > when the solution requires communication across domains X and Y. >> If you >> > don't, projects will either choose what they want (subjective, >> bad), or come >> > back to you for direction anyway.>> >> > >> > >> -size: 100%; line-height: 122%; } #ygrp-sponsor .ad >> a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text- >> decoration: underline; } #ygrp-sponsor .ad p{ margin: 0; } >> o{font- >> size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: >> 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4} --> >
