7

Align and Scale Agile Framework with Enterprise Architecture

Agile frameworks designed for large enterprises, such as SAFe, help companies apply lean and agile principles. Adaptive design and engineering practices are key components of enterprise architecture, according to SAFe. These practices help teams and programs work together on a shared technical vision. Architects provide strategic guidance, reference architectures, and technology standards to these new agile organizations. When they are combined, they facilitate the standardization of teams’ work. Reworks can be avoided by aligning projects to company standards and bridging silos.

Your enterprise architecture is the collection of structures and processes that support your organization. It should be flexible, easily extended, and easily evolved over time. Enterprise architecture is all about exploring, identifying, and optimizing an organization’s architectural ecosystem. Because of this, enterprise architects should have the ability to work cooperatively and in a collaborative manner, as well as collaborate closely with other teams. With the adoption of SAFe by large organizations, intentional architecture, and emergent design, the need for a better understanding of its key elements is also growing. As enterprise architects interact more frequently with development teams, their roles and practices may change as well.

The topics covered in this chapter are as follows:

• Technology choices and usage
• Architectural strategy
• Exemplifying lean-agile architecture
• Architecting for DevOps and release on demand
• Applying SAFe to Enterprise Architecture and cloud

Technology choices and usage

Gartner predicts that 60 percent of organizations will rely on EA to spearhead business strategies for digital innovation in 2023. The use of EA in plan, design, and analytics is already widely adopted by businesses today. A company’s business portfolio can be expanded through EA, which enables IT and business to merge together. With EA’s data management, businesses can predict future models and, as a result, increase profitability while reducing costs.

Over the past decade, the industry has developed various trends, architectures, languages, and tools. Because of that, there are many emerging JavaScript frameworks today because technology changes at such a rapid pace. It appears to be more difficult than ever for architects to choose a technology, whether it is a library, framework, programming language, or vendor product.

It is also common for enterprises to hire consultant architects when internal architects cannot reach a consensus. Technical architects are needed by companies with many products, projects, or entire lines of business. Most of the time, making a decision that affects multiple teams will prove challenging. There is a risk that it could become highly politicized, especially when selecting vendor products. An enterprise may need to even issue a request for proposal (RFP) to get vendors to respond in such a scenario. Multiple entities provide points to be considered in the selection of technologies during an exhaustive selection process. A strong understanding of why certain decisions are made, as well as why those decisions will benefit the work, is crucial for architects. In the following list, several high-level issues are discussed. Different organizations have different definitions of digital transformation. However, it generally involves the following:

• Evolving technology trends (i.e., cloud services)
• Artificial intelligence (AI) and machine learning (ML)
• Advanced analytics and big data
• Internet of things (IoT)
• Robotic process automation (RPA)

Planned strategic action has always been essential to business success. As we move further into the digital era, it has become more critical than ever to plan for this transformation. By implementing transformation, organizations become more agile and dynamic, enabling them to respond to market changes more quickly. Companies can adapt to fast growth using cloud-based offerings such as Software as a Service (SaaS) and implementing AI and RPA. As most projects need to move at a much faster pace, digital transformation offers great help in this regard to the EA facilitators.

Assigning application components to technology architecture represents the association of software/hardware components. Assembled and configured, they form the enterprise’s technological infrastructure, which is largely procured in the marketplace. By examining the technology architecture, you can see how individual application components will be realized and deployed. It is possible to study migration problems at an early stage that can develop between different stages of the Information Systems evolution path. The purpose of technology architecture is to solve logistical and location problems related to hardware and IS management. Also, a well-designed technology architecture ensures that components of the delivered application integrate seamlessly.

Adopting scaled agile in technology domains

In development value streams, specialized teams in software, hardware, electrical, electronics, and other technology areas drive the development of operational value streams. They contribute to the definition, development, testing, and deployment of solutions to internal and external customers. The right products for the right customers are created by using customer-centricity and a design thinking approach, and agility provides the flexibility to address market changes and emerging opportunities rapidly.

There is a long tradition of embracing agility in the software industry. In fact, SAFe offers practitioners the flexibility to deploy it at any level of enterprise scalability. Our advanced interests or value areas include behavior-driven development (BDD), test-driven development (TDD), agile testing, refactoring, and spikes. Scaled agile software architecture combines values, practices, and partnerships focused on supporting evolutionary design and architecture. DevOps embraces the philosophy of continuously updating a system’s architecture over time, while simultaneously supporting the needs of its users. The Big Up-Front Design (BUFD) and phase-gate processes entail a high amount of rework and redesign, which results in delays.

Agile development practices are supported by an agile architecture that encourages collaboration and design simplicity. Agile architectures also enable testing, deploying, and releasing capabilities, just as Agile development practices do.

Applying SAFe to hardware

Cyber-physical system builders will be defined by hardware innovation for the next decade or more, and those who don’t develop hardware quickly are at a competitive disadvantage. In order for developer changes to be verified, the larger context of the system must be taken into account. Physical parts created during hardware development have high material costs and long lead times. In this case, hardware verification often takes place later in the product development cycle.

The first step in hardware development is to develop models using design tools (e.g., electrical and mechanical CAD). Virtual models are now being used by many organizations for analysis and simulation to provide early feedback in a bigger system context. Prior to manufacturing, engineers can ensure their designs are compatible with stakeholders and validate them with stakeholders. Physical parts can only be used to verify some aspects of a design.

For early feedback, additive manufacturing and 3D printing are already widely used. As well as being used for production parts, they can be used for innovation when higher change frequencies are required and lower volume is necessary. It may also be possible to accelerate manufacturing times by reducing quality and reliability constraints. In contrast to production parts that withstand a harsh environment for years, development parts often operate in a controlled environment and are replaced after the next revision.

A vital aspect of system design is allocating functionality to various elements. With the advent of over-the-air updates enabled by growing network capacities and costs, behavior is rapidly shifting to programmable components. Small changes are tested, integrated, and validated in a context before being delivered using continuous integration. The development of hardware functions begins with virtual designs. As a result of automating continuous integration activities, developers get faster feedback on changes in these environments. In addition to building the system, developers must build a continuous integration environment.

Balance intentionality and emergence

In the early days of architecture, traditional approaches were followed, lots of documentation was generated, and unvalidated decisions were made. Combining intentionality and emergent design is another solution for aligning architecture with business needs. Developers create a system so that they can see what works before the architecture emerges.

Intentional architecture

This defines an architectural strategy and initiative that are meant to be purposeful and planned. They provide guidance for synchronizing the design and implementation of inter-team solutions, as well as improving performance and usability.

Emergent design

This implements a fully incremental and evolutionary strategy. As a system is built and deployed, developers and designers can respond to the needs of users in real time. With this balance, agile architecture can address enterprise solution complexity with a lean-agile approach. As well as supporting current users, the system has evolved to address future needs. Collectively, emergent design and intentionality provide the technical foundation for future productions of business value that continually build and extend the architectural runway.

It is impossible for an organization’s value to flow through its functional silos. Most work has been structured according to functional skills. A rocket nozzle, for example, would have a mechanical structure that is made up of hardware, firmware, and software. According to the traditional method, each would be independently developed. In order to verify and validate, all components must be integrated together at the end, making adjustments very difficult. Agile development organizes cross-functional teams to increase collaboration and minimize delays:

Figure 7.1 – Team structure

The acronyms in the preceding image are as follows:

• HW – Hardware
• SW – Software
• FW – Firmware
• ART – Agile Release Train

Three equally viable approaches are shown in the preceding figure, as well as the circumstances in which they are most useful. A creative environment may not require the collaboration of an entire team, and the domains may work independently. However, the teams are aligned by working together as part of the same ART and by managing dependencies and implementing SAFe practices to integrate frequently. Predictability is higher in other environments. Using a common roadmap that defines key integration points, the teams can work independently on their system components. These teams are not necessarily on the same assembly reference template, and the organization may evolve over time. Nonetheless, early product development requires more comprehensive feedback.

Agile teams utilize cross-functional skills to maximize value at every iteration. Mechanical engineers can update firmware, or software engineers can modify CAD designs and rerun analysis tests. Deep functional skills are unfortunately not rewarded in many organizations. By using Agile methods, the skills required to build innovative products are broadened while not sacrificing expertise.

Architectural strategy

Enterprise architecture involves configuring computing resources to serve a company’s business objectives. Aligning the company’s strategic goals with its existing business processes, the data and information it generates, and the supporting infrastructure are key components of the success of this process. By producing such a report, a company’s current technology is noted, along with how future technologies will change or fit into the current technology.

In most cases, business changes are also technology changes in the age of digital transformation. Enterprise architects are also finding that the strategy and change planning process itself has a lot to gain from the enterprise architect’s toolbox. A key role in the development of strategy and execution of those initiatives can be played by the enterprise architect’s capability to build models and use those models to generate actionable insights. Even though conventional planning processes do not include those models, they force much greater levels of communication than conventional processes.

It’s imperative for EAs to understand the source of their value if they are fortunate enough to be selected as a planner. Therefore, you should work in conjunction with the business strategy teams and the Project Management Office (PMO) teams rather than competing with them. Turning an idea into a comprehensive EA strategy takes time and a lot of conversations. As technology progresses and priorities change, the journey of the EA will evolve and mature over time.

Solutions architecture strategy

It is important for each new IT project to have a solution architecture that enables the business to implement technical solutions in line with its IT strategy, focusing on a specific set of business needs. Solution architects conceptualize the ideal solution based on a particular problem while considering all functional and non-functional requirements. Organizing and managing technical teams can be improved by establishing clear guidelines. Solution architects play a crucial role not only in collaboration with development teams but also in the broader enterprise. The EA transforms strategic visions into actionable solutions, so working with them is vital:

• Solution and EA focus on different tasks, regardless of their interdependence and ultimate goal – that is, to create more value for a business through the intelligent use of technology. EA, as its name implies, presents a comprehensive view of the enterprise, including all business entities and their relationships with technology and applications. Applications life cycles and the definition of IT strategies are key concerns for EA.
• In addition to minimizing costs, eliminating redundant technology, and managing the impact of a digital redesign, these strategies are designed to reduce risks as well. For a target architecture to be successful, it must be understood at the level of an entire organization. A company’s EAs must keep an in-depth view of the organization, so their attention to detail is rather limited. The technical side of IT infrastructure is thus less significant to them.
• The EA usually handles technical questions, but the solution architect performs specific tasks as well. Neither of them is directly responsible for implementing new IT solutions. Their role is to ensure that the technical architects can properly implement them. Both solution architects and EAs share similar responsibilities. In contrast to EA, solution architecture focuses on detailed designs.
• Technical architects and EAs work together in synergy to create a successful enterprise vision. In order to maximize a company’s ability to generate value through its use of technology, these two elements are essential. Despite the fact that enterprise and solution architects have overlapping responsibilities, their functions differ, and they rely on each other.

Basically, EAs develop abstract strategies that are later taken over by solution architects to be turned into actual solutions.

Infrastructure strategy

In the architecture field, infrastructure is a term that people use to describe a wide variety of things. Infrastructure architecture is a defining concept for facilitating boundaryless communication across an enterprise’s scope. The content of e-services will expand with the progress toward e-service aggregation.

A thorough and strategic EA review is vital to the success of any system on the roadmap for core systems. Ideally, a well-designed enterprise infrastructure strategy will outline the key systems to achieve the company’s business objectives and determine its success. Without careful consideration of the reality, you can get swept up in the possibilities of what could be built. Most IT and infrastructure strategies have what is called the ivory tower approach – when the EA introduces everything they add to the architecture review. From a practical standpoint, it fails to emphasize everything that teams should do. Enterprises reviewing systems for critical path applications benefit greatly from taking a far more pragmatic approach.

Additionally, infrastructure applications may include data that is common or shared. Business architecture also includes elements that are common across organizations, such as business principles, common business processes, and so on. TOGAF’s Architecture Development Method (ADM) is meant to address architecture domains that are orthogonal to infrastructure architecture. Infrastructure architecture is not explicitly identified in the ADM description. Still, such a setup is perfectly viable with the ADM. Here is a brief overview of how the ADM was used to create an infrastructure architecture.

Implementation strategy

In order to achieve the business goals and objectives set by the EA program, the architectures created and maintained by the program must be implemented. Regardless of whether the solution is being purchased or internally developed, these architectures will be an invaluable tool for implementation teams. Both the business and technical components are involved in the implementation, and the architecture acts as a guideline to ensure that the implementations align with enterprise-wide initiatives. In addition to formal guidance, regular meetings through the PMO will likely be a regular part of the process.

A centralized repository for architecture and implementation models enables traceability between the two disciplines. It makes EA ideally positioned to provide guidance and governance. There can be an application of principles at an implementation level, demonstrating the importance and applicability of the principle. To implement the target architecture aligned with the plans and schedules defined in these offices, the architecture program must work closely with the project management offices. In addition to the oversight of implementation projects, the architectural office coordinates plans with the PM offices to schedule and carry out their architectures.

Executive support is essential for a successful EA program. In order to do so, they must understand the strategic importance of the project. A program like this can provide a lot of value to an organization. EA must have access to all divisions and the entire organization if these programs are to be effective. Creating and managing EAs can be done using an architecture framework. The architecture repository stores the content, and the architectural team is organized, including guidance on creating architectural design and governance over the construction.

EA is a powerful platform that provides all the features necessary for creating and managing architectural frameworks. A repository for architectural content is incorporated into EA and used to store architectures at multiple levels across the business domains. As a tool with powerful features designed by practitioners, it provides executives, managers, and operations managers with content and views they will appreciate. As a result, EAs can imbed content from a variety of sources, allowing architects to reuse content from other tools.

Architectures are developed according to a process or method. Many frameworks do not provide a predefined process. Organizations are responsible for creating and configuring their own processes. Through EA, processes can be specified at any level; hence, more granular aspects of the process are discussed. Input and output critical to architecture are stored in the architecture repository. Architectures, their components, standards, references, principles, governance registers, and so on are included in this activity. EA is a fully featured architecture repository regardless of the Architecture framework that is being used. Its powerful features offer a number of options for creating a program efficiently, importing content, defining viewpoints, generating publications, and so on.

Common challenges when establishing an EA strategy

Creating an EA strategy comes with a variety of risks and challenges. Technology changes so fast that even entire methodologies, systems, and applications can become obsolete in a short period of time due to how quickly technology develops. In combination with a tendency to follow the latest trends, the EA model is particularly prone to becoming outdated. This is especially true when a standard version is in place.

The EAs in this situation are constantly playing catch-up, and the strategy never delivers its full benefits. It is not uncommon for architects to be considered people out of touch with reality, as business teams often are. Developers are often not convinced that documentation is necessary. EA plays a critical role in achieving both short- and long-term business goals, so technology executives must continually promote its strategic importance. Furthermore, ensuring that documentation is operationally accountable is key.

Operationalizing the EA strategy

As a company grows, its EA strategy must translate business vision and strategy into effective business changes. To achieve this goal, we need to develop, communicate, and improve the primary requirements and the strategies that are set out for the enterprise’s evolution. During the process of strategic planning, an organization defines its strategy, or direction, and then decides how to allocate capital and people to pursue that strategy. In order to accomplish goals, EA planning must be linked to strategic planning. Without strategic planning, neither will be successful. By using roadmaps, business architecture strategies address any barriers that are in the way of achieving the desired state. To implement any transformational change at any level of your organization, you need an EA strategy and business architecture strategy.

Exemplifying lean-agile architecture

Business needs and opportunities require architecture to evolve. The technology-centric approach to business execution otherwise becomes a bottleneck. As a result of changing business strategies, modified strategic themes are translated into new solutions and value streams. This process is supported by EAs who provide input and set expectations on technical feasibility. Architects collaborate with solution and systems architects to meet the new business goals once the new direction is decided. The updated strategy outlines how vision, intent, and roadmaps are changed. Additionally, EAs ensure that solutions and values streams align across the portfolio. Their role is to provide long-term guidance for the development of the portfolio solutions set’s technologies and platforms. To ensure that the large shifts in technology remain aligned with business strategy, they often function as epic owners for portfolio-level enablers.

An agile architecture supports cooperative, active design and evolution of a system with a set of practices, values, and collaborations. As a result of this approach, a system’s architecture can evolve continuously over time while meeting current requirements, embracing the DevOps mindset. Phase-gate processes and BUFD avoid the overhead, delays, and large-scale redesign associated with start-stop-start methodologies. In agile architecture, the design process is collaborative, emergent, and intentional, and design is streamlined. Design for testability, deployability, and release ability is an integral part of agile architecture, much like agile development practices. Decentralized innovation, rapid prototyping, and domain modeling accompany this principle.

Architecture influences the organization’s ability to meet its objectives through frequent, independent releases. The architecture is optimized to enable a seamless end-to-end value stream by agile architects. Consequently, the company can continuously deliver value within the shortest possible time frame. The agile architect is motivated to ensure that the architectural runway is just enough to support a growing business. Legacy modernization initiatives are continually developed and know where to refactor to get rid of bottlenecks. Business requirements are clearly communicated through these initiatives.

Balance intentionality and emergence

Early architecture was heavily influenced by traditional architectural approaches. As a result, there was a significant amount of documentation and unsubstantiated decisions. In order to design architecture that is aligned with the business needs, architecture is created as developers experiment with the system. A balanced approach to agile architecture is as follows.

Intentional architecture

The architect defines the strategy and initiatives that are to be implemented in a planned, purposeful manner. They are instrumental in optimizing performance, usability, and design. Also provided are guidelines for synchronizing team designs and implementations.

Emergent design

Contains all of the technical bases for an evolutionary and incremental implementation approach. As systems are built and deployed, designers and developers are able to respond to immediate user needs. Agile architecture addresses the complexity of building enterprise solutions with a lean-agile approach, combining these two approaches. As a result, the system meets both current and future user needs with ease. Combined, emergent design and intentionality build the architectural runway, enabling future business value to be created.

SAFe, for example, provides a scalable agile framework for applying lean and agile principles to large organizations. EA is an element in SAFe that fosters adaptive design and engineering practices, as well as driving programs to rally around shared visions. It is the EA’s job to provide technology standards, recommendations, and strategic guidance to ensure standardized development practices. In this manner, reworks can be avoided that may result from mismatches with company standards, and silos can be broken down.

A growing number of large organizations are embracing this framework, which integrates concepts such as an architectural runway, intentional architecture, and emergent design. The role of the EA will change to be able to communicate better with development teams. Further, we will look at how EA can adapt to these agile organizations.

SAFe and business architecture

A value stream is a method for satisfying customers that are incorporated into the business architecture. Organizations can create products that will generate value for customers based on a product-centric approach. As defined by SAFe, operational value streams are those that provide end-user value.

Identifying the required or missing business capabilities is determined by linking them to the stages of the value streams. A company’s EAs assess business capabilities based on their value to customers, their complexity, and their alignment with strategic goals. The alignment of agile development with strategic goals is also made possible by linking business capabilities to user stories.

SAFe and the architectural runway

Architectural runways are a key component of the SAFe framework. Program increments are measured in the SAFe framework over 8 to 12 weeks. A runway can be extended by utilizing enablers in order to support future business functionalities.

Implementing infrastructure, complying with regulations, and developing architecture are enablers. Ensuring that the business features developed for the next program increment land correctly is their responsibility. Thus, the term “runway” refers to the runway on which a plane lands. An EA creates enabler epics that contain information on the application architecture, infrastructure, and technology recommendations. We put them on a kanban board so that they will be implemented by the development teams.

Intentional architecture versus emergent design

As development moves quickly, agile teams must design the architecture that will help them achieve their goals, according to “the best architectures, requirements, and designs emerging from self-organizing teams.”

Emergent design is a result of spontaneous engineering solutions. Patterns, principles, and trade-offs shape the evolution of software. EAs, however, create intentional architectures. A high-level, plan-based architecture is intended to align cross-team roles. That is what a foundational enabler is. To follow the changes that occurred during the development process, the intentional architecture must be reconciled with the emergent design.

The evolving role of EAs – determining the best way to interact with development teams

EAs should be business partners who coordinate and integrate regulatory policies and regulatory constraints in agile environments. By collaborating closely with development teams, they build the architectural foundation for agile development. In addition to facilitating the adoption of agile practices, they determine when emergent or intentional design is most appropriate.

Evolution of the EA practice in agile environments – giving more power to local teams

The gap between the objectives of the management team and the objectives of the agile team, as described in the The five trademarks of agile organizations article by McKinsey, is the key to changing from a traditional top-down organization to an agile one.

Traditionally, managers enact what needs to be done by telling their employees what they are supposed to do. Customers must be delighted by agile organizations. In an iterative and self-organizing fashion, work is done by self-organized teams and customers are consulted directly. Transparency and continuous improvement are considered the most significant values. Under this new approach to EA, centralized management will give way to decentralized management, and local teams will have more control. Enterprise governance teams provide direction to the entire organization at the corporate level.

In addition to identifying enterprise governance objectives and regulatory constraints, the enterprise governance team assesses and plans future business capabilities. This is done in order to improve security and bring about economies of scale.

A successful agile architect should adopt these strategies and practices:

• Define the architectural vision: Architects work with business and strategic goals to define the architectural vision. Among the factors they consider are scope and budget, which determine the technical direction as well. A testable and adaptable architecture is designed that is appropriate for the enterprise.

Aiming for this requires architects to understand stakeholders’ goals and constraints, as well as their needs. Architects should be able to model and document architecture and designs while working closely with sprint teams.

• Choose the right technologies and tools: Agile enables the teams to select the right tools and technologies. In addition to assisting the team in utilizing them effectively, architects may offer guardrails, recommendations, principles, and constraints. Involving people in decisions and contributing when necessary is something the agile architect should do.
• Plan for change: It is fragile, not agile, to have an architecture incapable of handling change. Planning for change, managing change effectively, and understanding the associated costs are the characteristics of an agile architect.

It is not advisable for architects to be defensive of their ideas. They should embrace change and be open to feedback. A designer should, however, consider the impact and cost of a change before accepting it. If necessary, they should propose alternative solutions.

• Socialize, collaborate, and motivate: Building relationships with team members is imperative for the agile architect. Agile architects need to be social to be successful. Agile architects, therefore, need to be able to communicate and collaborate within and across teams. In order to understand stakeholders’ expectations, requirements, and constraints, the agile architect must communicate with them. Every member of the team needs to be aware of the architecture so that it can be communicated. Having the ability to gain respect and trust from the team members is essential for the success of the agile architect. Collaboration and shared knowledge are crucial to the success of an agile team.

You do not have to be a problem solver to be an agile architect. The agile architect should mentor, guide, and motivate people so that they can solve problems on their own rather than having the problem solved for them. The architect should collaborate with the team on design decisions. By working together with the team on the product backlog, design ideas will evolve.

• Lead from the front: When it comes to selecting tools and technologies, agile architects should serve as evangelists, influencing the team, communicating the design and architecture to the team, and taking the lead when it comes to providing direction to the team. The agile approach deals with uncertainty, change, stakeholder interaction, and risk management issues much more than the traditional waterfall model. Often, they play a number of roles, but they are most crucial to the team’s ability to work agilely.

An architect creating architecture and design specifications has no place in the ivory tower. The architect should be involved in the agile process closely, understand the goals, requirements, and constraints of the team, and lead from the front. As an agile architect, you should be capable of delivering value to the business, maximizing stakeholder value, and managing change and complexity.

Architecting for DevOps and release on demand

In the context of continuous deployment, development and operations are becoming attractive approaches to software development. Both teams are more closely connected with each other through this approach. Putting new releases into production quickly is what CD is defined as. With DevOps/CD, architects face new challenges that impact both their design decisions and their responsibilities within their organizations. DevOps and CD adoption can have profound effects on architectural decision-making processes and their outcomes. In order to understand how this can be done, it is important to conduct sufficient research.

According to the request of customers, release on demand deploys new functionality into production and releases it without delay or in increments to them. Release on demand is supported by three primary aspects that ensure that new functionality is continuously prepared and validated in production. For an enterprise to realize the real benefits of agility, it’s imperative to release the right value at the right time, when end users are operating the solution in their environment. The timing and nature of product releases are essential economic drivers that should be carefully considered. The goal of CD is to release new functionality as soon as it is developed, allowing users to exploit new capabilities right away. The actual release tends to be decoupled and on demand, occurring for particular users at specific times, when they need it or when it makes sense for the company.

A customer-centric approach is applied when determining which elements of the system to release and which end users to reach out to. Releases should be based on market rhythms and events and aligned with customer time frames. Moreover, specific customer segments should be targeted with new features or the entire system when releasing release elements.

By decoupling releases, business agility is further enhanced, especially for value streams that serve external customers. Promotional activities can be targeted at specific segments of the market. Also, the timing of the solution and the functionality of the sale can be structured with greater confidence.

The four activities of release on demand include the following:

• The release refers to the processes involved in delivering the solution to end users, either all at once or in incremental steps
• Stabilize and operate solutions describe the steps to ensure that both the functional and non-functional aspects of the project are working correctly
• Measurement is the process to determine whether newly released functionality fulfills the intended purpose
• As part of the CD pipeline, this learning module describes the steps involved in deciding what actions to take with the information collected

It is now time to open up the solution to customers once it has been put into production and has been verified as operable. The timing of the release of value is critical, as releasing too early or too late at the wrong time can have negative economic consequences. We will further explore this aspect by digging deeper into the release value to customers approach.

Release value to customers

The product management process includes policies for governing the execution of the product development process. These policies range from automatically releasing qualified code to customers to establishing a more formal review process. If the system is complex, there is a greater likelihood that a manual gate determines the answers to the previous questions (who, when, and what should be released). The release can be accomplished through the following four practices:

• Dark launches enable deployments to production environments without providing end users with the functionality
• In order to facilitate dark launches, developers have implemented feature toggles, which allow switching between old and new functionality in code
• Canary releases allow the solution to be released to a specific customer segment and measured before it is further expanded and released to more customers
• A decoupled release element is one in which the release elements have each been identified separately so that separate releases can be carried out independently

For applications to function properly, development, as well as operations, are essential. During deployment, software components or frameworks are designed, developed, and tested.

Operating a software company includes administrative tasks, services, and support. DevOps architecture can reduce the time between deployment and operation terms by combining both development and operations. This will improve the delivery of software.

Architecture for DevOps

While DevOps is viewed as a framework for building computing systems, it is not an architecture reference in modern computing. Rather than a specific technique or methodology, DevOps is a philosophy that focuses on teamwork, communication, and constantly improving the software. It will ultimately lead to producing better software as efficiently and quickly as possible. DevOps encourages an entire organization to participate in improving their software applications routinely and incrementally.

Agile is also influenced by DevOps. However, the newly developed approach is an improvement over both agile and waterfall development. This is because it requires developers to complete entire projects before handing them over to operations for testing in production. There used to be silos between developers and operations specialists. In order to run the code in production, developers write them while operators run the code as system administrators. Even so, due to breakdowns in communication and inadequate collaboration, things that are supposed to be easy can turn out to be challenging – the communication of customer requests to developers and the provision of clean code to operational personnel, for example.

Build

The total cost of the resources used to fulfill the operations was calculated based on estimates for fixed hardware allocation when DevOps was not utilized. Individual usage requirements were defined in the business strategy to make things flow smoothly. A key feature of DevOps is the use of the cloud as well as the sharing of resources. Builds can be controlled by users to ensure resources are utilized appropriately.

Code

The use of Git and many other good practices allows the code to be reused. It helps write code that meets the needs of businesses, tracks changes, and informs about the reasons regarding the differences between what is actually happening and what is expected to happen. In case of an emergency, the code can be reverted to its original state. Files, folders, and so on can be arranged appropriately to safeguard the code. Reusing them is also possible.

Test

Testing will be complete before the application moves into production. It takes more time to test manually and move code from the input to the output when using manual testing. Automated testing speeds up the deployment process because automating the scripts will remove many manual steps before the code is deployed to production. The time required to test the code will be reduced, and in turn, deployment time will be reduced as well.

Plan

Agile development is an important component of DevOps. It is easier to plan accordingly, as the development and operations teams are in sync, and thus productivity is increased.

Monitor

Any potential failure is identified by continuous monitoring. Further, it assists in tracking the application throughout so that the application is up to date with and in sync with the modern upgrades. Monitoring log data becomes easier with services such as Splunk, where multiple third-party tools enable monitoring.

Deploy

Automated deployment can be achieved by many systems through the scheduler. Cloud management platforms allow users to capture accurate insights and analyze trends through dashboards. They allow them to see the optimization scenario and trend analysis.

Operate

In contrast to traditional approaches, DevOps integrates developing and testing in one workflow. Team members actively participate throughout the entire life cycle of services in a collaborative way. As a result of the collaboration between development and operations teams, a monitoring plan that serves both business and IT requirements is created.

Release

It is possible to automate the deployment of a program to an environment. However, when deployments are made to the production environment, they are manually triggered. In an effort to minimize customer impact, there are a number of processes of release management that frequently use manual deployment for deployment in the production environment.

A DevOps approach tests software updates rigorously before they are released to users, using the appropriate people and tools. This is possible because of several DevOps principles. Cloud-hosted and large distributed applications are developed using DevOps architecture. Using agile development allows integration and delivery to be seamlessly combined as part of the DevOps architecture. Developing, testing, and deploying a product takes longer when development and operations work independently. In the event that the terms of the deal are not compatible, this may affect the delivery schedule. Therefore, DevOps streamlines the development process and allows teams to improve their productivity.

Applying SAFe to EA and the cloud

A business architecture lays out how a company will function. In a similar way to an IT architect, who determines how systems, data, integrations, and resources should be utilized to support an IT organization, business architecture defines what the organization does as well as how the business provides value, what information is needed to conduct business, and what organizations are involved. You will also find information about how the business does its work.

Enterprises can embark on a transformation of their people, processes, and technology by implementing a scaled agile framework (SAFe: https://scaledagileframework.com/) across the entire enterprise, going all-in with Amazon Web Services (AWS ) (https://press.aboutamazon.com/news-releases/news-release-details/cox-automotive-goes-all-aws), and evolving to a you build it, you run it environment. Companies can build out small teams that use scrum, kanban, or other agile methodologies, and teams can be typically 8–10 people in size to drive ownership and autonomy, very similar to Amazon’s two-pizza teams. Implementing a coordinated delivery, operations, and technology strategy allows companies to unify IT and the business by creating a team of product, engineering, architecture, and business leaders at the upper levels of SAFe, resulting in a more transparent and collaborative environment. This model provides connectivity of priorities and gives teams the context as they look to solve customer problems.

Aligning architecture with business value

Technology is an essential part of supplying value to customers in the digital age. Whenever business strategies change, the systems, applications, and technology that deliver those strategies must also adapt. Those who support applications and systems are responsible for any changes to the customer experience. It is the architects’ responsibility to ensure those systems are able to achieve current and future business goals in close coordination with business owners and product managers. A portfolio vision, a portfolio canvas, and a strategic theme guide the architecture of the company. Technical investments are set into a portfolio by these constraints, which provide direction, along with an overall context.

In addition to a narrow focus on architecture, EAs should also consider the larger enterprise strategy. Essentially, an end-to-end value stream comprises all the activities that lead to the creation of a result for a client, be it the ultimate customer or an internal customer. It is crucial to identify the stakeholders who trigger and participate in the business architecture value stream. Additional incremental items that accrue as part of the path to reaching the value proposition are also included. Essentially, it illustrates the value sought and received – or, to put it another way, the purpose for which a customer deals with a company.

The operational value stream, as illustrated by the SAFe framework, explains how goods and services are provided to customers. The operational value stream contains the people and systems that did the work, in addition to the systems, flow of information, and material that delivered value to the customer.

In general, value streams align well with business architecture in SAFe. While there are a few semantic differences between the concepts of capability within the business architecture and SAFe, more consideration is necessary. Although SAFe and business architecture concepts may not be misaligned, the specific language used by the two frameworks requires practitioners of both to consider their shared vocabulary with care, especially when harnessing the power of both tools.

Developing solution vision, solution intent, and roadmaps

Using SAFe’s solution intent, you can store, manage, and communicate information about the current and intended behaviors of your solutions. It provides a simple but elegant way to capture knowledge. Also, it offers a basic understanding of current and evolving requirements, designs, and intentions. This generally indicates that the solution’s primary purpose has been satisfied. Business goals are more likely to be achieved when architecture is aligned with business strategy. By translating strategy into solutions, architects help businesses meet their objectives. Solution vision, context, and intent are the three characteristics of those solutions.

Solution intent is embedded storage of knowledge, providing a single point of truth for all content relevant to the architecture of the system, including requirements, design, structure, behavior, and other architectural concerns. The intent of the solution includes all the decisions, patterns, models, and other technical information required to meet minimal requirements. In addition to system constraints, the solution intent captures Non-Functional Requirements (NFRs). To ensure quality and compliance, NFRs are regularly tested via automated tests, just like all other requirements. In addition, a roadmap outlines the steps in the implementation of the project. Architects and teams explore technical options while building the architecture runway by collaboratively defining enablers in the roadmap. They provide insight into what they can achieve early in the process. Intentionality and emergence are balanced as teams implement features over the top of the architecture. Each ART is defined by its backlog, which consists of all the work to be done. Product managers and architects work together to prioritize and balance new features with technical work. In addition to predicting technical debt issues, they prioritize architectural runway needs.

Ultimately, the solution roadmap determines the backlog items to be executed and the solution intent. Solution vision defines the purpose and key capabilities of a solution, as well as its non-functional requirements. As teams create backlogs and plan their work using this knowledge and the emerging roadmap, they establish critical milestones and releases.

Preparing architecture for PI planning

The Program Increment (PI) planning sessions are regularly scheduled meetings that take place throughout the year. A shared vision and roadmap are discussed, and cross-team dependencies are identified for the ART.

PI planning includes the following essential elements:

• You will be required to attend two full-day events every 8 to 12 weeks (depending on how long your increments are)
• Prioritizing the planned features in advance is the role of the product manager
• Development teams are in charge of developing user stories and estimating their length
• User Experience (UX) and engineering teams validate the planning by testing it in the target environment
• It’s all about aligning the teams with each other and the mission
• All team members should attend in person if possible
• Remote participation can be made possible through technology if required

We can never revert to the way we worked before COVID-19. It used to be standard practice to conduct PI planning in person. However, it is now evident that it may not always be feasible to group teams together. It is imperative to make sure that the teams who are doing the work are present during planning, instead of being in the same room. It is, therefore, more critical for teams to be able to plan in real time rather than face to face. PI planning may need to be adjusted in some ways: the schedule, the timing, and, of course, the technological support that is required to support this ceremony. SAFe users who are newly introduced to it should almost certainly begin by implementing PI planning. Due to its foundation, the Scaled Agile Framework (SAFe) is built upon it.

Teams develop features and enablers as part of each increment. This list of near-term work items is defined and prioritized by architects in collaboration with product management. Through their in-depth data, current features are able to be outlined and sized and their acceptance criteria defined. In addition to the current features, enablers are defined in the backlog for these future features to be explored and gives knowledge, which will ensure their viability. Technical dependencies outside an ART are also taken into account by architects, whether from a solution train or the enterprise, helping to coordinate these activities.

By collaborating with teams during PI planning, it helps reduce the number of discoveries and ensure teams are able to make effective decisions. The process of PI planning can greatly improve the efficiency of large, agile organizations. It is worthwhile to examine some numbers in order to better comprehend the implications. Depending on the size of an organization, there may be between 200 and 300 development teams. Prior to the change in work style, these teams would not have ever spoken to each other (until a critical problem forced them to share information). At first, the alignment would be at the leadership level, and then the information would be passed down by multiple levels of managers, but the team members would not communicate with one another. A constant competition would take place for the best resources, budgets, and opportunities. During this time, there have been a number of projects that clashed – one team would release something, but it would break something in another team. Most of these big businesses have never gathered their teams together to talk to one another on a call or in person before PI planning. In addition to the chance to discuss what’s being done, they get a chance to discuss who is working on what. This might be important in a number of situations or circumstances:

• It is extremely crucial to consider how your changes will affect other teams when you touch a system or code repository
• If you need to work on another team’s feature first or the other way round, you might have to do some work to facilitate their work

Planning PI enables you to have effective communication among and across the teams. It puts you in a better position to see the bigger picture and has visibility across the board regarding a project or a task. Collaboration comes with the package as well. This allows teams to accomplish tasks more efficiently, deliver more features within less time, and stay within budget.

Coordinating architecture through PI planning

A plan for the next increment is created by the teams during PI planning. As part of the planning agenda, the teams present the architectural briefing. While teams develop their plans during breakout sessions, architects manage the room to make sure the technical work is being planned properly. In addition, they make sure that the enabler work is being accounted for. Any questions or concerns can then be addressed. Architectural and technical issues regarding potential modifications are addressed by architects during the management review. Also, they participate in assigning value to PI objectives together with business owners. Those who support the use of enablers explain, in business terms, how they support the overall goals of their organizations and champion their importance.

Supporting CD through PI execution

A developer’s responsibility for enablers is to own the technology and exploration work related to the essential and solution levels, and, as a result, guide the development progress of teams. Attending the sprint planning sessions and/or sprint demos of those teams will allow them to monitor progress, address issues, and adjust directions as needed. In addition, they provide coaching and mentoring to the teams, and respond to problems and issues as quickly as possible so that the architecture doesn’t become a bottleneck. At the end of each iteration, architects ensure that enabler work includes the latest learning, runway additions, and any enhancements to the CD pipeline. Architect Sync is used for large-scale solutions to ensure alignment and progress sharing among architects.

Supporting new strategic themes and value streams

Business requirements and opportunities demand that architecture evolves. The alternative is that technology becomes an obstacle to business success. Changing business strategies results in new or redesigned strategies that are applied to the portfolio canvas and result in original or modified solutions or value streams. Business architects assist and influence this process through their input, participation in Value Stream Mapping workshops, and by setting expectations regarding technical feasibility.

Architects of systems and solutions collaborate with EAs to realize the new business direction once it is determined. They communicate how their new strategy changes the vision of the solution, its functionality, and its roadmap. In addition, EAs coordinate architecture activity across multiple business units to ensure alignment between products and processes. Technical consultants may also advise on the non-functional requirements (security, compliance, performance, and so on) of portfolio solutions in addition to provide technical guidance for the long-term evolution of technologies and platforms. In their role as enablers, these workers ensure major technological shifts are aligned with business strategy.

Leading the lean-agile transformation

The development community often respects and holds architects in high regard due to their knowledge and experience. Thus, architects play an instrumental role in any SAFe implementation. Lean-agile architects have the role of leading by example, coaching, and encouraging developers to adopt leaner ways of thinking and operating. As a result, the development community is able to expand its knowledge base and skill set due to autonomy and mastery. By becoming SAFe architects, organizations can learn how to work in a lean-agile environment, participate in developing the organization’s roadmap that has been implemented, and accelerate adoption.

Summary

SAFe is among the scaled agile frameworks discussed in this chapter. These frameworks help large enterprises implement the principles of lean and agile. According to SAFe, EA fosters adaptability and engineering practices, and improves program and team coordination. EAs are instrumental in assisting developer teams to work according to standardized standards, providing strategic guidance, reference architectures, and technology standards. Rework may be avoided if the standards of the company are aligned. This also breaks down silos in the organization.

Moreover, adapting computing resources to a company’s business needs is an important part of EA. It is essential to align the strategic goals of the company with its existing business processes, the information generated, and the supporting infrastructure to make this successful. Organizations achieve their objectives through frequent releases that are independent of one another. Agile architects use a customized architecture to enable seamless end-to-end value streams.

The next chapter is about cloud migration, where we will explore the journey from start to end. We will also focus on whether it is the right choice for your business needs or not and how adopting agile or SAFe helps in a cloud transformation.