Services > Projects
We propose to apply the the well-known Prepare-Plan-Design-Implement-Operate life cycle model. It delivers a suitable approach in most cases.
Strategy
Goals
The goal of the cloud or data center strategy is to align the business strategy and IT strategy of your organization. A strategy should deliver a set of actionable recommendations that are necessary to reach the target state. A strategy must, in case where conflicting statements exist, eliminate those and provide clarity. It also should consider and leverage existing investments where-ever it makes sense.
Methodology
The cloud strategy for your organization will be organized into strategy themes. Each strategy theme consists of a theme definition, viewpoints, and position statements. Every position statement is established through reasons, impact, and – if needed – a trade-off analysis, dependencies, and risks.
The strategy themes and associated drivers of your organization are defined as a joined effort between your stakeholders and our consultants. An already existing business strategy or IT strategy, applicable regulations or standards, a series of interviews and workshops provide the foundation. After carefully considering the known aspects, positions are manifested.
Interaction through workshops and knowledge transfers create a solid foundation for the successful completion of this service.
Architecture
The cloud solution for your organization is functionally described in the target architecture. We propose defining and using building blocks to describe the solution. Each building block represents a specific functional or physical area in the infrastructure. Building blocks are described through their capabilities and how they interact with each other.
Goals
The aim of an architecture is to breaking down the complexity that is normally found in monolithic constructions. By partitioning the structure, a modular solution is promoted. Focusing on functional aspects leads to solutions that are not driven through technology.
Methodology
The creation of the target architecture for your organization is structured into two major phases. The acquisition and management of input parameters and target architecture creation.
Interaction through workshops and knowledge transfers create a solid foundation for the successful completion of this service.
Acquisition and Management of Input Parameters
We propose to consider various input parameters which drive the development of your organizations target architecture. Analysis of existing documents and interviews provide the vehicles for acquiring the data. We propose to examine the following drivers.
- Strategies and existing workstreams
- Existing decisions
- Requirements
- Applicable existing regulations
- Architecture Principles
Target Architecture Creation
For most data center infrastructure architectures it is sufficient to consider the engineering viewpoint. In case of cloud architectures, the operational viewpoint should also be considered. The enterprise and technology viewpoint are further candidates for consideration.
We propose that your organizations representatives and our consultants run a series of workshops in which consensus on the desired building structure and scope is created. It provides the basic structure for describing the target architecture.
During the creation of the target architecture, the following aspects find consideration:
- Definition of a common vocabulary
- Functional description of the building blocks
- Building building blocks interaction
- Architectural decision and reasons
- Describe how architectural decision support requirements or other input parameters
- Discuss recommended standards
- Compliant and suitable products may be discussed if desired
The target cloud architecture document provides the basis for the design phase to follow.
Design
The design describes the architecture in further detail by focusing on non-functional aspects. Physical and logical topologies explain the solution. The design describes which technologies are chosen and how they get applied.
Goals
The goal of this phase is to describe the problem (requirements) to be solved and to provide a check list against which the solution can be bench-marked. The goal of the design is to deliver a description of the solution from a technology perspective. Last but not least, decisions must be articulated and must be comprehensible.
It provides the basis for the implementation phase.
Methodology
Two phases are anticipated to complete this phase of the project. The acquisition of requirements and the definition of the design.>
Acquisition and Management of Requirements
Requirements for the design are acquired through multiple sources and processes.
First of all, strategies and architectures provide guidelines and decision that are translated into the requirements for the design phase. Existing requirements documents should be leveraged. In case where those are missing, interviews should be conducted by our consultants in which we capture and document your requirements.
In case where the target solution replaces an existing environment, requirements can be derived from it. Analyzing topologies and configurations are vehicles to reverse engineer requirements.
Requirements must be captured and documented. They provide the basis for design and technology decisions.
Design Creation
Design decisions are jointly reached between the representatives of your organization and our consultants. Design decisions and reasons are documented and are aligned with requirements.
Suitable technologies are selected, discarded technology candidates are briefly described and reason is provided for the decision.
Physical and logical topologies are key in describing the solution. They are created at various level of abstraction. Topologies are complemented by connectivity matrices.
Vendors and products are determined. Suitable product features and their characteristics are selected. The design describes those.
To support availability, manageability, and security of the solution, we will describe and leverage best practices.
The design will contain configuration templates.
Domains
We propose that the structure follows the one that has been chosen in the architecture. The structure is completed by
- Physical design aspects including connectivity matrices
- Logical design aspects including connectivity matrices
- Best Practices
Implementation
Goals
Implementation planning provides the detailed instructions for the actual deployment. Must must be diligent in the planning to avoid any interrupts in the implementation. The implementation plan should be organized such that a validation provides significant information for the deployment in production.
Methodology
Our DevOps approach allows to flexibly reacting to adjustments, provides the assurance that the staging results are representative for production, provides robust results, and last but least, is time effective. Three ingredients are leveraged during the implementation planning. Those are automation, configuration, and parametrization.
We leverage open-source tools for automation, such Python and Ansible. The Robot framework can be applied for testing.
Configuration templates are used as defined in the design phase.
Parameterization is based on the data that has been generated during the design phase. In includes physical connectivity and logical connectivity aspects, including IP addressing, indexing for various purposes, and configuration of features.
Migration
Migration strategy and migration planning support the transformation from the today’s infrastructure (your future legacy) into your new network or cloud solution. We leverage a DevOps approach for the migration where-ever possible.
Goals
The migrations strategy and migration planning should provide the detailed steps to execute the migration. The migration planning must focus on reducing the number of migration windows and reducing the overall downtime. Another goal is recovery, that is rolling back to a predefined state in case of problems during migration.
Methodology
Our philosophy is to approach complex migrations by creating a migration strategy first, followed by detailled migration planning.
Migration Strategy
The migration strategy contains a description of the status of network at the beginning of the migration. This initial state is described by a series of topology diagrams and a series of relevant attributes. A data base is created and stocked with configuration items that are existing in the network. The data base is populated through custom open-source software, the Current State Analysis.
Based on the initial state, the project team (the representatives of your organization and our consultants) define the high-level migration steps that are necessary to reach the target state. The purpose of the migration strategy is to describe the migration verbally and graphically. It allows to discuss the approach and verify feasibility.
Migration Planning
The migration planning provides the next (and final level) of migration preparation. Yet again, a DevOps approach is taken advantage of. The benefits which have been discussed in the implementation planning, do also apply to the DevOps-based migration approach: Adjusts to changes flexibly and allows to validate the approach and procedures. While timely execution is a nice-to-have capability during implementation, it becomes an essential ingredient in migrations.
Open-source tools – Python and Ansible – are used for automation. The starting point for the migration is described in the data base that represents the results of the aforementioned current state analysis. The benefit of this approach is obvious: We can flexibly react to operational changes that may occur in the network prior to the migration. Taret state configuration templates are used as defined in the design phase.
Parameterization is based on the data that has been generated during the design phase. In includes physical connectivity and logical connectivity aspects, including IP addressing, indexing for various purposes, and configuration of features.
