How do you use architectural styles to improve system development?

Software can be developed in various ways, just like one can get from origin to destination via multiple routes. Just like we use maps to identify the optimal route for our journey, we use architecture styles to decide how the software system will be developed. Architecture styles define a high level approach / strategy which can be used to develop a robust software system. These are time tested, well defined & understood patterns and principles of software architecture describing a high level solution at software system level, while being technology agnostic. They also provide a common language for communication. Choosing the wrong architectural style can prove costly hence it is often done by the experienced EAs / SAs on the team.

In my experience architecture styles are patterns that architects from across different industry sectors agree on, so that they applicability is very broadly understood (e.g. modularization, event-based integration,…). To select those high-level architecture styles for an organization is an important task for enterprise architects as those decisions shall represent the ?north star“ for a big audience of system architects and solution teams within the organization.

System development is the process of creating, designing, testing, and deploying SYSTEMS to meet specific requirements and goals. There is nothing "software" specific about development of systems. It applies to hardware, software, socio-technical, and all other types of systems which are architected.

it is insteresting topic, based on my Architect experience, every organization follows certain standards based on the Technology roadmap and Vision. so fundamentally, our architecture will use that has a baseline for any application architecture or new solution for new usecase. the design and architecture decision will align as per this baseline. Therefore, the architecture style always closely aligned with this. Many scenario, i had to chose the design strategy based on organization technology roadmap. However, Due to the technology advancement and new capabilities introduced in Cloud service provider brings the challanges to the roadmap finalization because Business and application wanted to adapt the new services/capabilities

In my view, architectural styles are the key decisive factors in any application design which helps the product achieve streamlined performance even when the requirements get more complex. Its similar to the design patterns, but it is predominantly gathered through experience where to use Queue-based system and where to use Event-driven system. Thats where the EAs play a major role when designing complex systems.

Architectural styles gained more importance in the recent days as the computing used for the new systems are getting more tricky and complex in nature. Also in the modern world, everything is expected to be processed in real-time and without following appropriate architecture style, this can not be achieved.

Architectures are key to make solutions usable, maintainable, testable, scalable, among so many others, but what it makes key an architecture is to be able to express an idea in a simple and concise way. When the same pattern gets repeated, a team of developers can embrace the solution, making easier applying the same piece of code over and over. Let's put as an example a micro-service architecture. In the past we trusted on monolithic solutions, now we can build smaller pieces to compose bigger systems, following, most of the times, specific patterns.

We discuss some of the things you itemize here as guiding principles. The idea being that we have patterns and standards at a detailed level but guiding principles are things like "buy over build" or data should be "open but secured". These NFRs should be addressed in terms of the patterns and guiding principles and technology standards that you have published. Always strive towards removing ambiguity for the system engineers.

Architectural styles are important because they: Ensure Consistency: Establish standardized design patterns for a consistent system structure. Promote Modularity: Facilitate the organization of complex systems into manageable components. Enable Scalability: Support system growth and adaptability to changing demands. Encourage Reusability: Allow for the reuse of components and design patterns. Simplify Maintenance: Facilitate easier issue identification and updates. Enhance Security: Enable separation of concerns and implementation of security measures. Optimize Performance: Provide a foundation for performance optimization. Future-Proof Systems: Reduce the risk of architectural obsolescence.

The choice of architectural style also needs to factor in the overall enterprise environment in which the system will be ultimately deployed, as well as any integration requirements it may have with existing systems, data sources or legacy apps that also reside within that enterprise environment. If the cost and effort of incorporating the new system within an enterprise architecture is alleviated by choosing a more compatible architectural style, then that is one consideration that can be taken into account in addition to the immediate functional and processing requirements of the new system itself. One further related consideration is the extent to which the new system may need to be upgraded, extended or otherwise evolved over time.

In my experience the drive has to be considered at org level. A governance body (EAs) driving guiding principles across all of the moving parts within an enterprise which has to be adopted culturally and diligently by everyone involved in the program has to the first step. Anything without this would work in silos within an org and holistically would fail to present a unified architectural style. In my experience I have seen this in action and without a cultural shift and acceptance any pattern or style used would be inappropriate. Best example is API design first strategy which in my mind has to be adopted culturally first without going into design or finalising the patterns and styles as these would follow as by product of the shift.

Any choice in an enterprise context always comes with trade offs so too the different architecture styles that help teams build enterprise application. Conways law fits well here that architecture are often a representation of the organisation structures. One perspective is that, Any architecture style being chosen should focus on how multiple teams will collaborate frictionless as much as possible to help build systems faster that eventually help the business realise value in the marketplace.

There is never a single right answer. If you ask five architects which style to take there will be five answers. Focus the decision on the absolute key tradeoffs, which include: 1. Business impact (go deep and use data) 2. Cost/TCO 3. All the "ilities" - extensibility, scalability, maintainability, etc. Rank these against one another 4. Non-functional requirements Explainability is important so make sure the documentation on the choice is thorough.

There is no specific defined path of architectural style to be followed for specific problem statement. The type of problem/ requirement defines the style to be selected. It is based on multiple factors - e.g. Applications which are talking to each other, Protocols between them (as in whether db connectivity, restAPI etc), data availability requirement, underlying hardware capability and performance requirements.

Here are some common architectural styles in software development: Client-Server Architecture: Divides the system into clients and servers; clients request services, servers provide them. Layered Architecture (n-tier): Organizes the system into layers (e.g., presentation, business logic, data) to separate concerns and enhance modularity. Microservices Architecture: Decomposes the system into small, independent services, allowing flexible deployment and scaling. Event-Driven Architecture (EDA): Components communicate through events, triggering actions upon event occurrence. Component-Based Architecture: Utilizes reusable, self-contained software components for easier assembly.

Architectural styles are frameworks for designing and organizing systems. Examples include: 1. **Client-Server**: Splits into clients (requesters) and servers (providers) for efficiency. 2. **Peer-to-Peer**: Shares tasks among peers, enabling decentralization. 3. **Pipe and Filter**: Chains processing steps via pipes for sequential data processing. 4. **Event-Driven**: Focuses on events triggering responsive, asynchronous actions. 5. **Microservices**: Breaks into independent services, ensuring scalability and agility. 6. **Monolithic**: Builds a tightly integrated single unit, suitable for smaller apps. 7. **Data-Centric**: Prioritizes data organization, crucial in data-heavy apps.

To apply an architectural style: 1. Understand the style. 2. Identify components. 3. Define responsibilities. 4. Establish communication. 5. Design interfaces. 6. Implement logic. 7. Ensure separation of concerns. 8. Address cross-cutting concerns. 9. Follow style-specific rules. 10. Test interactions. 11. Optimize performance. 12. Document architecture. 13. Enforce consistency. 14. Iterate and adapt. 15. Plan for future evolution. 16. Validate periodically.

I agree that this is the process good architects shall follow. In my experience it can be helpful to have a business analyst who gathered all those information about context, constraints, requirements, characteristic and the business process to support with the system. This information can be modelled as Archimate model for clarity in the motivation layer and business layer. This model acts as a single source of through about what shall be built and can be iterated on together with the business stakeholders and business analyst. When the model contains the finalised business view of what shall be built, the architect can then start modeling the application layer below in archimate to define components, interfaces and integration pattern.

As described above data-centric etc I'm not sure how often we get into those types of conversations directly. I think we live more at the "you should isolate vendor APIs" and what is critical is that the style or pattern that you promote has a practical implementation path/tooling. People need to be really clear on what they should use in your enterprise for an "Event Driven" approach for example. Or else you'll get a proliferation of tools and approaches and code which sort of takes away some of the value of using a style.

Dans une équipe qui grossit, il est pour moi important d'adopter le bon découpage du système d'information pour préserver l'efficacité. Bien souvent, cela se traduit pour moi par une approche SOA pour rendre les différentes équipes les plus autonomes sur des transversalités métier spécifiques et limiter leurs adhérences. Pour ce faire, je m'inspire beaucoup de l'approche Microservice en essayant de garder un nombre de services cohérent (pas plus de 2 ou 3 maximum par équipe). Il ne faut pas oublier que le style d'architecture doit rester au service de la performance des équipes et non les contraindre.

In the end, it is important to consider that as technology, customer experiences and computing models are evolving, so will the architecture styles. Continuous governance is important to ensure that enterprise adoption remains relevant.