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} -->
