07908 859 818


JGilmartin - Technical Architect leading your Development Team

What are the benefits of having an architect leading your team?

As your Architect I will guarantee your software is well designed ensuring the code conforms to SOLID principles, is loosely coupled and follows tried and tested design patterns. This will make the code testable and simple to extend in the future. I will analyse your business requirements and make recommendations both from past experience and current research for the most suitable technologies and frameworks. I will setup a DevOps process that features not only automated deployments but Source Control branching structures, Continuous integration, build servers and a code review process for all code that is checked in or merged. I will recommend from experience the best way for your Development team to successfully work with your product team using Azure DevOps to create Features, User Stores, Tasks and Bugs that are linked to check-ins and branch merges. I will design, propose and implement your live infrastructure, detailing the best Cloud services most suitable for the project. I will also design and implement your Test/UAT environments so at any point you can view the latest build.

Failure to follow these conventions at the early stages will result in low of developer productivity, performance issues, complex deployments and ever-growing technical debt which will far exceed the initial cost of me joining the team as the architect.

Why it makes sense to invest in an Architect

Lets view in detail my roles and responsibilities working as your architect

I will first analyse your current codebase to understand its structure and design methodology. The questions I will be asking are…
Do you have Coding Standards Documentation
If not, I would write a document for your business that specifies my recommend code conventions, how the solution needs to be structured and overall “dos and don’ts” to ensure high code quality.
Is there Unit tests and if so, can they be run in isolation?
We want to be able to run all unit tests in isolation. This is so we can add a Continuous Integration step on the build server to run all unit tests and have them successfully pass before any code in the current branch is deployed. To do this we must decouple all tests from dependencies such as the database.
I would initially recommend to implement a Mocking framework such as Moq.
Further refactoring may be needed if the code is not sufficiently segregated by interfaces.
Are you using Dependency Injection and IoC?
I would recommend using Unity for IoC which will in turn make the code cleaner and easier to test in isolation. Let’s ensure all dependencies are passed as interfaces to our constructors and that each Class follows the same pattern and code structure. This will minimise technical debt while making it easier for new Developers to quickly add value.
Are you following SOLID design principles?
Ensures all code follows the same structure and design patterns. This means it’s simple for developers to understand the code throughout the application.
Reduces technical debt as the codebase can easily be contributed by current and future developers
Code can be easily tested in isolation without DB dependency
Is the application Monolithic? Can we separate functionality into services?
Do we have parts of the application that would benefit being abstracted into a service?
For new Developments I would recommend a microservices architectural approach that groups functionality into independent WebAPI services.
Remove single point of failure
Each service is independently scalable.
Each service is designed in the exact same way so it’s easy for developers to work on different areas of the application.
Do you have a Database Design Convention?
Implement schemas to group tables, views and stored procs by functionality.
Ensure all tables feature created and amended timestamps, Primary, Foreign Keys and indexes.
A poor database design is a key area of technical debt.
How are we ensuring the Database schema and data remains constant?
I would recommend adding Database Projects so that on deployments, pre and post SQL scripts are executed automatically which keeps the data and schema consistent between SQL Server Environments.
This removes the need for manual patch scripts which are very manual, Error Prone and Introduce Risk
How are we documenting requirements from the business and translating them to User Stories and Tasks for the Developers?
I would demonstrate the benefits of Azure DevOps and the convention of Epics, Features User Stories, Tasks and Bugs.
Are we doing code reviews on check-ins?
By not doing code reviews it will increase the likelihood of mistakes and the risk of introducing new bugs.
It ensures code consistency is maintained
What is the process Developers follow when assigned a task?
I would recommend the following process. Once a developer completes the code for an assigned task, it is tested locally and then checked in. QA will test on the UAT Environment and sign off the task. The task is only complete when the developer merges the code from UAT to the Production branch. At this stage it is ready for the next scheduled deployment.
Are you following Agile and Sprint based project management?
Allow me to demonstrate Azure DevOps as the tool for managing Agile Development. I can introduce you to Agile methodologies such as daily stand-ups, sprint planning and sprint retrospective sessions.
User stories describing the problem – “as a user I need to be able…” which are accompanied by specific tasks and bugs.
Introduce Epics and features for long term project strategies.
What are your test environments?
I recommend implementing 5 different environments (local, DEV, UAT, PROD and Live)
Do we have CI Builds and automated deployments to test environments?
Each test Environment (DEV, UAT, PROD) has its own dedicated environment that will auto deploy once code has been merged to its respective branch.
What is the status of the Source Code Repositories, branches and permissions?
I recommend a branch per environment with an enforced check-in and merging policy that requires a code review.
How are we managing environment specific configuration and settings?
I would recommend implementing build configuration transforms which will transform settings such as connection strings and App Settings per environment.

When working as an Architect for a client, I recommend the following process for test environments and code branching structures. Code is only merged through to each branch once it’s been tested and signed off. It consists of 5 environments (including Local and Live) with continuous integration setup on the Development, UAT and Production environments. For each of these 3 environments on the hour, every hour a new automated deployment is triggered which includes both code and databases. This ensures that at the very most the codebase and databases are just 1 hour out-of-date.
Developer access to the environments is restricted. This ensures no configuration, files or Database Schema/Data can be modified which is different from the environments respective branch. Any changes would be overwritten on the next deployment so it enforces developers to make changes in the solution rather than try and rely on server/database/environment hacks.



DB Naming Convention

Continuous Integration?

Developer Access Level

Local Local development instance on dev machine LOCAL_##DBName## N/A Full
Development Dedicated Environment – first developer check-in branch DEV_##DBName## Yes Read Only – No access to servers
UAT Dedicated Environment – Once code in the dev branch has been tested, it is then merged to the UAT branch ready for the QA team to view/test UAT_##DBName## Yes Read Only – No access to servers
Production Dedicated Environment. UAT check-ins that have been signed off by QA are merged to the Production branch. PROD_##DBName## Yes Read Only – No access to servers
Live Abstracted Environment fully isolated from developers. Developers may not even have an overview of this environment.
Code deployed exclusively from the Production branch
LIVE_##DBName## Live Deployments manually trigged or set on a schedule Zero Access

The key goal will be to ensure we have continuous delivery and automated deployments.
As your architect I will implement a Continuous Delivery process that will consist of separate source code branches one for each environment. Each time code is checked-in to the repository or code is merged to another branch it will trigger a build and if successful a deployment to the test environment. This ensures the business has full visibility of the current build and progress of the application.

As your Architect I will develop a one click, fully automated deployment process to the live environment so your business can feel confident that deployments can be triggered on demand, are reliable and with significantly reduced risks. This is often far more complex than the test environment deployment process as typically the live environment is comprised of several load balanced servers and cloud resources such as Databases, Web Servers, Distributed Caching/CDNs and Enterprise Search. If the Application is following a microservices architecture the live environment will consist of many pairs of Geo-replicated App Services and SQL Databases.

Reliable Automated Deployments. On Demand and with Zero Downtime
When working with a microservices solution hosted in Azure using AppServices, I achieve zero downtime by using Deployment Slots. These are identical instances of your Primary AppService where your application is deployed to. You can either switch to your primary AppService as part of a successful automated deployment or for additional sanity, view your application first and trigger the switch manually. Deployment slots have proved valuable as the switch is instant and incurs zero downtime.

  • Implement a code design for Developers to follow to ensure all code conforms to SOLID Principles
  • Ensures all code follows the same structure and design patterns. This means it’s simple for developers to understand the code throughout the application.
  • Reduces technical debt as the codebase can easily be contributed by current and future developers
  • Code can be easily tested in isolation without DB dependency
  • Produces a system design that groups functionality into independent WebAPI services.
  • Remove single point of failure
  • You can scale each service independently.
  • Each service is designed in the exact same way so its easy for developers to work on different areas of the application.
  • Present the benefits, options and costs.
  • Design and propose the cloud architecture, emphasising PaaS and SaaS services
  • Identify OnPrem bottlenecks and “low hanging fruit” to gradually migrate to the cloud.
  • Propose Cloud solutions that would benefit the business such as Enterprise CDN’s, Application Gateways, Load Balancers. PaaS Services, ect
  • Analyse and report the cost of the proposed cloud infrastructure.
  • Inspire the team with regular technical workshops and lectures.
  • Train existing and recruit new developers.
  • Ensure all developers are happy and resolve issues within the team.
  • Keep the team happy and engaged.
I worked with Motorpoint as a Software Architect for a number of years delivering business critical .net applications

I worked with Pinewood as a Technical Architect Microservice based and Sitecore Powered web applications