Expert answer:Technology Roadmap for Transforming an IT Environm
Expert answer:Construct a Technology Roadmap for moving your employer, or a firm with which you are familiar, from its current IT environment to the firm’s vision of where it wants to be. In the roadmap, summarize your approach to each of the seven activities described in the attached pdf. In a separate section, briefly address the difficulties you think you will face in trying to deal with the five Practical Steps mentioned in the attached pdf. Please be concise but comprehensive in your analysis of the seven activities and five steps.Requirements:Paper should be six to eight pages in length, not counting the title or reference pages, which must be included.Include at least three scholarly references.Paper must follow APA style guidelines, as appropriate.
pages_from_it_strategy_issues_and_practice___james_d__mckeen.pdf
Unformatted Attachment Preview
Chapter 19 • Creating and Evolving a Technology Roadmap
Current State
of
Technology
This
Gap
Drives the
Roadmap
Future State
Becomes
Current State
Over Time
Technology
Roadmap
Figure 19.1
Business
Initiatives
and Drivers
1.
2.
3.
4.
5.
6.
7.
Guiding Principles
Current Technology
Gap Analysis
Technology Landscape
Future Technology
Migration Strategy
Governance
The Process of Developing a Technology Roadmap
Activity #1: Guiding Principles
When launching a technology roadmap, it is important to establish a set of principles that will guide its development and enhancement. First and foremost, this is a
statement about the role and purpose of technology within the business that should
clearly convey aspirations and purpose. It outlines how technology will support the
business, stipulating the envisioned role for technology to play. This roadmap should
be a statement about the type of technology support to be delivered to the business
with a sense of performance. For example, contrast the following two statements:
“We will provide technology that is proven, reliable, and cost effective” and “We will
provide leading-edge technology.”
In addition to establishing the role and purpose for the technology roadmap, it
is important to outline its goals. One company’s goal for its technology roadmap was
“to increase the speed of developing, deploying, and productively executing future
business models.” It then outlined three strategies to accomplish this:
1. Decouple the business processes from the underlying IT applications.
2. Decouple business applications from the infrastructure.
3. Establish a new collaboration environment that supports the rapid introduction
and productive use of the new business processes.
This signaled to the organization that IT was adopting a service-oriented a rchitecture
(SOA). Because SOA was not well understood by the business, the technology roadmap spoke to the desire to identify components of the business model, which could be
designed as reusable software services; to adopt integrated and standardized processes
for optimizing cost; to accelerate integrated data/information architecture to enable horizontal integration across the enterprise; and to provide a stable, secure, and ubiquitous
287
288
Section IV • IT Portfolio Development and Management
workspace for employees to be more effective in their roles and efficient in their jobs by
delivering information, applications, and people to easily collaborate within the context
of business processes. This established the mandate, purpose, and goals of the techno
logy roadmap, using language appropriate for the organizational context.
With the purpose and goals established, guiding principles can then be articulated
to explain other key factors and decisions that would impact technology and, therefore,
have a bearing on the technology roadmap. The following statements are examples of
key principles used by focus group members:
•
•
•
•
•
•
•
•
•
•
Establish investment boundaries. “We will invest in technology at a rate necessary
to sustain our business growth.”
Outline the role of technology for the organization. “We will adopt a ‘fast follower’
strategy, aggressively adopting proven, architecturally compliant technologies.”
Outline the role of technology within the industry. “Technology is a core business
competency.”
Reinforce the role of standards. “All components will adhere to open industry
standards.”
Specify the role of support. “We will assist employees with technology problems
that occur via call centers, desktop support, self-help, and/or service-level
agreements.”
Specify the impact on resident IT skills. “We will draw technology expertise from
our existing large skill base.”
Outline development preference. “We will buy first, build second.”
Establish expectations. “Service levels and availability are outlined for all production systems.”
Adherence to regulatory standards. “We will be security and privacy compliant.”
Specify timeframe. “The ‘future’ in our technology roadmap has a three- to five-year
horizon.”
Activity #2: Assess Current Technology
This is basically an inventory. It should outline what technologies the business currently
has and describe their status (e.g., standard, unsupported, discontinued). The first task
is to develop a classification scheme to assist in managing the inventory. For each type
of technology domain (e.g., operating systems; hardware, desktops, servers, and storage;
telecommunications and networks; applications; and databases), members recommended
recording the following minimum information: business process area, platform, vendor,
level of support, dependencies (products, applications), critical versus noncritical, and
life cycle.
The next step is to assign a technology custodian/owner, so someone within the
firm is responsible for each technology domain. At one company, these individuals
are referred to as technology “domain architects.” Typical duties of such individuals
include acquiring the technology, maintaining the relationship with the vendor, updating
and enhancing the technology, facilitating in-house training for those working with the
technology, accreditation regarding the technology, recording all applications of the
technology, maintaining documentation (e.g., licensing; financing; and establishing service levels, guarantees, and warranties), and retiring the technology when appropriate.
Chapter 19 • Creating and Evolving a Technology Roadmap
This is a major responsibility particularly when individuals will have more than one
domain assigned to them.
One of the key tools in managing the technology inventory is a framework to
classify technologies. One such tool, the Application System Asset Management (ASAM)
Decision Chart (Mangurian 1985), assesses the business importance (i.e., the application’s overall value to the business), functional support (i.e., how well the s ystem meets
the business requirements), and technical support (i.e., the system’s e fficiency and effectiveness). This particular tool has been used successfully over a number of years by
one firm. On an annual basis, all application systems are evaluated against these three
criteria, leading to one of the following actions: maintain, renovate, replace, augment,
or eliminate.
Another company uses a two-by-two matrix that evaluates applications on the basis
of their criticality to the business (i.e., whether or not they support business processes
deemed critical to the business units) and their strategic importance (i.e., those providing
global functions that will not be replaced over the next two years). Placement within this
matrix (i.e., maintenance classification) dictates service levels: strategic/critical applications receive “gold” service; critical/nonstrategic applications receive “silver” service;
strategic/noncritical applications receive “bronze” service; and nonstrategic/noncritical
applications receive “blue” maintenance. Yet another company uses the “WISE” chart to
evaluate technologies on the basis of their strategic value and longevity, yielding four life
cycle stages: Watch, Invest, Support, and Eliminate (McKeen and Smith 2003).
The focus group agreed that the specific classification scheme matters less than the
fact that a company has a scheme to manage its technology inventory. The technology
inventory also provides input to other processes such as risk management, team development, and skills planning.
Activity #3: Analyze Gaps
With a technology inventory in place, organizations can perform a gap analysis between
the technology that is currently available and that which is required. The first step is to
identify the required technology. This ties the technology roadmap directly to the business and is perhaps the most crucial step in developing an effective plan. One manager
made this point rather emphatically by saying, “Get this wrong, and the roadmap is
junk.” Others suggested that simply asking business leaders for their future requirements will not work for a number of reasons. First, business leaders do not think in
terms of requirements; they think in terms of growth, customers, sales, markets, costs,
suppliers, and shareholders. It takes a lot of work and skill to translate this view of the
business into technology requirements. Second, the roadmap has to be ahead of the
business—that is, it must reflect the fact that because business changes faster than technology, you have to build technology in anticipation of business change and growth.
A technology roadmap cannot afford to be reactive; it must be proactive regardless of
whether the technology vision is “quick second” or “late adopter.” Third, business is
driven by innovation and differentiation, while IT benefits from standards, common
features, and universality. This will always put IT at odds with the business. According
to one participant, it boils down to the question, “When is a line of business so different
that common systems don’t make sense, and what criteria do you apply to test this?”
289
290
Section IV • IT Portfolio Development and Management
Eliciting business drivers and building a composite picture of the technology
required to support the business vision is more art than science. It requires close
cooperation between IT and the business. This cooperation happens at many levels
within the organization and should be an ongoing activity. The annual IT planning
cycle articulates the applications to be introduced over the next year, but attempting
to derive a technology roadmap from this activity is a case of “too little, too late.” IT
has to be working with the business closely enough to be well ahead of the annual
planning cycle. At one company, the domain architects are being reoriented to align
them closely with the business units to create a better early-warning system for
application needs driven by growth and changes to the business model. Its manager
stated the following:
The enterprise has a vision, and each line of business has a vision, and the job of the
domain architect is to put all these visions on the table to expose gaps. To do this,
architects need to be 75 percent business and 25 percent technology. Today they are the
reverse.
At another company, business analysts work together with enterprise architects to “get a fix on future business directions.” We tend to think of architects and
technical experts as playing the key roles, whereas the focus group pointed out that the
best vantage point for performing a gap analysis between the existing technology and
emerging business drivers is the CIO office, due to the fact that the CIO sits at the same
table as other senior executives to set the strategy for the business. The focus group
pointed out that having the CIO at these sessions provides a significant advantage in
terms of forecasting the future for technology within the company.
With a “line of sight” to the business strategy, coupled with an accurate technology
inventory, all the tools to perform a gap analysis are in place. The o
utcome of the gap
analysis is an articulation of the technology required to support the business’s vision
and strategy. Unfortunately, a technology roadmap cannot be simply created from
this analysis because it must also be governed by trends in the external environment.
Activity #4: Evaluate Technology Landscape
The group was unanimous in its recommendation that firms must continuously invest
in research and development (R&D) if they are to keep abreast of technology. The size
of this investment, however, differs depending on how critical IT is to a firm. The
roadmap should articulate how large this investment will be, how it will be enacted,
who is responsible, and what guidelines are in place to assist this initiative. Setting
these structures in place is the easy part; knowing when enough is enough is more
difficult.
In the past much of a company’s technology was dictated by its choice of vendor;
if asked what its technology roadmap was, a firm could simply reply by naming a
single vendor. Today’s lock-in by vendors is much reduced, particularly with the
widespread adoption of open standards, interoperability among various platforms,
Web, and cloud services. As a result, vendors must enact different strategies to win
over clients as they seek new footholds in industry sectors, opportunities to showcase
Chapter 19 • Creating and Evolving a Technology Roadmap
emerging technologies, and ways to gain entry into new markets. Many times, this is
accomplished by partnering with willing organizations in R&D initiatives. As a result,
organizations should be leveraging their vendor communities aggressively. One focus
group member had only used a portion of her R&D budget because a key vendor had
provided all the technology and most of the support free of charge.
Focus group members shared a number of different approaches to R&D, but all
shared a common challenge: capital funding. At some companies R&D flies “below
the radar” as “skunkworks.” Here the IT department uses its own money that it has
squirreled away over time, treating R&D similar to a cost of doing business. In others,
R&D is financed by a technology investment fund (i.e., a tax to the business levied as
a percentage of technology usage). This fund is governed by a committee composed
of senior managers who guide the investment in R&D. In another firm, IT maintenance is reduced by 10 to 15 percent per year, and the dollars are reallocated to strategic IT investments, much of which are funneled to a “technology adoption program”
described as a “sandbox where new technologies are tried, improved, tested, scaled,
and assessed for business value.” These latter approaches are preferable because they
don’t attempt to hide R&D. In fact, they make R&D transparent to the organization.
Business leaders understand the need for reinvestment in the physical plant; IT is
no different.
Activity #5: Describe Future Technology
This part of the IT roadmap should contain a description of the technologies to be
adopted in the future. These future technology roadmaps should not be simple lists.
They should also include the logic that was used in the decision to follow a certain
path. If, for instance, the technology roadmap depicts a preferred vendor strategy,
equally if not more important is the reasoning that underpins this strategy. Making this
explicit within the roadmap permits others to challenge the logic without challenging
the decision. This is essential, particularly if you wish to obtain constructive input from
business managers when creating your technology roadmap.
Equally important are the assumptions built into the roadmap. IT professionals
are frequently guilty of assuming that it is obvious to others why a certain strategy
has been adopted. Hence, there is value in making all embedded assumptions explicit.
These assumptions may reflect trends in the competitive marketplace (e.g., vendor
A will continue to dominate with its software offerings), the general environment
(e.g., the adoption of open standards will accelerate), specific technologies, or general
trends (e.g., new development will increasingly adopt Agile practices). This exposure
provides the basis for meaningful conversation to help clarify the roadmap’s dependence on widely accepted (but perhaps not articulated) assumptions.
The group felt that describing the technology was fairly straightforward, using
major technology domains such as hardware, software, applications, and networks.
The difficulty often is in regard to the granularity of future technology. The question is,
how do you decide the level of detail in future technology platforms? According to one
manager, “If your roadmap is severely impacted by business change, your roadmap
is probably too granular.” The opposite, creating a technology roadmap that is too
high level, is equally inadequate. The goal is to find the “sweet spot” between the two
extremes, which is “more art than science,” he said.
291
292
Section IV • IT Portfolio Development and Management
Activity #6: Outline Migration Strategy
A technology roadmap should also outline a migration strategy to get you from today’s
technology platforms to tomorrow’s. At first glance, the implementation of a technology roadmap appears similar to the accomplishment of other major IT initiatives. The
focus group, however, was quick to point out the differences. Of these, the primary one
is that a technology roadmap is not a self-contained project; it affects every project as
technologies are embedded within the entire spectrum of applications, many of which
cross lines of business, geography, and generations. By positioning each technology
domain on a life cycle (e.g., watch, invest, support, eliminate), two dominant migration
strategies emerge—“gradual” and “big bang.”
The gradual strategy focuses on the application (i.e., as new applications are
implemented or reworked, their technology is updated to fall in line with the dictates
of the roadmap). The big bang strategy emphasizes the technology (i.e., all instances of
a given technology are updated across all applications). The choice is not an either–or
situation, nor is it a “technology only” decision. Rather the choice should be dictated
by the business. There are few situations where the big bang approach is absolutely
necessary simply because there are always means of staging the conversion over time,
applications, business lines, and/or platforms. As one participant noted, “Even large
architectural builds/deployments are typically done within a program across several
phases.” Sometimes, though, the big bang is a business necessity due to the need to reap
advantages in a reduced timeframe.
A major challenge facing the migration strategy is the need to assign priorities to
the various technology components that need to be changed. One organization uses
the following criteria to assess the criticality of migration in order to assign order of
execution:
•
•
•
•
•
Technology elements that are inflexible
Elements that do not meet the strategic direction
Components that are expensive to maintain
Components that do not meet nonfunctional requirements (e.g., scalability,
extensibility)
Architectural designs built to reflect obsolete business strategies (e.g., segmentation
silos, line-of-business silos).
Once priorities are assigned, timelines can be established for the migration of
various technologies.
A migration strategy should explicitly recognize a number of dominant trends
within technology, such as the movement toward cloud-based services and big data.
Although such trends provide useful high-level guidance, they need to be augmented
by more tactical guidelines (see Appendix A). Of particular interest here is the need
for a migration strategy to explicitly plan for the migration of people skills in alignment
with the future technology demands.
Activity #7: Establish Governance
Every organization should have an established process in place to articulate who is
responsible for creating the technology roadmap, how and on what basis, by whom
it is updated and enhanced, and finally who approves the technology roadmap. Most
Chapter 19 • Creating and Evolving a Technology Roadmap
organizations in the group felt that the technology roadmap was legitimately the
responsibility of the enterprise architecture function, which is responsible for mapping
out the architectural platforms to support the various lines of business. The majority
of companies recognized the need for two distinct levels of architecture governance
within their organizations:
•
•
Strategic. Individuals and groups at this le …
Purchase answer to see full
attachment
How it works
- Paste your instructions in the instructions box. You can also attach an instructions file
- Select the writer category, deadline, education level and review the instructions
- Make a payment for the order to be assignment to a writer
- Download the paper after the writer uploads it
Will the writer plagiarize my essay?
You will get a plagiarism-free paper and you can get an originality report upon request.
Is this service safe?
All the personal information is confidential and we have 100% safe payment methods. We also guarantee good grades