The Desktop Transformation Implementation Cycle – Solutions Development – Part 1

By Greg LaVigne

Continuing the discussion with The
Desktop Transformational Implementation Cycle
, I’ll move to the next phase
which is Solutions Development.

The Solutions Development phase includes the architecture,
development and core infrastructure build out for the solution, or more likely,
solutions chosen to be implemented.

Figure 1 depicts what I consider to be a pretty complete
conceptual rendering of the various solutions that can comprise a wide scoping Desktop
Transformation effort. Not every organization is going to implement this full
model as each organization will define what solution set(s) will comprise their
journey and deliver the “biggest bang for the buck.”


DTIC-Solution Components

Figure 1: Desktop Transformation Solution Components


My next blog will go into
further detail on each component. However, for this entry I want to focus on
some common aspects that should be considered.

  • First, each of these boxes represents its own unique
    implementation and thus requires its own project and related implementation
    plan. There is significant integration between the various boxes, but not
    enough that each shouldn’t be isolated and managed independently. When
    designing for each, considerations around high availability, disaster recovery
    and business resumption should be considered and accounted for.
  • Second, the project plans for each of these demands its own
    operational readiness, support services and training education plan. It’s
    imperative that these be considered individually early on and up front to
    ensure proper monitoring, incident management and subsequent change management
    practices are built, implemented and leveraged. As further integration between
    solution sets occurs down the road, a foundation baseline has at least been
    established from a process perspective that can then be built upon.
  • Third, each solution should contain its own unique metrics
    that can be reported on, again laying that foundational baseline that can be
    added to down the road. The metrics should be SMART and meaningful so that they
    can be translated for both operational aspects as well as the business value
    they drive. Often times, metric reporting is completely overlooked, forgotten
    or simply never addressed. Now is the chance to be proactive (plus you’ll look
    like a “rock star”).
  • Finally, I’ve found that it’s important to build a
    conceptual model (like figure 1) that outlines the piece parts (i.e. components)
    that your entire solution set entails. Once built, keep it with you at all
    times as a reference that will be leveraged many times when discussing
    timeframes, rationale and integration points with management and customers.

One last thing to be mindful
of in this phase is that we’re simply designing core components and building a
base functional infrastructure. Scale out and capacity planning will be
discussed in subsequent steps.

Next up, we’ll break down
each of the components depicted in Figure 1. 


Written by , Posted .