QSI, Inc.

System Engineering / Architecture

Quality Solutions Consulting (QSI) has proven capabilities to support engineering, system engineering, and process engineering support processes. Our experienced staff realizes in order to have a successful design that they must understand the current architectural design.  The four processes that make up our approach to understanding and making sound recommendations are 1) Analyze Technical Architecture, 2) Design Technical Architecture, 3) Build Technical Architecture, and 4) Test Technical Architecture.  

During analyze technical architecture phase, QSI’s consultants will:

·             Gather the technical requirements

·             Review the current technical architectures

·             Identify gaps between the current technical capability and the “to be” (future state) capability

·             Map the business requirements with the application components and then define the required technical architecture. 

As part of this process, we identify the architecture gaps so that we recommend solutions to closing those gaps and define the system landscape.  Our staff develops:

·         A high-level view of the existing system landscape

·         The instance strategy

·         Change management strategy

·         Identify all components of the existing system landscape such as the target infrastructure scenario (central and decentralize server infrastructure)

·         System environments (Development, Test, Production, etc.)

·         Clients

·         Transport paths

·         Security needs (access to the solution or to the data)

·         High-level development and customization guidelines

·         Specify the scope, names, and number of legacy systems that the new system must interact with or be integrated to

·         Review the system landscape specification with key stakeholders and project management

·         Address the security needs concerning users’ accesses to the development environment

·         Define a roadmap for development environments set-up, and identify the global geographical strategy of the landscape. 

In conjunction with defining the landscape strategy, we define the number of logical environments required according to project organization such as Sandbox, Development, Test, Integration, Quality, Acceptance, Security, Training, Pre-Production, Production, Maintenance, etc… We also identify system landscape components based on the targeted application blueprint and the identified system products and components to be included in the landscape.  We create a client strategy detailing landscape diagram showing client, transport route, and possible refresh plan. Our staff will explain each instance with description, objectives, characteristics (open for customizing, test system, etc.).  The strategy will be clear if it is based on production copy or not and who’s responsible. 

As a function of the client strategy, we explain / define the transport management system.  The transport management system (TMS) provides insight into what should be transportable by the TMS or ALE or any other automated way such as conversions or automated scripting tools.  QSI prefers the TMS approach for distributing customizations and development objects from the development environment through the whole landscape up to the production environment. In addition, manual transports or system copies might be required as well.  We explain in details to the client about transport path.  Transport path defines transport domain/domains and routes across the landscape.  All change migration between the systems in the landscape will be done through transports.   In order to handle transports correctly and to facilitate a proper release management, a transport management solution is required such as change request form or a spreadsheet solution. 

QSI consultants will assist with developing transport governance using industry best practices. The creation and release of transport requests must be properly controlled and the contents of each transport request tracked. Transport requests that are not associated to a business change or do not comply with the naming conventions must not be released from the development system.  Lastly during this phase our staff will created a release management strategy that distinguishes between planned and non-planned releases and as a result can cater to both major and minor solution changes as well as local and global changes.  We will define the criteria for release migration into the production environment.

The next phase is design technical architecture. During this phase, QSI’s Consultants will:

·         Set-up project infrastructure,

·         Environments and tools,

·         Design the technical architecture to meet the technical,

·         Security,

·         Performance requirements. 

We also create the component and assembly test plan. 

During build technical architecture phase, QSI’s Consultants will:

·         Maintain project infrastructure, environments, and tools

·         Set up production infrastructure and environments

·         Build and component test the technical architecture components and services

·         Transition the technical architecture components and services to the test team. 

The last phase is test technical architecture. In this phase, QSI’s Consultants will:

·         Maintain production infrastructure and environments;

·         Conduct the assembly test to ensure technical components work correctly;

·         Conduct the product test to ensure the overall technical architecture meets all the functional requirements;

·         Conduct the performance test to ensure the technical architecture meets all performance-related metrics, such as response time, availability, and load/throughput.

Lastly, we ensure the new technical architecture integrates properly with the existing (legacy) overall architecture.