`Products:
Professional Knowledge Transfer—IT Consulting
Information Technology (IT) Infrastructure Learning:
IT Consulting—Instructed by Consultants with Real-World Empirical Experiences
Learn to discuss cloud & cybersecurity initiative alignment with IT business goals and objectives
Business-information
technology alignment, the "holy grail" of organizations, integrates
the information technology (IT) to the strategy, mission, and goals
of the organization.
Business-IT alignment involves optimizing communication
between executives who make the business decisions and IT managers
who oversee the technical operations.
Learn the Unwritten Rules of Consulting
Presentations | White board Sessions
Beware of Silent Saboteurs
Share Your Knowledge
Observing others’ behavior - how not to behave
The client’s unwritten ruless
A psychologist named
Noel Burch created a learning model
to describe
how humans go through four stages of learning when introduced to a
new skill. This model is known as “The Four Stages of Competence”.
Competence Hierarchy adapted from Noel Burch by Igor Kokcharov” – Own work. Licensed under CC BY-SA 4.0 via Commons
The keys to successful cloud application migration:
Define a Cloud Reference
Architecture
Before an
application migration, the cloud requirements must be holistically
addressed within context of business and operational needs,
applications, platforms, and infrastructure. Cloud architectural
decisions should be made in context of how each layer of the
technology stack—infrastructure, platforms, and applications—is
impacted by a cloud deployment.
The cloud service delivery models (SaaS, PaaS, and IaaS) roughly map to the applications, operating systems and IT infrastructure of the traditional data center. Another way to look at cloud migrations is to use the SaaS, PaaS and IaaS layers as the model for the migration initiative. The project can then be segmented to take advantage of each layer’s strengths.
Application Migration—Decisions
roughly fall into the following categories:
Migrate the current application portfolio
into the cloud with minimal modification for the purpose of driving
infrastructure
Refactor applications into a private cloud
framework to optimize application scalability, portability, and
integration capabilities.
Refactor applications to incorporate shared
business and technical services in a private cloud framework to
leverage common services.
Refactor applications to incorporate shared
business and technical services in an industry specific community
cloud.
Learn Cloud Rules | Principles
Cloud principles and rules are a set of
specific reference guidelines that the applications are evaluated
against for their cloud fitness. They also help determine the
migration re-factoring effort. Cloud rules are specific code
parameters needed to effectively satisfy the requirements of the
cloud principles. The following are some sample cloud principles:
Security Framework
ESB and Integration Services
Middleware / Messaging
Transaction Management
Business Continuity / Disaster Recovery
Cloud File Access
Monitoring and Management (Logging)
Regulatory and Compliance
Vulnerability Assessment
Testing and Deployment
Other factors such as Native Interfaces, RMI,
Library Version Control, etc.
Perform an Application Portfolio
Analysis
The cloud principles developed in the above step determines which applications can be migrated to the cloud. Several additional selection criteria must be considered to obtain a comprehensive snapshot of the current “as-is” architectural state.
Information
gathered from this analysis helps make a data-based business case
for the migration initiative. The selection criteria fall into
business, technical, and project categories:
Business Criteria
The primary criteria are the strategic business elements
affecting the application and the underlying business processes and
functions which they support. Business questions to ask include:
What is essential to the business and what is
not?
How can this initiative be used to drive
innovation?
Is the application creating and sustaining
competitive advantage?
Is the system cost-efficient?
What is the business value?
Technical Criteria
Several
categories of technical criteria also need to be considered. The
following list is by no means exhaustive but serves to highlight the
many dimensions involved and the technical complexity of the
analysis needed to intelligently select the appropriate
applications:
Hardware
Does the
application use specialized hardware, dedicated chipsets, or
firmware?
Does the application use or depend on any specialized network
hardware, appliances, and/or proprietary protocols?
Architecture
How well does the
application adhere to Service Oriented Architecture principles?
Have service catalogues been created and implemented?
What development
frameworks, programming languages, technologies, and platforms does
the application depend on?
Does the target cloud platform support all or some of these
environments?
Business domain
Is the
application transactional (OLTP) or analytics oriented (OLAP)? How
well are these components separated in the architecture?
Governance and Operations
Are there special
security requirements that will influence the migration decision?
How will compliance and certification requirements be satisfied in
the target cloud?
Complexity
How large is the
application code set? What are the data set sizes?
What type of data is used – structured, unstructured,
semi-structured or mixed?
Is the data or application geographically distributed?
What is the application usage pattern and volume? Number and type of
users?
Availability | Reliability | Latency | Performance
Does the
application need to be clustered for high availability or
reliability?
Does it have strict latency and/or performance requirements?
Several
categories of technical criteria also need to be considered. The
following list is by no means exhaustive but serves to highlight the
many dimensions involved and the technical complexity of the
analysis needed to intelligently select the appropriate
applications:
How well are the
existing architecture, code, and interface points documented?
Are there other
stakeholders (outside organizations and/or other departments within
the company) who have technical skills to contribute or management
authority to influence the migration project?
Experience and Skills
How much technical and operational
experience does the migration team have with the selected
application?
1. Unconscious Incompetence
The individual does not understand or know how to do something and
does not necessarily recognize the deficit. They may deny the
usefulness of the skill. The individual must recognize their own
incompetence, and the value of the new skill, before moving on to
the next stage. The length of time an individual spends in this
stage depends on the strength of the stimulus to learn.
2. Conscious Incompetence
Though the individual does not understand or know how to do
something, he or she does recognize the deficit, as well as the
value of a new skill in addressing the deficit. The making of
mistakes can be integral to the learning process at this stage.
3. Conscious Competence
The individual understands or knows how to do something. However,
demonstrating the skill or knowledge requires concentration. It may
be broken down into steps, and there is heavy conscious involvement
in executing the new skill.
4. Unconscious Competence
The individual has had so much practice with a skill that it has
become “second nature” and can be performed easily. As a result, the
skill can be performed while executing another task. The individual
may be able to teach it to others, depending upon how and when it
was learned.
Applying this model to the Cloud 
This model has many parallels to how large organizations adapt
to cloud computing. The following stages of cloud adoption are not
based on scientific analysis or modeling, but rather how typically
organizations mature as they progress through the learning curve.
Stage 1 – Cloud Denial
At the unconscious incompetence stage, the lack of knowledge of the
underlying technology, organizational impact, and potential business
value causes organizations to deny the usefulness of cloud
computing.
Some call it resistance to change, but it is really a lack of
understanding of the core value proposition.
Organizations in this stage dispute the benefits of cloud and use
things like security, compliance, and outages as justification for
continuing to run IT with a legacy data center mentality.
Stage 2 – Do-It-Yourself (DIY) Cloud
At the conscious incompetence stage, many either see tangible value
in the cloud or have a mandate from the C-suite to go cloud.
However, these organizations don’t necessarily trust cloud
providers, especially public cloud vendors, and they continue to
apply their legacy data center thinking to the cloud architectures
that they build.
They also still want to be in control because they think that the
cloud is only safe if they build it themselves. A lot of blood,
sweat, tears, and money is shed over the next year or two but the
business value is rarely achieved at the levels that were
anticipated.
These organizations are turning their companies into infrastructure
companies, instead of turning them into software companies.
Stage 3 – Cloud Transformation
Those at the conscious competence stage have a year or two of hands
on experience with the cloud and a solid understanding of IaaS. At
this point, most organizations realize the DIY model is complex and
time consuming. Now that those driving the change understand the
underlying technologies, the organizational impacts, and the
potential business value, they often start looking for ways to
accelerate their cloud adoption programs.
This is where companies who previously said “we will never go to the
public cloud” change their mindset to “tell me what I can’t run
in the public cloud.”
These same companies also understand that they must transform the
way they build software and start looking to DevOps as a way to
become more agile in the cloud. In this stage, cloud adoption is
intentional and rapid.
Executives start applying very strategic plans to transform their
company to become modern suppliers of IT services and bring in cloud
computing experts to help accelerate the change.
Stage 4 – “All in” the Cloud
At the unconscious competence stage, building solutions in the cloud
becomes natural. These companies transformed the way software is
built and delivered and have created great value for their business.
In some cases they may have even enabled new business models and are
now looking for ways to accelerate bringing value to the business.
At this point, these organizations are “all in” the cloud.
They also start embracing PaaS, whether that is from a pure play
PaaS provider or higher level services from the IaaS providers or
both.
These organizations understand that there is little to no business
value in infrastructure and the application stacks.
Step 5: Manage the Migration Program
A structured migration effort is designed to produce predictable
business outcomes. Experience has shown that these outcomes cross
operational, tactical and strategic boundaries.
The project must be managed to high quality standards to shorten
development cycles and minimize project expense.
Key factors for a successful migration program include:
Detailed work breakdown requirements from profiling analysis
Organizational Change Management
Use the program to facilitate organizational transformation across
business, development and support functions
Education
and enhanced support programs
The value received from cloud computing is derived from delivering
on business requirements that drive more revenue, creating higher
level of services for customers, and getting to market before their
competitors.