The main force behind today's digital world is software. Software is at the heart of everything, from smartphone apps and web applications to the sophisticated systems that run our daily lives. However, have you ever wondered how software is set up, arranged, and created to satisfy the various demands of consumers and companies? That's where Software Architecture comes into play. This article will dive into software architecture, explain why it's important, how the role is integrated at Blip and how it affects the software development in our company.
What role does architecture play in software development?
Software architecture is a high-level structure that outlines how software components interact to meet specific requirements. It serves as the architectural plan for a software system, defining its components, data flow, and interactions. A well-designed architecture makes code easier to understand, alter, and address problems. It allows for scalability, reliability, reusability, and collaboration among team members. Choosing the right architecture is critical for project success, as different projects require different architectures. It also ensures quality, addresses performance, security, and user experience, and aids in technical debt management.
Software architecture is made of choices and decisions. There will never be a perfect architecture for every circumstance, so some compromises will always be necessary. Software architecture is about making well-informed decisions over trade-offs, and most cases is more about avoid costly future decisions (from missing something) rather than getting everything right straightaway.
How is the Software Architect role integrated at Blip/Flutter?
Architects lead the process of developing technical architecture and vision for its technological progress, working closely with the Product, Commercial, and Technology teams. They create straightforward answers to complicated business issues while ensuring specific system characteristics, for example, availability, performance, scalability and others. They discuss and advise stakeholders on roadmap features on a continuous basis, as well as lead and implement architectural design best practices.
Architects give technical mentoring and support for architectural solution design to further grow ongoing projects. For each stage of a project, there must be at least one lead architect per functional area and there are, frequently, other supporting architects.
Starting with the validation phase and progressing until the project is completed and delivered in production, the architectural team is present at almost every stage of the project to keep track of progress and to assist development teams in resolving issues as quickly as possible.
At Blip/Flutter, we do not work in a waterfall model where everything is decided upfront - there is always room for refining specific details over the delivered solutions along the way, depending on the project phase and the criticality of those decisions. E.g., choosing to build a new component is crucial to determine beforehand, but small API details such as field names might be decided only on build phase.
Project Iteractions
- Identify: Brand stakeholders and product managers review product concepts. Architects can support this project phase by giving a high-level complexity estimate to help prioritise between two important projects, and by creating technical Lean Canvas to get sponsorship to build or improve a system.
- Validate: Stakeholders approve the project for a deeper solution and cost analysis during the project phase. A working group with product teams is created and requirements are defined with stakeholders. Architects then work together with product teams through the product requirements until they reach a technical solution that respects all the requirements, but also keeps or improves the overall system architecture. The output is an architecture document that can be easily understood by the product teams that agree with the proposed solution and the technical teams that will work on it.
- Plan: Project phase in which stakeholders accept the effort estimation for the project based on predicted commercial value. During this phase, delivery teams are assigned, and specific estimates and a delivery plan are expected to be presented. Project dependencies, delivery risks, and priorities have been established. During this phase, product and architecture representatives assist teams and engineering managers.
- Build: Phase of a project or initiative in which delivery teams have been given permission to build. During this phase, architecture representatives assist teams and engineering managers, for unblocking decisions, clarifying solution approach, and ensuring that what is being built aligns with what was conceptualised.
Architecture team main goals
- Close the gap between business and technology teams by identifying synergies and technical approaches that allow the business to evolve.
- Identify internal and external dependencies and mitigate potential delivery implications.
- Ensure cross-divisional alignment in global products, such as gbp, so they can grow into a genuinely world-class sports betting platform that will enable the Flutter Group to innovate and distinguish the experience we can provide to our clients across our various brands.
- Work closely with teams to assist them in collectively selecting the best solutions for situations at hand.
- Bring architecture closer to teams while also giving them a say in strategic direction.
- Assist in reaching the best possible outcomes for the teams.
- Mentoring developers to help them grow professionally.
Concepts and patterns that empower our software development
Choosing the proper architectural pattern for our projects is a critical decision that will affect the development, maintenance, and scalability of applications. When making this selection, we consider the size, complexity, scalability needs, and team skills of each project. There is no one-size-fits-all approach, and the key to success is selecting the design pattern that caters to different project’s needs and goals. Having this in mind, we will now explore some of the architectural patterns that are part of our architects’ daily basis.
Event-Driven Design and Domain-Driven Design
Event-Driven Design (EDD) and Domain-Driven Design (DDD) are architectural techniques used in software development. EDD is an architectural pattern which deals with the flow of data, transmitted in the form of events among loosely coupled services on distributed systems. DDD is an approach to deal with the modelling the problem domain and can be used with event-driven architectures. EDD focuses on handling events, allowing components to communicate through producing and reacting to them. It is suitable for real-time, asynchronous systems with loose coupling, enabling efficient division of work among components. It is also beneficial for systems with complex workflows or processes. DDD emphasises the need to know and model a software system's problem domain. It promotes collaboration between domain experts and developers to achieve a common understanding, leading to a well-structured, domain-centric design. DDD is particularly beneficial for complex, business-critical domains where a thorough understanding is required. It also encourages a clean and maintainable codebase by aligning the software's structure with the issue domain.
Event Sourcing
Event Sourcing is an architectural pattern that determines a system's state based on a sequence of events, preserving an audit record of every change in a system. It involves event generation, storage, and reconstruction. Events are generated whenever a change occurs, ensuring a complete audit trail. Event Sourcing challenges standard data storage and retrieval methods, offering a complete history record, fault tolerance, and temporal querying capabilities. It is a popular choice for data-centric systems in software development.
Distributed Systems
Distributed systems are collections of independent computers or nodes that work together to form a single coherent system. They can span multiple locations, networks, and platforms. Key principles include concurrency, communication, fault tolerance, and scalability. These systems provide benefits like scalability, robustness, and performance but also present complexity that must be managed. As technology advances, distributed systems will play a larger role in the software architectural environment, influencing future application creation and scaling.
Command Query Responsibility Segregation (CQRS)
CQRS is a software design pattern that separates the duties of reading and writing data. It involves a command stack for writing operations, and a query stack for read operations. Asynchronous communication ensures consistency and separates write and read operations. Some CQRS implementations use event sourcing for replayability. CQRS can increase efficiency, scalability, and flexibility, but requires careful analysis of application requirements.
Microservices
Microservices is an architectural paradigm that divides an application into loosely connected, independently deployable services. These microservices offer scalability, fault isolation, rapid development and deployment, and flexibility in technology. They enable horizontal scalability, allowing individual services to handle variable loads. Microservices also encourage innovation and experimentation by adopting the most appropriate technologies for individual needs. However, deploying microservices requires careful design and understanding of related issues.
Final conclusions
Software architecture is more than just code and databases; it is about designing systems that effectively model real-world scenarios. Software architecture is the backbone of any successful corporate software development project. It is the blueprint that outlines how different components of a software system interact and collaborate.
A software architect's role is crucial in ensuring that this design aligns with the company's goals, meets user expectations, and is long-lasting. A well-designed architecture can lead to faster development cycles, improved system maintainability, scalability, and market flexibility. A poorly thought-out design, on the other hand, may lead to inefficiencies, technological debt, and project delays. It is the difference between building a tower on solid ground and shifting sands. Recognising the importance of software architecture and investing in competent architects is thus not merely a best practice but a strategic must for any firm aiming to thrive in the digital era. So, the next time you interact with software, keep in mind that a well-designed architecture is enabling it all.
Are you a Software Architect interested in learning more about how we do it at Blip? We have the perfect opportunity waiting for you. Join us!
Soraia Gonçalves
