Defining a framework to maximize the impact that software architects have within an organization is a continuous process. A software architect's duties include ensuring the quality of an organization's systems, providing technical guidance, and empowering teams to make local decisions with strategic alignment. This is typically handled by a dedicated architecture group, separated into multiple levels. Its definition can be framed under the concept of “Shift Left”, which refers to the practice of moving activities and decisions to the early stages of a process, rather than leaving them for the end.
Shift Left applied to architecture
A practical example of applying "Shift Left" in architecture is establishing a set of guidelines and standards that teams must follow when developing new projects. These guidelines can include design principles, recommended architectural patterns, security practices, and more.
Instead of waiting until the end of the development process for architects to review and validate the design of each project, teams are encouraged to consult the guidelines and perform internal reviews from the earliest stages. This makes it possible to identify potential problems or deviations before too much time and effort is invested in development.
For example, suppose a team is developing a new cloud service for the organization. Applying the "Shift Left" concept, architects can provide a set of guidelines covering aspects such as choosing a microservices-based architecture, using containers for deployment, and implementing proper security practices.
The team can then use these guidelines to develop the service, ensuring it complies with the established best practices. Along the way, they can conduct internal reviews and consult with the architects to make sure they are following the right approach and addressing potential challenges appropriately.
By applying "Shift Left," architects empower the team to make local decisions while providing guidance and guidelines from the start of the project. This allows the team to move forward more efficiently and effectively, ensuring the quality and strategic alignment of the service being developed.
Comparison of shift left with the traditional model.
The following process is recommended for developing an architecture framework:
-
The Software Architect Elevator
-
Architecture Decision Records
-
Guidelines and standards
-
Advisory and consulting
-
Reference Architecture and proofs of concept
-
Improvement opportunities
-
Prioritizing investments
-
Resource planning and project design
-
Execution
-
Multi-role architects
The Software Architect Elevator
From the book The Software Architect Elevator
One of the best concepts that can be applied to the creation / adoption of a Software Architect framework comes from Gregor Hohpe, author of the book The Transformation Architect - The Architect Elevator.
The book depicts the "Penthouse" as a representation of the roles of executives and enterprise architects who make decisions about strategy, investments, and budgets, while the "Engine Room," located at the bottom of the building, represents the team that executes projects and makes local decisions.
Architecture Decision Records
An "Architecture Decision Record" (ADR) is used to capture the rationale, context, and implications of decisions made by the architecture team. This includes information such as the problems addressed, the alternatives considered, the decision criteria used, and the final decision made. This record is typically produced by Enterprise Architects and serves to empower teams so they can make local decisions while staying aligned with the IT strategy.
There is a very fine line between diversity (which adds value) and chaos (which does not); unmanaged evolution will lead to complete chaos (don't be afraid to have some architectural influence). — Stefan Tilkov
While it's true that problems can be solved in different ways, using an ADR allows us to reduce the chances of chaos over time and of losing sight of the IT strategy. This is explained by the concept of the "Cone of Possibilities."
For example, if a single cloud provider has already been chosen, documenting that decision eliminates the effort and time other teams might spend on explorations, proofs of concept, and so on.
Guidelines and standards
Once decisions are made, the details matter to ensure the decision is delivered and understood effectively so it can be adopted by the teams. The goal is to achieve deterministic outcomes through a standard set of "knowledge tools" to ensure the quality and consistency of the architecture's maturity. This can involve several steps, such as:
-
Guideline definition: creating standards.
-
Guideline adoption: management review, implementation plans, and training.
-
Guideline review: periodic review and measurement of alignment.
Guidelines
Guidelines are directives or rules established to steer teams' actions and decisions regarding software architecture. These guidelines are essential to ensure the quality and consistency of the systems developed within an organization. By following the established guidelines, teams can make sure their solutions comply with recommended standards and practices.
An example of a guideline could be the adoption of a specific architectural pattern, such as microservices architecture. This guideline states that teams must design their systems using a microservices-based approach, where each service is developed and deployed independently. By following this guideline, teams can take advantage of the scalability, flexibility, and resilience benefits that microservices architecture provides.
Beyond the guidelines themselves, it's important to measure team maturity in terms of their ability to follow the guidelines and apply architecture best practices. This can be achieved by implementing a maturity assessment model, which makes it possible to evaluate and measure the level of guideline adoption by the teams.
An example of a maturity assessment model could be a five-level scale, where each level represents a degree of maturity in adopting the guidelines. For example:
-
Level 1: Initial - Teams have a basic knowledge of the guidelines, but adoption is limited and not standardized.
-
Level 2: Repeatable - Teams follow the guidelines consistently, but there is still room for improvement in terms of standardization and documentation.
-
Level 3: Defined - Teams have established processes for following the guidelines, and adoption is standardized across the organization.
-
Level 4: Managed - Teams regularly monitor and measure their adoption of the guidelines, and make continuous improvements based on the results.
-
Level 5: Optimized - Teams are leaders in guideline adoption and keep improving and refining their architecture practices.
By measuring team maturity, organizations can identify areas for improvement and provide additional support and resources to help teams reach higher maturity levels.
A common approach to measuring team maturity with respect to architecture guidelines is to use surveys or assessments that allow teams to self-evaluate against the established criteria. Some examples of questions that can be included in a maturity survey are:
-
Does the team know the established architecture guidelines?
-
Does the team consistently follow the guidelines when designing and developing solutions?
-
Does the team document and share its architecture and design decisions with other teams?
-
Does the team conduct regular reviews and assessments of its architecture to identify areas for improvement?
-
Does the team actively seek opportunities to learn and improve its software architecture skills?
-
Does the team have a clear understanding of how its solutions align with the organization's architecture strategy?
These questions can be adapted and customized according to the organization's specific guidelines and needs. The answers to these questions can provide an overview of team maturity and help identify areas of strength and opportunities for improvement.
It's important to note that measuring team maturity is not a one-time process; it should be done periodically to assess progress and make adjustments as needed. Additionally, it is essential to provide feedback and support to teams to help them improve and reach higher levels of maturity in adopting the architecture guidelines.
Advisory and consulting
With the guidelines and standards defined, the next stage is adoption, through direct work with the "Engine Room" in an advisory role. Ideally, the previously generated artifacts are referenced to ensure maximum transparency about expectations.
Architecture's responsibility is to constantly find a way to communicate the strategy, guidelines, and standards. Teams are responsible for reviewing them, finding a path to adoption, and providing feedback whenever they want to make decisions where no guideline exists or where one of them needs to evolve.
At this stage it is key to understand that there must be "mutual curiosity": Enterprise Architects don't see everything, and Technical Architects don't consider the broader organizational context.
Reference Architecture and proofs of concept
Through the team advisory process, Architecture can gather information and feedback to make adjustments or investments. Starting with questions like:
-
Could this be built as a capability reusable by more than one team?
-
Could it reduce costs?
-
Do current capabilities limit the future of the business?
Then an exploration stage can take place, running proofs of concept to accept or reject an idea, using reference architectures for this purpose.
Proof of Concept
A proof of concept is an exercise or experiment carried out to evaluate the technical, functional, or commercial viability of an idea or concept. It is used to test and validate hypotheses before investing significant resources in the full development of a product or project.
A proof of concept is usually performed at a smaller scale and with a limited scope, but with the goal of demonstrating the feasibility and potential of the idea. It may involve building a prototype, simulating a scenario, or running controlled experiments.
Suppose a company is considering implementing a new automated inventory management system in its warehouse. Before investing in the full implementation of the system, they decide to run a proof of concept to evaluate its viability.
In the proof of concept, they select a section of the warehouse and equip it with sensors, barcode readers, and other devices required for the automated inventory management system. Then, they run tests to verify whether the system can perform the required tasks, such as tracking and recording the location and quantity of products in real time.
During the proof of concept, they collect data, evaluate the system's performance, and analyze the results. If the proof of concept demonstrates that the automated inventory management system meets the expected requirements and benefits, the company can choose to implement it across the entire warehouse.
The proof of concept allows the company to reduce risks and make informed decisions before fully committing to the system's implementation. It also provides the opportunity to identify potential challenges and make adjustments or improvements before scaling the project.
Reference Architecture
A reference architecture is a set of patterns, practices, and standards used as a guide for designing and developing software systems in an organization. It provides a common frame of reference that helps development teams build coherent, high-quality systems.
An example of a reference architecture is the microservices architecture model. In this model, systems are divided into small, independent components known as microservices. Each microservice can be developed, deployed, and scaled independently, allowing for greater flexibility and agility in application development.
A reference architecture can also include specific architectural patterns, such as the three-tier architecture pattern (presentation, business logic, and data persistence), which is used to separate and organize the different responsibilities of a system.
Improvement opportunities
The improvement opportunities identified by Architecture, which have gone through the Engine Room for feedback via exploration and proofs of concept, are synthesized and executed to evolve the guidelines.
The goal is to build a business case to change the strategy or investment budgets. A minimal template for standardizing these details should include:
-
Problem statement: explains why this is a problem for the organization.
-
Context: provides relevant background and details about the problem.
-
Benefits: details the advantage the organization gains from this investment.
-
Risks: outlines the dangers of not acting on this opportunity.
-
Cost-benefit analysis: evaluates the relationship between the costs and the expected benefits of the investment.
-
Implementation plan: describes how the improvement opportunity will be implemented.
Prioritizing investments
Investment prioritization can vary from one company to another. The ideal moment is before the next planning or investment cycle takes place, to avoid disrupting currently committed deliverables.
Prioritize the opportunities with the greatest benefits or risks for review, keeping in mind that not everything will be tackled at once. Communication efficiency is important during this phase due to the likelihood of many competing business priorities.
Investment prioritization is a crucial process to ensure that resources are allocated effectively and strategically. To carry out this process, two reasoning approaches can be used: inductive reasoning and deductive reasoning.
Inductive reasoning is used in the Engine Room, where data is analyzed and different options and potential solutions are evaluated. This approach is based on observing patterns or trends in the data and formulating a general conclusion. For example, by analyzing data A, B, and C, certain common patterns or characteristics can be identified that lead to the conclusion that solution D is the best option. Inductive reasoning is useful for generating ideas and options, and for exploring different possibilities before making decisions.
On the other hand, deductive reasoning is applied in the Penthouse, where investments are selected and prioritized based on the data and analysis presented. In this approach, you start from a general premise and apply specific principles or rules to reach a specific conclusion. For example, backed by data A, B, and C, the conclusion is that solution D should be implemented. Deductive reasoning is useful for making informed, strategic decisions, since it is based on concrete data and analysis.
Implementing these reasoning approaches helps ensure that investments are made in an informed and strategic manner. By using inductive reasoning in the Engine Room, different options and potential solutions can be identified, possibilities explored, and impacts assessed. Then, in the Penthouse, deductive reasoning is applied to select and prioritize the investments that maximize impact and results for the organization. This prioritization process based on inductive and deductive reasoning improves decision-making efficiency and helps ensure resources are allocated optimally.
In summary, prioritizing investments using inductive and deductive reasoning is an effective approach for making informed, strategic decisions. By using inductive reasoning in the Engine Room and deductive reasoning in the Penthouse, you can explore different options, assess impacts, and select the investments that generate the greatest value for the organization.
Resource planning and project design
For the opportunities approved during the investment process, the Architecture function facilitates a path to execution through technical and project planning, breaking down the efforts into broad categories with the help of the following questions:
-
Does the team need a reference Architecture?
-
Which systems need to be created or refactored?
-
What is the ideal team composition for this effort?
-
What specific skills are missing to ensure success?
-
How many teams are affected by implementing this?
-
Can this effort be assigned to a single team, or does it need to be a broader multi-team program?
-
How long will this effort take?
A good resource to use during project design is the book Righting Software, which discusses work decomposition and team composition based on budget and time. Below is a chart showing how teams could be formed.
“Righting Software: A Method for System and Project Design” by Juval Löwy
Execution
This can be broken down into accountability, delivery, and execution of a project. It is crucial that the initiative's sponsor takes accountability for ensuring the established goals are met and the project is executed effectively.
Accountability involves making sure all parties involved understand their roles and responsibilities, and that there is clear communication and coordination between the different teams and stakeholders. The sponsor must ensure that adequate resources, both human and financial, are allocated to carry out the project successfully.
Delivery refers to delivering the project's results in accordance with the established deadlines and requirements. This involves making sure all planned stages and activities are completed, and that the necessary tests and validations are performed before final delivery. The sponsor must oversee and closely track the project's progress, ensuring milestones are met and any deviation is addressed in a timely manner.
Execution refers to the effective implementation of the project's results in the operating environment. This may involve training staff, installing infrastructure, or integrating existing systems. The sponsor must ensure that all activities required for the successful execution of the project are carried out, and that the necessary tests and adjustments are made to guarantee smooth operation.
Multi-role architects
In certain scenarios, there may be a desire to place architects in multiple roles (product owner, developer, security). While the architect's dedicated capacity to ride the elevator is lost, there are also benefits to this trade-off, some of which are:
-
Greater understanding of context: By getting involved in different roles, the architect gains a broader and deeper view of the project's context and challenges. This allows them to make more informed, strategic decisions by considering how each component or decision affects the entire system.
-
Better communication and collaboration: By being directly involved in the team's daily work, the architect can establish more effective, collaborative communication with team members. This facilitates mutual understanding, problem solving, and goal alignment.
-
Greater agility and adaptability: By taking on multiple roles, the architect becomes more versatile and adaptable to different situations and changes in the project. They can quickly adjust their approach and make agile decisions to address challenges in real time.
-
Knowledge transfer: By working in different roles, the architect can share their experience and knowledge across different disciplines with the team. This promotes learning and skill development within the team, improving the team's overall ability to tackle architectural challenges.
-
Greater efficiency in decision-making: With knowledge and experience across different areas, the architect can make decisions more efficiently by considering multiple perspectives and quickly assessing the implications of each option.
-
Greater visibility and recognition: By taking on additional roles, the architect has the opportunity to stand out and demonstrate their ability to lead and contribute in different areas. This can lead to greater visibility within the organization and recognition for their experience and skills.
-
Greater satisfaction and motivation: By taking on additional roles, the architect experiences greater diversity in their daily work, which can result in higher satisfaction and motivation. And this can lead to greater commitment and overall performance.\
In summary, when an architect takes on other roles, not only do the team and the project benefit, but so does the architect. Through greater understanding, communication, adaptability, and knowledge transfer, the architect can maximize their impact and contribute more effectively to the project's success.
Key takeaways
-
Defining a framework to maximize the impact of software architects within an organization is a continuous process.
-
Ensuring system quality, providing technical guidance, and empowering teams to make local decisions are key functions of software architects.
-
Implementing the "Shift Left" concept empowers teams to make local decisions while providing guidance and guidelines.
-
Using an Architecture Decision Record (ADR) helps capture and justify the architectural decisions made.
-
Establishing guidelines and standards, measuring adoption, and providing support and consulting are recommended practices for maximizing the impact of software architects.
-
Effective communication, investment prioritization, and resource planning are important aspects of the process of defining a framework for software architects.
-
Placing architects in multiple roles can bring benefits in terms of context understanding, communication, agility, and knowledge transfer.