Technology
Last updated
Was this helpful?
Last updated
Was this helpful?
Large-scale services in society allow people to do things like order food or donate blood. But in the world of technology, services can also be discreet pieces of functionality, like a print service that connects to your printer or a or a messenger service that connects you with other users.
When we talk about technical design, we refer to the planning of technologies and infrastructure to support a large-scale service delivery.
In a way, designing a service is like building a house. Architects plan the design of the house before the builders start creating it to make sure the house will be safe and the foundations secure before any bricks are laid.
Similarly, our solutions and technical architects plan the technology and infrastructure we need in place to support the designs before developers start creating a product. The architects review high-level requirements during discovery and help formulate potential solutions during the alpha phase. The chosen approach will be refined and detailed during the beta to create the proposed design.
We focus on making the systems secure, extendable, scalable and available. And as part of that, we may capture business processes in Business Process Model and Notation (BPMN) or Universal Modelling Language (UML) and specify the necessary architecture components, like what services are required and how they communicate with each other. We also ensure they're easily extendable once live to support future enhancements and changing business conditions.
Security is built into everything we do. Following the National Cyber Security Centre guidance, our products are secure by design. So what we’re creating, and who we’re creating it for, will dictate how secure it has to be. We might be designing a public website with predominantly open information. Or we might be designing a private police programme with sensitive data, including personally identifiable information like medical records or sentence plans.
We’re experienced at working with extremely sensitive data. We assess how private the information is and then plan the security around it. We consider what bad actors might want to access the data and how to prevent that from happening. Our security approach is based around the universal principle of least privilege access. So someone can only access the data if this is required by their needs, role or function.
The technical architect creates all relevant diagrams and documentation to show how and when data would be accessed in an application based on the requirements to help define the technical security controls. The diagrams inform what can happen to the data at every stage, by whom, and when. We answer questions like is it read-only or can it be edited. No matter the level of data access, we always create an audit trail to track it. The architects design authentication processes to confirm a user is who they claim to be and that they’re authorised to access the platform. All of these elements give our clients the confidence that we can protect their data.
For a modern system architecture, services need to be able to scale. We design platforms based on the expected number of concurrent users and their usage frequency. Our Service Level Agreements (SLAs) are commitments to our clients regarding response times (how quickly the application reacts). For example, if we’re expecting 100 users on a Tuesday evening but 5,000 users try to access the system, it could negatively impact performance. So we need to be able to increase availability as needed and in real-time.
We build cloud-native, highly available applications. For some applications with a fixed number of users, our designs are tailored to support those numbers in a cost-effective manner. But for public facing applications that have a varying number of users, we design it to work with dynamic demand. This means that when more users are active on our platforms, we can quickly scale up the capacity to maintain the expected performance levels. And then during quiet periods, we can scale it back down again, reducing costs.
The technical architect designs the system to support this, planning how and what compute resources (like virtual machines or serverless resource) and storage is required for the platform.
Availability goes hand in hand with scalability. It’s about always being available and accessible. We design our systems to work, even in the face of failures as our services are fault tolerant. Availability is preparing for things to go wrong so the user can never tell.
The technical architect designs the infrastructure to span multiple service instances to protect the application. And we build in disaster recovery plans from the outset so we can adapt to any challenges that come our way.
Even with the most secure and reliable solutions, things can still go wrong. Sometimes, environmental or external issues occur that are out of anyone's control. That’s why we plan ahead for those situations. We always back up key data, whether it’s related to people or systems. It allows us to restore lost or corrupted data within minutes of the last entry. This way, no one loses a day’s worth of work. We’ve plan and test a wide range of disaster scenarios, from a single service failure to a complete hosting platform outage, and adjust our designs to restart or even rebuild from scratch if needed.
