Concurrent Dev Policies

Concurrent Dev Policies – The Best Practices Of Integrating Applications

May 30, 2023

Introduction

Concurrent Dev policies provides general guidance to ASIs (Application Software Integrators) regarding the development and integration of software systems for the Customer (Enterprise) Platform. It presents policies and recommended approaches for creating applications that work with the Middleware (MW) components of the Platform.

Additionally, this blog assumes you have a template that can be used to create interface design documentation (Will write a separate blog on this!). ASIs are encouraged to adhere to the naming conventions provided in this document while developing MW applications.

By adhering to the practices and processes for concurrent dev policies outlined in this document, ASIs can also reduce the time required to onboard new developers, make efficient use of existing services by reusing them, and promote consistent interaction among different ASIs.

ASIs should consider this document as a point of reference for their concurrent dev policies.

Customer Platform

The Platform consists of managed hosting services and other shared services utilized across multiple projects and/or business solutions that are deployed on the Platform. The customer or an enterprise integrator is not only responsible for providing these shared services, but also includes an independent System Integrator / Multi-Vendor Integration (SI/MVI) team that is responsible for supporting ASIs and implementing proper governance and processes for development on the Platform.

The following areas are normally designated as shared services provided as part of the Platform for which we are discussing the concurrent dev policies. You may add more the following list.

Middleware
Security
Analytics
Portal
Content Management

Generally the architecture is broken into four distinct parts. They are 1. Presentation Layer 2. Data Layer 3. Application Layer and 4. Middleware Layer.

Types of documents to be maintained by ASI for concurrent dev policies include the following:

Onboarding Guide

Develop and document standardized processes for onboarding new ASI team members. This is the responsibility of the ASI supervisor. The SI/MVI team administrators will provide the necessary support in addition to an handbook for how to appropriately work with the Enterprise Systems Integrator (ESI).

Design Documents

The ASI must maintain the following types of documents for any new application or project implemented by the ASI.
- Logical Architecture: A system architecture diagram displaying all the logical components. Interface Design: A document detailing specifications for new services or interfaces exposed to other ASIs.
- Integration Flows: A document displaying all the integration flows developed for the new applications and projects.

Standards Documents

Develop and maintain coding standard documents that detail practices to be followed by ASI developers. These standards should also include any policies or standards from the customer for any shared service areas that may be relevant to the work being performed by the ASI.

Design Policies

The following must be used as a guide and you can add to it for concurrent development policies

ASIs should review the current customer Enterprise Platform architecture. The SI/MVI enterprise architect/technical lead (EA/TL) is responsible for maintaining relevant, Platform-related documentation.
Testing environments may contain masked personally identifiable information (PII) data. During the design phase, the ASI should identify any PII data to be masked for the new application or project.
The ASI must consider high availability (HA) when designing the architecture for the new application or project.

The proposed design must be compatible with the established disaster recovery (DR) process, which also has to follow the published standards of the concurrent development policies.

Solution Architecture Principles

The proposed solution should follow guiding architectural principles developed by customer.

Modular Design: Architectural design should follow a modular approach. This includes breaking down the solution into as small modules as possible which provide a single functionality with minimal inter-dependency.
Service-Oriented: The architecture should consist of a number of services that are compliant with industry standards for SOA to facilitate reuse, adaptability, and interoperability.
Distributed Architecture: Modules must be able to run on distributed resources and ability to communicate with each other.
Reusability: Design the modules for reuse. Modules are designed and deployed in a manner that enables them to be invoked by disparate systems.
High Availability: The solution architecture must be designed to ensure high availability.

Integration and Testing

The ASI will be responsible for testing and maintaining valid integrations for all components of the overall system architecture at all times.
The ASI will be responsible for code migration.
The ASI is responsible for identifying test data and providing scripts to create/migrate data.
The customer/integrator team will be responsible for executing the migration scripts for test data and other Platform-related configurations required for testing.
The customer/integrator team will coordinate testing activities with other ASIs and external partners and agencies.
Additional details on integration and the code migration path are provided in Section 5 Code Migration.

ASIs must follow continuous integration practices. ASIs are free to use the integration tools of their choosing; however, the ESI recommends using the tools in the following table.

Code Migration Policies

The ASI needs to produce a Systems Integration document that provides the customer with the information required for the integration of the associated application or project. This information should include: integration flows, connections to external systems and agencies, test data set requirements and other details as applicable. These documents are to be uploaded to the applicable Shared project site with permissions granted to the customer for accessibility.
Before promoting code to the next environment, the ASI needs to provide the customer with a Testing Summary document that includes the methodology and a task list of what was tested and how. This document must be attached to the service request in ServiceNow, requesting promotion.
Environment backups should be taken before code promotion. The ASI can request backups by submitting a service request. Please note that databases should be backed up on a recurring basis for all non-production environments, except for UATxx (exceptions). If an ASI needs regular backups of infrastructure components (e.g., software binaries, filesystems, log files, etc.) for any other non-production environment, the ASI needs to submit a service request ticket with details on the backup, restore requirements, and timeline. All infrastructure components for non-production environments—example (UATxx and UATyy) —are backed up on a regular basis.
Testing environments contain masked personal identification data. It is the ASI’s responsibility to identify the personal data to be masked for the new application or project developed by the ASI.
The ASI needs to provide the customer with instructions on how to mask the personal data (identified in the previous bullet). The ASI can request data masking by submitting a service request ticket. The instructions for masking should be attached to the service request.
For disaster recovery, the customer/integrator team will be responsible for migration and sync-up of databases and file systems. It is the ASI’s responsibility to migrate and sync application specific configurations.

In conclusion these are some of the guidelines you can use as a reference for Concurrent Dev policies that are adopted by your internal team and also your application software integrators. This will ensure a standardized and predictable output following desired standards.