Principles

As a group we want a set of guidelines/principles for enterprise architecture so that we can implement a solution that would benefit all our affiliates and stakeholders going forward.
Some of the guidelines/principles we have identified are :

Cloud First
- As a group we want to design and develop applications that will be hosted in the cloud before considering on-prem.

Event Driven Microservices
- Adoption of events as a source for any action in a system rather than polling or scheduling batch driven updates.

Loosely Coupled Architecture
- Each microservice should not have any tight dependency on another. Adoption of an event driven message brokering system would be a good solution.

Linux Containers
- As a group we will adopt using containers to deploy any microservice. This allows us to be operating system agnostic and programming language agnostic.

No Vendor Lock In
- Using the Linux container approach we can deploy on any infrastructure and not be locked in to any specific vendor.

Cloud Service Provider Agnostic
- As stated above we can make use of any cloud service provider we choose.

Usage of Container Orchestrators
- By making extensive use of containers, we will utilize industry standard container orchestrators (kubernetes, openshift) , ensuring high availability and scaling. This also allows us to be cloud provider agnostic.

Adoption of CICD
- To be competitive in today's markets we need to adopt and implement continuous integration , continuous deployment and continuous delivery in all our product lines.

Benefits of Event Driven Microservice Architecture
- Scalability
- Availability
- Resiliency
- Independent, autonomous
- Decentralized governance
- Failure isolation
- Auto-Provisioning
- Continuous delivery through DevOps

Architecture (ref Accelerate Gene Kim et al)
"We have seen that adopting continuous delivery practices improved delivery performance, impacts culture and reduces burnout and deployment pain, however the architecture of your software and services depends on and can be a significant barrier increasing both the tempo and stability of release process and the systems delivered. Furthermore devops and continuous delivery originated in web-based systems, so it's legitimate to ask if they can be applied to mainframe systems firmware or to any average big ball of mud enterprise environment consisting of thousands of tightly coupled systems. We set out to discover the impact of architectural decisions and constraints on delivery performance, and what makes effective architecture."

The importance of focusing on architectural characteristics, rather than the implementation details of your architecture is key. It's possible to achieve these characteristics even with package software and legacy mainframe systems. Conversely employing the latest microservice architecture deployed on containers is no guarantee of high-performance if you ignore these characteristics.

As mentioned before given that software delivery performance impacts organisational performance its important to invest in your capabilities to create an evolve the core, strategic software products and services that provide a key differentiator for your business. The fact that low performers where more likely to be using - or integrating against custom software developed by another company underlines the importance of bringing this capability in house

Focus on deployability and testability
High performers reported that :
- We can do most of our testing without requiring an integrated invironment
- We can and do deploy or release our application independently of applications/services it depends on

It appears that these characteristics of architectural decisions , namely testability and deployability are important in creating high performance.
Outcomes from from 2017 analysis

- Make large scale changes to the design of your system without the permission of somebody else outside the team.
- Make large scale changes to the design of the system without depending on other teams to make changes in their systems or creating significant work for other teams.
- Complete your work without communicating and coordinating with people outside the team.
- Deploy and release your product or service on demand regardless of other services it depends upon.
- Do most of the testing "On Demand" without requiring an integrated test environment.
- Perform deploymens during normal business hours with negligible downtime.

In teams which scored highly on architecture capabilities little communication is required between delivery teams to get work done and the Architecture of the system is designed to enable teams to test deploy and change the systems without dependencies on other teams, in other words architecture teams are loosely coupled, to enable this we must ensure delivery teams are cross-functional with all the skills necessary to design, develop, test, deploy and operate assistance on the same team.

- A loosely coupled architecture enables scaling
- Allow teams to choose their own tools
- Architects should focus on engineers and outcomes not tools or technologies

Technical Practices (ref Accelerate Gene Kim et al)
- Continuous Delivery
- Continuous delivery is a set of capabilities that enables us to get changes of all kinds of features configuration changes, bug fixes, experiments into production or into the hands of users safely quickly and sustainably, there are five key principles at the heart of continuous delivery.

- Build quality In
- Work in small batches
- Computers perform repetitive tasks people solve problems
- Relentlessly pursue continuous improvement
- Everyone is responsible

In order to implement continuous delivery we must create the following foundations :
- Comprehensive configuration management
- Continuous integration
- Continuous testing
The impact of continuous delivery
In the few iterations of a research from 2014 - 2016 we modelled and measured a number of capabilities, the use of version control for application code, system configuration, application configuration, build and configuration scripts, the following is a list of our findings

Comprehensive test automation that is a reliable easy to fix and runs regularly
- Deployment automation
- Continuous integration
- Shifting left on security
- Using trunk based development as opposed to long-lived feature branches
- Effective test data management