IT Architecture: Development Layer

Application development follows a methodology that facilitates the different phases of the development lifecycle. The lifecycle can be based on waterfall or agile  methodology and typically has a number of stages during development:

• Analysis, to understand the requirements the application,
• Design, where the application platform and solution are drawn up,
• Build, where development and application programming or configuration is done,
• Test, to test whether the application works according to the functional and technical specs 
• User acceptance, to ensure that the application complies with the final end users´ needs
• Deploy, putting the application go-live into production

These stages are depicted in the famous V-model of development that shows several aspects:

1. Shows the timeline of the different development lifecycle stages going from left to right,
2. Shows the involvement starting with the business going down to IT and then coming back up to the business to do final acceptance,
3. Shows that each stage of analysis, design and detailed design are verified in corresponding test phases.

 

If you flatten the V-model, you can distinguish the various development stages we have described earlier:

 

The development capacity of the model shows all capacities that are required to facilitate development and addresses 3 main capabilities:

 

Version and Configuration Management

The most important development feature required is version and environment configuration management between the different development stages. Software version management is a repository that basically maintains different versions of the software and more advanced systems can merge different programs into a single version. Configuration management looks at the configuration of the software platform and environment based on the version used. The configuration items such as parameters, tuning, memory and buffer allocation, operating system and hardware specifics are stored in a configuration management database, also called a CMDB. It ensures that the different test and production environments are properly configured and can be back traced in case of errors. 

Continous Integration and Deployment  

Once a specific software feature has been developed, the latest version can be integrated with other modules, deployed to testing and production environments.  And once the application is running in production, development turns into maintenance and typically less capacity is required. The ability to maintain different versions of the software is important to ensure to understand the history of development and for maintenance purposes that the solution can be rolled back to an earlier version if there are certain software bugs. If this process is automated for all test stages , it is called continuous integration. 

Continuous integration differs from continuous delivery and continuous deployment, as delivery is the overall process to facilitate automated builds from development through testing and acceptance. Typically before final deployment, there is a manual approval step to ensure the software is approved and complies with internal and external regulations. Continuous deployment is the overall end-to-end automated build process from development to production. 

 

Development Environments

Multiple environments are needed to facilitate the development lifecycle. For small applications, one can start with a development, a test and production environment, but that limits parallel testing. For instance, testing data conversion and testing programming logic are different parts of the application and can be tested independently and if you have only one environment, you must rebuild, redeploy and clean the testing environment for each different test purpose. 

This is impractical for larger applications, and typically we see the following development and test environments: 

• Sandbox environment, this is optional and is used to prototype certain functionalities or try out features. This is a parttime and very small environment.
• Development environment, where the application is being built. This can also be on the developers’ PCs or laptops and then centralized into one development environment. This is a small environment.
• Basic test environment, where application and its features are tested after development team has finished their development. This is typically a small environment.
• Integration test environment, this is the environment where application integration is verified. This is integration with legacy, third party or other applications and could be services, micro services, APIs, batch or data interfaces. This is typically a small environment.
• Conversion test environment, this is an optional environment that is needed when data has to be migrated or converted from other (old) applications to the new application. This is typically a small environment, but has large diskspace, CPU and memory as data conversion is data volume, memory and processor intensive.
• User Acceptance test environment, is required to ensure users can test the application in a clean final environment to ensure the application can be signed off to deploy to production
• Technical acceptance test environment, this is optional but for larger applications mandatory to test performance, disaster and failover scenarios. This environment is typically a mirror of full production environment with similar CPU´s, memory and diskspace
• Cut-over testing, optional environment to do the cut-over procedure testing where the sequence of cutover steps to deploy the application to production and prepare it to go-live including data conversions, is practiced and tested to go-live. This is typically a smaller environment.
• Training environment, optional and not shown below, but is required if training and classes are given to large groups of employees. This is a smaller environment.
• Production environment, this is obviously the final production environment where the application runs 
• Maintenance environment, not shown below, but is required if the application continues to be developed for a subsequent release and the current application needs to be maintained and fixed and tested. This is a smaller environment.

Testing Environment Sizing

Sizing is very important for these environments as it impacts performance as well as cost. The table below shows typical initial sizing of environments based on production sizing. So, for instance if you have 4 servers + 4 failover servers (including application, web and database servers) in production, then a development environment would have 1/8 of this capacity, that results in just 1 server that is shared by the application, web and database. Obviously, dependent on the application and during the development and testing, the environments need to be tuned to ensure they match its final purpose.

Environment	Initial Sizing
Sandbox	1/16
Development	1/8
Test	1/8
Integration Test	1/8
Conversion Test	1/8, but with sufficient CPU and diskspace when processing conversion due to intensive data processing requirement
UAT	1/8
Tech Acceptance Test	1
Cut-over Test	1/8
Training	1/8, dependent on concurrent training sessions and users
Production	1
Maintenance	1/8