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.”
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.