| |
 |
|
 |
Exchange Migration as a Path Toward Reinvention
With Thierry Demorre and Elias VarVarezis, Avanade
Technology seems to constantly call for us to update, upgrade, improve, change.
It's a call we've almost hardened against. Everyone seems to have a story about
that one big upgrade or migration that was supposed to solve the ills of the
world, only to find the grass was-quite frankly-exactly the same color on the
other side of the fence.
The following conversation with experts in the area of Microsoft messaging and
the new opportunities Exchange 2003 can open begins to reveal significant
optimism tempered with serious realism. Perhaps what will be most surprising to
some is that technology appears to be the least of our concerns here.
We have the pleasure of introducing two significant experts in the field of
Microsoft Exchange, Thierry Demorre and Elias VarVarezis, both of whom bring
particular depth in technology and implementation practices. So, without
further adieu...
Why Migrate?
Surprises
Taking the Right First Steps
Getting It Done Right
Final Thoughts
Why Migrate?
| Thierry: |
You will always need a compelling reason to address a fundamental
business decision like migration. Sunsetting support for the NT4 platform, not
to mention near-discontinued support on other technology platforms entirely,
all contribute to primary reasons for migration. Ultimately, though, it comes
down to Total Cost of Ownership (TCO). You have to be able to understand and
prove a cost-benefit for migrating that meets both short-term and long-term
needs.
Simply put, the new version of Exchange is more scaleable, allowing you to, for
instance, reduce the number of servers you have in play. This consolidation
begs a number of questions in large organizations though. You have to consider
that when you begin consolidating servers you are also consolidating work
process, personnel, physical assets, and more. The issue quickly moves beyond a
technology-focused solution.
|
|
| Elias: |
Consolidation is key. However, like Thierry says, it quickly
becomes a business decision. That means a business manager should be as
involved in determining if server reduction is more cost effective than putting
a server out in the field as a technologist.
From a purely technical perspective, Exchange 2003 allows you to leave your
server and infrastructure configuration much the way it currently stands. It
also supports radical re-thought of your network configuration and
communication flow. Making the right decision is a matter of best practice and
an understanding of how a major reconfiguration can begin to impact more than
hardware allocations or network bandwidth usage.
back to top
|
|
| Surprises |
|
|
| Thierry: |
Because Exchange 5.5 is familiar and since approaches to such
things as directory structure and server configuration have been handled the
same way for so long, many of my customers come to Exchange 2003 thinking of it
as a simple upgrade. It's much more than upgrading software though.
As Elias alluded, you may well need to change your operating model. You may
have to change how you think about your organization and the way you support
communications. That's a bigger challenge than any technical challenge you'll
face. At least if you want to get the real benefit out of a migration of this
nature.
You can think of it this way. I have a client who supports a global
communications structure with thousands of users and hundreds of servers in
their infrastructure. Any organization that supports hundreds of servers has
had to introduce a level of intermediary management to support servers in the
field, local configuration, user setup, and more. But this introduction of
mid-level personnel and the inherent processes, security, and facility
implications reduce the agility of the organization. So when my client
considered something as basic as server consolidation with Exchange 2003, it
became apparent that the bigger benefit to the CIO was regaining control over
his organization.
Think of it. Fewer people involved in the implementation, maintenance, and
support of a communications infrastructure means a more agile global operation.
It also means that security processes are easier to implement, audit, and
improve. We could easily put the same antivirus software on all servers,
implement a single entry point for all network users, quarantine problems more
effectively, and so on.
In my case, I ended up helping to create a situation where my client inherited
a global IT team that was more manageable and a user community that felt like
they were in better control of their communications environment.
back to top
|
|
| Taking the Right First Steps |
|
| Elias: |
Where do I begin? I'll just list a few of the high-points I
encounter with customers who are taking the first steps in implementing
Exchange 2003.
The first is plain and simple: Politics don't have a place in the design of an
Exchange 2003 solution. They can't. Once you introduce political issues into
the design process, you've compromised the solution and you may as well
reconsider if you're ready for a new solution at all. I know that's a strong
statement, so let me also stress that this is not to say that you should be
insensitive to the political impact that a new approach and design may have on
your organization. That's an issue you and your implementation partner must be
comfortable addressing in a forthright and effective manner.
Another stepping-off point where I often get involved is in the RFP process.
The common mistake I see is the inclusion of design directly in the RFP. That's
prescriptive. And most often it's very limiting to the development of a
solution that is right for your organization. Of course, if you truly stepped
back and developed a design that is based on the benefits afforded by Exchange
2003 (perhaps with an outside partner), then you should put it in the RFP. I
just have yet to see that happen. More often, design in an RFP is the
recreation of a current design cast into what the customer thinks the Exchange
2003 environment should be.
During the RFP process I also see a lot of customers receive wide-ranging
implementation costs. I have had too many conversations with customers who
think "Vendor A" is considerably cheaper than "Vendor B" only to find out that
the former didn't have the understanding needed to implement a full solution.
Therefore, aspects crucial to the success of the implementation were left out.
Today, pricing in the market is basically the same. A 40-50% cost range in RFP
responses indicates difference in services to be provided and especially in
Exchange 2003, it means further clarification may be needed before making a
decision. |
|
| Thierry: |
For my part, I would just add that I often see clients address
migrations with third-party tools that can't deliver on their promises. Too
many migration tools try to be everything to everyone. They end up unable to
solve basic issues.
I was involved personally in a situation where a customer invested heavily in a
migration tool to speed up common processes like directory synchronization,
mailbox migration, object integration, etc. But the tool was too generic. After
spending considerable time on testing, they finally found it would not meet all
of the project requirements. We created a new migration tool that was simple
and got the job done. Fortunately for us (and any customer we work with next)
Avanade now has an asset that addresses many of the specific issues this client
was trying to solve with an off-the-shelf solution. Except we do it in
bite-sized chunks that can be managed.
I often find that specific scenarios require custom development. You can't be
afraid to create a tool that is adapted to the way you are working. You cannot
adapt to the tool and be successful.
|
|
| Elias: |
I would second that statement. Technology must reflect how you do
business, not the other way around.
Another area that should be reviewed are the Service Level Agreements (SLAs)
for the current messaging solution in respect to the business. SLAs often
aren't written properly. Your SLAs should be explicit in defining the
availability of a service from end to end instead of availability of the
servers. What good is it to have a server working if no user can access the
services it is providing?
You have to focus on end to end service and capability. Ask yourself one simple
question: what does it cost my organization if the service goes down? If you
can't answer this question, you can't make smart decisions about high
availability architecture that ultimately affect how you architect your
Exchange solution in respect to costs associated with redundancies. For
instance, before you begin architecting a contingency plan for a communications
outage, consider the type of outage. Is it a loss of data or a loss of
connectivity? If it is a loss of connectivity, can your workforce still be
effective without their data for a short period of time? Conversely, if the
outage is a loss of data, can the workforce be effective with maintained
network communication and availability to the service such as being able to
send and receive mail even though they lost their inbox mail for a period of
time? Answers to simple questions like these have a great impact on the
Exchange design required to meet your business requirements, as well as the
cost of implementing that design.
A proper review of an SLA addresses availability, performance, work load
levels, security, recoverability, affordability of the solution, and
accuracy-all in an even-handed manner. Clarifying service and capability
outside of existing hardware and software configurations also ensures you'll
streamline the SLA analysis process in the long-term and save yourself more
time and effort down the road in reference to the frequency in which SLA review
is conducted.
back to top
|
|
| Getting It Done Right |
|
| Thierry: |
I often tell my customers that you have to address an Exchange
migration from a business perspective first and a technology perspective
second. Technology, after all, has become the commodity in this equation. Once
it works right and you know how to implement it, any well-trained professional
should be able to implement.
The difference is how you implement. Knowing how to implement means you know
how to get to the root of business needs and you have a process for doing so.
If you are considering an Exchange migration and you are not directly
addressing business considerations as a distinct part of the project, you may
commit some of the same mistakes I have seen customers make recently with
Exchange 2003.
|
|
| Elias: |
I agree. I believe you just have to ask four simple questions
during the process of selecting an implementation partner. 1.) Where have you
done this before? 2.) Can I call those companies? 3.) Will the same people on
that project be working on mine? And, 4.) Can I interview your people?
You can't afford to have your implementation partner learning on your dime. You
can't afford it in terms of cost, time, and most importantly in terms of risk
to your operation. We all have to understand that when selecting a partner,
there is a boundary between what a consultancy has done and what the individual
has done. The right partner will be honest and forthright about this fact.
back to top
|
|
| Final Thoughts: |
|
| Thierry: |
I just want to stress the importance again of looking at an
Exchange migration to 2003 to be a fresh look at your messaging and
communications structure. This means putting a technology like Active Directory
to use in the most effective ways possible. It means not implementing
generically into an existing structure, but finding the way your business
should operate first and implementing a technology solution second. You have to
find someone you trust and with whom you can work effectively to do just that. |
|
| Elias: |
When you consider working with someone, you basically have four
approaches:
1.) Delegation of responsibility, where a consulting partner owns all the risk
2.) Collaboration, where the client and the consulting partner share the risk
3.) Workforce augmentation, where the client owns all the risk and requires
additional staff to execute
and, 4.) Advisor.
I strongly believe for clients moving from a non-Microsoft platforms to
Exchange that the best results for the Exchange migration project will come
from a collaborative approach where you have the greatest exposure for
knowledge transfer from your consulting partner . This type of consulting may
be a bit more expensive due to the "sharing of risk," but there is a real value
to it.
You'll also find that one of the most important aspects of the consultative
process is overlooked, which I believe is advisory. As we've said before in so
many words, implementation is a commodity. You pay for vision.
An advisor role should be tied to your success first, not the project or the
implementation partner. This person should look at things from a business
perspective, not a "technology-is-cool" perspective. An advisor must understand
your business in order to fit technology to your needs. In the best situations,
you see that advisement starts in the early stages of a relationship with a
consulting partner and is founded on trust.
You'll find an advisor in a senior member of a consulting team. Someone who is
not required to know everything from a technology perspective, but who knows
how to find the right information based on business understanding. This is the
person who you trust to impact the success of your career as much as the
success of a near-term Exchange migration project. The long-term vision is
likely to be a key factor in your own career growth.
back to top
|
|
|
|
|
