+1 This is the "heatmap" bit that I get clients to do on their business services, its about understanding the business contract and value that IT delivers to the business service.
Redundancy in Utlity and Cost areas is completely pointless, in ROI areas its normally dangerous but in differentiating areas its often almost mandatory. Recently I've been looking at a lot of application rationalisation pieces using business services and heatmaps with a view to finding the real rationalisation areas rather than those areas that just happen to have a lot of overlapping applications. Steve 2008/12/20 Anne Thomas Manes <[email protected]>: > 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} --> >> >
