To allow digital products to flourish we must provide a strong architectural foundation that supports high product quality, cost effective and time effective delivery and operational simplicity.
Application architecture seeks to build a bridge between business requirements and technical requirements by understanding use cases, and then finding ways to implement those use cases in the software. Good architecture reduces the business risks associated with building a technical solution. A good design is sufficiently flexible to be able to handle the natural drift that will occur over time in hardware and software technology, as well as in user scenarios and requirements.
Modern tools and platforms help to simplify the task of building applications, but they do not replace the need to design your application carefully, based on your specific scenarios and requirements. The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment.
Common architectural styles:
- Layered Architecture: Partitions the concerns of the application into stacked groups (layers).
- Component-Based Architecture: Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.
- Microservices: Refers to applications that expose and consume functionality as a service using contracts and messages. An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.
- Domain Driven Design: A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
- Object-Oriented Design: A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.
The following are the main benefits of the component-based architectural style:
- Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.
- Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.
- Ease of development. Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.
- Reusable. The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.
- Mitigation of technical complexity. Components mitigate complexity through the use of a component container and its services. Example component services include component activation, lifetime management, method queuing, eventing, and transactions.
As multiple variants of the same application are created, software becomes more sophisticated and increasingly expensive to customize, maintain, and extend. A platform with a well defined architecture can turn the tide of rising costs and risks.
Our platforms should offer, and our products make use of, a well-defined reusable set of API exposed capabilities, SDK and UX components, micro-products, toolset frameworks and management controls. This will drive down the time and cost of delivery whilst driving up quality and operational efficiency, releasing resource and funding for product innovation.
There are several reasons why we should consider investing in code reusability:
-
Quicker time to market: The more reusable assets that a team has at its disposal then the less the team will have to build, thereby enabling them to release quicker.
-
Improved return on investment (ROI): Reuse engineering enables IT delivery teams to avoid building something that your organization already has. This leads to greater ROI for your IT investment which in turn leads to greater value being delivered to your stakeholders.
-
Improved consistency: When all of your systems use the same implementation of a service, or component, or function, or framework then that functionality by definition is implemented consistently across those systems. This makes them more predictable and easier to understand.
-
Easier updates to common functionality: When functionality is implemented in one place and then reused where needed it is very easy to update that functionality and then deploy the updated version.
Having a wide variation in technical implementation and a fractured experience in operational process increases complexity in delivery, fragility in product and architecture and cost in operation. We need to start addressing this through best practice development, integration patterns and toolset developments in order to simplify our workflow.
Global products and platforms should support internationalisation and localisation of function, content and data to allow the fast rollout of existing products and content across multiple territories on a global basis. This will allow us to evolve, grow and operate our online products in a proactive, cost effective and sustainable way.
Our products and platforms should provide rich data insight into the cost of delivering specific product functionality. This will support identification of components that are high cost drivers (candidates for optimisation) and the identification of high cost product functionality (candidates for change or deprecation when measured against audience value).