The Guide to Practical and Pragmatic IT Architecture Design

How to Build IT Architecture

Now we have designed the IT architecture, it is time to start building and constructing the platform solution. There are three main areas that need to be addressed:
  • Development capabilities, tooling and environments
  • Development processes
  • Development Standards and Guidance

Development capabilities, tooling and environments

For the development capabilities, tooling and environments, the basic steps are:
  1. Procure the required infrastructure, that may be physical servers or cloud infrastructure premises, 
  2. Procure the licenses for the required software, operating system, database,  virtualization, and other products including tools for development and operations 
  3. Prepare the development and testing environments with the infrastructure and software. If certain libraries are required, ensure that those are installed as well.
  4. Prepare the development toolings for version, CMDB, build, test, deploy  and release management. Ensure that there is a backup process in place in case the software version management platform gets corrupt.
  5. Configure user accounts so that developers have their own area to develop, administrators have proper rights to maintain the environments and toolings etc.
  6. Start development on laptops and PCs and ensure that the developers are submitting their code versions to the SW version repository.
  7. Let the developers perform unit testing their development units before submitting it to test phase to ensure code has been verified before.
  8. Use security development tooling to ensure vulnerabilities are filtered and taken out of the code.
People need to be trained and able to have their own development area and PC. Remote connection to work from outside the office could be a necessity, so that needs to be facilitated. The development could either be through programming or configuration of the product software. 

Development Processes

Another area that needs to be looked at are the IT processes during development. How do developers submit their code? How and when do we merge branches of various code streams? Who manages the code tree and who and how do we decide when and where to deploy. These processes need to be lined out with clear activities and responsibilities. 

Software Version Management

The most important IT areas and processes during development are:
  • Source Code Version Control 
  • Continuous Integration
  • Continuous Deployment
  • Package Source, Allocation and Provisioning
  • Test Strategy
  • Code Quality and Unit Test
  • Test Automation
  • Test Data Management
  • Operations & Monitoring
  • Change Management
Each area needs to go in depth how to address the specifics with:
  1. tools - if required -, 
  2. process and 
  3. role(s). 
An example is source code version control that for instance needs 1) a repository to store the software versions, requires 2) a strategy and process to manage branching, integration and merging of various versions and a role of 3) an administrator who configures and manages this process.  
Software Version Management

Development Standards and Guidance

Development standards and guidance also need to be provided to ensure development is consistent and salable. Standards provide rules and guidance how to reduce software complexity, improve consistency and quality and facilitates easier hand-over to other teams such as mainteance. For instance, usage of consistent naming standards and code commenting helps facilitating later modification by other developers who are unknown to the original code. 

The most important standards and guidance to be considered during software build are:
  1. Software and Architecture Principles & Guidance
  2. Object Naming Standards
  3. Programming Standards
  4. Integration Development Standards
  5. Security Standards 
  6. Methodology Documentation Standards
  7. Etc.

These standards can be re-used and in most cases are available within the company or can be created when required first time for further use. Other standards need to be more strategic such as data model naming conventions as to change that later is more difficult. 

Once defined, these standards need to be made centrally available and published to ensure the development teams are aware of them. This can be with a repository or knowledge base available in the company or an easy file folder. 

No comments: