Embracing Agile Practices(Part-3): The Architectural Agility
In the previous two articles,
Disclaimer:
Whether consciously or unconsciously, we often adopt various methods to simplify our tasks and enhance business processes. There is no one-size-fits-all approach, as what works for one organization may not suit another. The key is to innovate and customize existing industry standards to meet our specific needs. Ultimately, the primary focus should always be on delivering high-quality products or features to the right customers at the right time. To facilitate meaningful discussions about business matters and processes within our industry and across organizations, it’s essential to have a common understanding of the terms and terminologies we use. Let’s continue to strive for excellence in our agile practices and drive positive outcomes in the world of enterprise architecture.
we explored the challenges posed by traditional architecture development methods and the potential of the Architecture Development Sprint (ADS) to address these issues effectively. We delved into the intricacies of the ADS process and witnessed its ability to foster innovation, collaboration, and alignment with business objectives. Now, in this third part of our series, we embark on a journey to explore the concept of architectural agility and its vital role in driving successful enterprise initiatives.
Architectural agility is a strategic approach that empowers organizations to adapt and respond swiftly to ever-changing business landscapes and customer demands. In the modern world, where disruptions are commonplace, the ability to build and maintain an agile architecture has become a decisive factor for staying competitive and ensuring sustainable growth.
Throughout this article, we will uncover the key considerations that make an architecture truly agile and conducive to rapid value delivery. From embracing lean principles to leveraging cutting-edge technology enablers, we will explore the essential components that empower enterprises to build nimble, future-proof solutions.
Today in any modern enterprise software instantiates and enables business processes, services, products, and many forms of business capabilities. Hence, in most cases, we can say business agility is a function of the agility of the software organization, and the pace at which the organization is able to deploy and make available production-ready software to a business and its customers.
The key architecture guidance that the team received after the architecture development sprint should support evolvability, high resilience to failure, and the ability for architecture to support a lean, agile, and continuous delivery operating model.
There are two basic principles that guided his overall approach to architecture development in an organization.
- Transforming the architecture development process in order to adopt agility, speed, and innovation into the process of developing architecture.
- Streamlining the architecture itself so that it offers the least resistance to the evolution of the architecture, and basically creating an architecture that actively enables continuous delivery of valuable business software.
The most important enabler that sustained agility from a longer-term perspective is the architecture itself, and the technology components that enable the architecture.
So let’s take a look at what these are.
Transforming Legacy Architecture
This architecture should be referred to as a transition state architecture because it represents an intermediate stable state that the architecture would transition through in the process of transforming into the envisioned final target state architecture.
I have explained the same approach here in detail:
https://medium.com/@dilankam/how-i-migrate-monolith-giant-to-microservices-23831300c221
As you can see the new solution depicted here does not fully replace the old monolith system, but rather coexists with the old then how the team employed the strangler pattern in this case.
The strangler pattern is an architecture pattern typically applied while transforming legacy systems in small, bite-sized increments. This effectively de-risked the transformation and enabled the teams to transform incrementally and learn as they iterated through architecture development sprints.
The strangler pattern involved leveraging an interface, or a service layer, between the consumers of the legacy system and the legacy system itself to intercept events that are directed at the system. It also involves creating the new application in small increments that replaces a small percentage of functionality in the whole system. This then enables running the increment of the new application live, together with the existing legacy application. The interface, or service layers, are configured to root the events to the new application for the small percentage of functionality that the increment replaces. The legacy application functionality may still be retained to serve as a fallback mechanism for a period of time. With each iteration, the process is rinsed and repeated for newer and newer increments until the new application completely replaces the old. In the present case he said, the checks processing functionality is a legacy functionality, which was being replaced by the new applications architecture.
Microservices Architecture
According to the ADS outcomes, The architecture should support evolvability, high resilience to failure, and the ability for architecture to support a lean, agile, and continuous delivery operating model.
Microservices architecture is a choice that the team should be naturally attracted to as it seemed like a good fit given these objectives. But, there are several pieces to the microservices architecture puzzle, so first up let’s look at it at a conceptual level and do a quick round-up of the key pieces of the puzzle.
- 🧩The first piece of the puzzle, of course, is the microservices themselves, which are small, autonomous, and decoupled suites of services. Overall the architectural objectives here are to ensure that the services are small enough and that they represent a single responsibility. We also ensure that the services can be independently modified and deployed without impacting each other.
- 🧩The second piece of the puzzle that when the team discovers the importance of enabling the continuous delivery of microservices.
- 🧩Containers technology represents the smallest possible environment, with all required features packed into it that enable an application to run.
- 🧩Each microservice can have its own independent deployment pipeline thereby enabling unprecedented flexibility for each component part of the architecture, to change without impacting the other. Essentially, the duo of containers and microservices represents the possibility of building fully composable enterprise applications.
- 🧩Containers do require a few additional tooling to help make this kind of flexibility more practical. Container registries, said Gary, can be thought of as a central repository of container images.
- 🧩Container orchestration platforms also enable quickly and easily scaling up and scaling down service instances, thereby allowing you to scale a specific service or a group of services. Although the architecture enables many new capabilities, it also introduces many new complexities that are not seen in a typical monolithic application.
- 🧩This architecture depends on a scaffolding of tools and capabilities to essentially manage the complexity it introduces.
Realizing the Architecture
In the realization phase of the Architecture Development Sprint (ADS), the team can embrace a microservices architecture style characterized by independently deployable services. Each microservice operated within its own container, following the principles of the 12-Factor App, which provided guidance for service development.
The architecture will be promoted autonomy and flexibility, with services To maintain independence among services, the team can adopt an event-driven choreography facilitated by a message broker or event platform, a style known as Event Driven Architecture. This approach, inspired by the Reactive Manifesto, enabled highly evolvable, elastically scalable, and message-driven architectures.
The microservices predominantly employed a publish and subscribe communication pattern, registering messages with the message broker, and interested services subscribing to relevant messages. Through this decoupled communication, the architecture remained flexible, rapidly evolvable, and supported a continuous delivery mindset. The team can choose RabbitMQ/Kafka as its middleware platform, benefiting from its lightweight design, high performance, reliability, and scalability.
Tools Walk-through
No doubt the architecture that we just described affords some great new capabilities, that were simply not practical even years ago. Composability, evolvability, immutable environments, infrastructure as code, and so forth, make it easier to continuously deliver software and business value, and also thereby enable greater innovation and business agility. However, all of this comes with a cost, the cost, of course, is greatly increased complexity.
When the application is a monolith and if something goes wrong, it’s not hard to figure out where to look. You would typically look at the application’s UI and its logs. You could reproduce the issues in your test and development environments easily by following some set of instructions. You could trace back to the issues by sequentially and systematically tracing back to what were mostly synchronous method costs. Doing this in a highly distributed dynamic and ephemeral environment becomes very difficult.
This architecture would not have been viable unless we have automation and tooling that helped us put a lid on top of such a combinatorial explosion of complexity. Let’s explore the tools that come to play.
1. Service Discovery Tools:
Service discovery tools facilitate communication between processes and services within a cluster by enabling them to find each other. These tools play a vital role in distributed applications, allowing for seamless interaction among various components. By providing mechanisms for identifying and locating services, service discovery tools ensure effective communication and coordination in complex architectures.
2. Logging, Log Aggregation, and Log Visualization Tools:
In distributed systems, logging becomes crucial for troubleshooting and monitoring applications. Log aggregation tools consolidate logs from multiple sources, making it easier to search and index log data. These tools enable the visualization of log information in powerful ways, allowing developers and administrators to identify and resolve issues more efficiently. The ability to analyze logs collectively is especially beneficial in identifying patterns and potential problems within the system.
3. Monitoring and Alerting Tools:
Monitoring tools continuously track key metrics of the system’s health, such as service response times and CPU usage. These metrics provide insights into the system’s performance, allowing early detection of anomalies and potential failures. When predefined thresholds are exceeded, alerting tools trigger notifications or interventions, ensuring timely action is taken to prevent and address issues promptly.
4. Continuous Delivery Tools:
Continuous delivery tools streamline the process of transforming code into executable packages and deploying them into production environments. This category includes tools for source control, build management, deployment pipelines, and build artifact management. By automating these steps, continuous delivery tools enable developers to deliver code changes rapidly, consistently, and reliably.
5. Configuration Management Tools:
Configuration management tools are employed to configure, set up, and manage the hosts that run Docker containers. These tools are essential for maintaining the desired state of the infrastructure and ensuring that containers are deployed correctly. Whether on physical or virtual machines or cloud infrastructures, configuration management tools play a key role in orchestrating the environment and supporting containerized applications.
Conclusion
The article delves into the concept of architectural agility and its crucial role in the success of enterprise initiatives. It begins by highlighting the traditional architectural problems faced during the Architectural Development Method (ADM) and introduces the Agile Design Sprint (ADS) as a solution. ADS is a practical approach that enables teams to rapidly develop and validate architecture through iterative and collaborative processes.
In the first part of the article, the focus is on traditional architectural challenges, and how they hinder the progress of enterprise projects. It then introduces the ADS, a methodology that embraces agility and collaboration to address these challenges effectively. ADS empowers teams to swiftly validate architectural decisions, enabling them to adapt and respond to changing requirements and emerging technologies.
The second part of the article takes a deep dive into the ADS methodology, providing a comprehensive explanation of each phase — framing, exploring, deciding, and realizing the architecture. It emphasizes the importance of collaboration, user-centric design, and iterative development in delivering robust and adaptive architectures. ADS fosters creativity, promotes quick feedback loops, and encourages continuous improvement.
Looking ahead to the next article, it will explore the pivotal role of Enterprise Architects and Technical Architects in Agile Architecture practice. These key stakeholders play a critical role in ensuring that architectural decisions align with the organization’s strategic goals and business objectives. They act as catalysts for collaboration and communication between business stakeholders, developers, and operations teams. By leveraging their expertise and guiding principles, Enterprise Architects and Technical Architects facilitate the successful implementation of agile architectural practices across the organization.
In conclusion, the article highlights the significance of architectural agility in driving successful enterprise initiatives. The ADS methodology provides a structured and iterative approach to architecture development, promoting responsiveness, adaptability, and collaboration. With the upcoming article focusing on the role of Enterprise Architects and Technical Architects, readers will gain insights into the leadership required to establish and maintain agile architectural practices within their organizations.
