How can you simplify your technical architecture?

Uma simplifica??o de Arquitetura é também o resultado da Gest?o do Portfolio de Aplica??es (ou APM, sigla em inglês para Applicaion Portfolio Management). Existem alguns frameworks que auxiliam nessa gest?o, normalmente utilizo o TOGAF, o modelo conceitual de desenvolvimento de arquitetura do TOGAF é o ADM (sigla em inglês para Architecture Development Method), uma das primeiras etapas desse processo é a identifica??o do AS IS, ou o estado atual.

I have approached this historically by: 1. Conducting interviews with relevant technical and business stakeholders. Document your interviews and your understanding and analysis. 2.Understand the current systems used, how the information flows, frequency and what tool/platform is used to make those updates. 3. Visualize the current state architecture using a tool like Lucidchart. 4. Review the architecture with the stakeholders you interviewed to see if there was any gap in your understanding. 5. Point out any glaring things where the flow of data is redundant or there is a big gap.

Very often the current state is not documented. Apply a Discovery tool as accelerator to create the current state. I repeat, apply it as an accelerator. Regardless of the most advanced A.I techniquie embeded in the tool, you must check sanity-check the results.

Identify sources of complexity such as legacy systems, technical debt, redundant or inconsistent data, unnecessary dependencies, and over-engineering. It's also crucial to evaluate how effectively the architecture meets both functional and non-functional requirements and aligns with the business strategy and vision. This initial assessment forms the basis for identifying simplification opportunities and planning subsequent actions. Reflecting personally, I've found that understanding the existing architecture deeply is key to effective simplification. It helps in making informed decisions that balance complexity reduction with maintaining or enhancing system functionality and business alignment.

I would interpret this in a different way. Define the next target state (or milestone) as a set of desired outcomes. Create guiding principles that can serve as decision-making criteria and decide on what the first iteration needs to be. Spending exhaustive time on defining a detailed target state is wasteful and delays value realization. I would advocate for keeping things simple and have an experienced tech leader and team who know when to flex and add complexity and where to hold off. This is a key piece of delivery that is very often missed.

Once you have a good understanding and picture of current state architecture, you can understand where the gaps are. Aim for simplicity in your future state architecture by considering things like: 1. Is the system that is doing the calculation right now, is that really the best system? Are we introducing any additional complexities with this setup? For e.g: Does Salesforce really need to calculate complicated revenue metrics or can that be done in Snowflake and fed into Salesforce. 2. How are we integrating systems - is it point to point integrations - there needs to be consistency so it can be easier to manage and maintain. 3. Is the current system truly the best system for its purpose-if not evaluate a better system and recommend that.

Simplifying technical architecture hinges on the strategic selection of an architecture style. As a global leader in Information Technology and PMOs, I advocate for choosing a style that aligns with your system's needs and facilitates clear, efficient component interaction. Whether it's monolithic for simplicity, layered for organized hierarchy, microservices for flexibility, event-driven for dynamic responsiveness, or serverless for operational efficiency, the key is to match the architecture with system requirements and quality attributes. This decision not only simplifies the architecture but also optimizes performance and scalability, demonstrating an informed, strategic approach to IT system design and management.

Look for opportunities to remove complexity by establishing consistency. I've seen many cases where architectures grew unmanaged, resulting in inconsistent use of design patterns and too many variants. Standardizing the use of patterns will lower complexity, make code easier to maintain, and enable future expansion.

1. Transitioning to open systems like Spring and Angular to eliminate licensing costs and reduce reliance on third-party interfaces. 2. Implementing HTML and Java to reduce the number of languages for maintenance and support. 3. Reducing the database footprint and standardizing databases to optimize data queries and enhance system efficiency. 4. Consolidating the user interface into a single, web-based interface for easier monitoring and issue response. 5. Simplifying and minimizing applications by utilizing a consistent set of technologies and operating system tools. 6. Upgrading the system protocol from CORBA to AMQP for future requirements. 7. Preparing the system for future cybersecurity solutions and interaction with subsystems.

You need to be really thoughtful on what you should automate. In start-ups, when you dont have the luxury of a lot of resources, the focus should be on automating tasks that are truly critical and needed. You don't have to automate everything. Dont aim for 100% automation but automate till 80% of those scenarios. Ensure you are not breaking anything else as part of your automation. Check if there are any other downstream impact as part of your automation Over-communicate on what changes are coming.

As the old adage goes, the best place to start is the beginning. In Architecture, more often than not, current state architecture doesn’t exist. Creating the current state oftentimes reveals the how and why manual process exists. Once the how and why are completely understood, automation and validation process can begin.

This reduces human error, boosts efficiency, and maintains quality. For infrastructure management, leverage configuration management, infrastructure as code, and containerization to automate and optimize provisioning and management. Additionally, employing performance, load, and stress testing ensures your system is optimized for performance and scalability. These steps not only simplify the architecture but also enhance its reliability and effectiveness. In my experience, automation and optimization have been transformative. They not only streamline workflows but also foster a more agile and responsive architecture, crucial in today's fast-paced technology landscape.

How you approach this depends on the reason to simplify. Simplification could be triggered by high cost, operational incidents, inability to scale, slow to change, or the inability to take on new capabilities. Architectures become complex over time for many reasons. In all cases, the first steps are to understand the existing architecture and document it. Existing artifacts are likely to be outdated or insufficient so don't assume anything existing is accurate. Once you have a handle on the current state, plan out the changes and create a thorough transition plan that simplifies portions of the architecture in the proper order. You will likely need to build transitional components temporarily as you execute.

Understand your existing architecture thoroughly. Document all components, dependencies, & processes.Determine what you want to achieve through simplification, such as improved performance, reduced costs, or faster development cycles.Set specific, measurable goals to track progress.Consolidate redundancy to reduce duplication.Minimize interdependencies between components for a loosely coupled architecture.Use a consistent set of technologies, frameworks, and tools across your architecture.Implement automation for routine tasks, such as deployment, testing, and monitoring.Simplify data models by removing unnecessary tables, fields, or relationships.Set up robust logging and monitoring systems to quickly identify and resolve issues.Document!!