Embracing Agile Practices(Part-1): The Significance of Agility in Enterprise Architecture

Industry, in general, is an agreement that agile is no more a fringe movement. It is now a mainstream methodology applied to software development and beyond, although it started its life inside start-ups and small development shops. In the last decade and a half, agile has seen increasing adoption within even the largest of enterprises.

Let’s discuss old traditions, their problems, and how agility helps to uplift the enterprise architecture.

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.

Traditional Process/Problem

During initial discussions of the project, the senior manager in the project portfolios discussed the traditional delivery model for the enterprise. According to them, following this model would involve going through different sequential phases.

The business case phase, where the business owner collaborates with business analysts and enterprise solutions architects to create documents describing the mission, impacts, benefits, risks, dependencies, and high-level architecture roadmaps for the proposed solution. Additionally, an execution plan is developed by the enterprise projects and program management office, outlining the project’s schedule, milestones, resource requirements, and funding needs.

These documents are reviewed and approved by various stakeholders, and the process can take three to six months.

The analysis and design phase, Once funding is granted, the program enters the analysis and design phase, followed by the implementation phase and subsequent phases. Detailed requirements are gathered during the analysis and design phase, and a more fine-grained project plan called is created with a 10%-20% buffer/variance allowance.

The program then undergoes a sign-off and approval process before being handed over to the development team.

and so on, which means that the flow is going through the waterfall model until the final go live.

Although the ideal timeline for business outcomes from these initiatives is approximately 12/18/24 months, some executives are concerned that past experiences have shown projects often don’t go as planned. They are eager to develop an internal capability to reliably deliver enterprise-scale projects successfully and on time.

Case Study

Let’s examine the imaginary case of Consumer Banking Corporation (CBC), a bank with ambitious plans to enhance customer-centricity. CBC recognized the need to revamp all customer touchpoints to achieve this goal. Additionally, they acknowledged that the existing back-end processes and systems were complex and inefficient due to historical tactical planning and short-term thinking. Streamlining and consolidating these back-end operations were crucial to ensure a delightful customer experience. The bank approached these strategic initiatives with great enthusiasm, understanding their significance in driving future growth and success in the industry. Alongside modernizing customer touchpoints, CBC aimed to improve its back-end processes and systems for seamless customer interactions with;

1. Online channel.
2. Mobile banking channel.
3. Telephone banking.
4. Network of branches.

The bank launched several concurrent projects to streamline its application and process landscape, while also establishing an API gateway for front-end systems. These initiatives began with great enthusiasm and optimism, involving a large and talented team of developers, testers, systems engineers, software designers, user experience designers, enterprise and technical architects, project managers, change managers, and more. The bank’s primary focus was to delight customers by introducing groundbreaking research and innovative user interface designs and interaction patterns. A significant amount of remarkable work was accomplished during this period, with a considerable number of individuals actively engaged in the program.
The team followed an agile software development approach, and they had continuous integration in place. Developers checked in code several times during the day, and those were automated. However, at a high level, budgeting, planning, schedules, requirement analysis, architecture, and design, and the downstream deployment processes still followed a heavily stage-gated process.
The bank did not have in place an enterprise architecture practice prior to initiating these large programs of work, but it formed such a group to spearhead the overall strategic architecture alignment of these initiatives. They tailored the stage-based approach such as the waterfall method to the needs of the bank. The tailored framework resembled a phase-gate-based method, and it moved work from one stage to the other with each successive stage focusing on various aspects of the architecture.

The phases that conclude for architecture and designs:

Mission and Strategy:

• Focus on defining the bank’s mission and strategic objectives.
• Identify business objectives, capabilities, and current value streams.
• Develop a logical sequence of stages for the transition to the desired future state.

Applications and Data Architecture:

• Design application and data architecture to support strategic objectives.
• Incorporate feedback and perspectives from stakeholders like executive managers, implementers, change managers, and the operations team.

IT/Infrastructure Architecture:

• Develop IT /Infrastructure architecture aligned with business needs and strategies.
• Build upon previous phases to add more details and viewpoints.

Architecture Blueprint and Enterprise Initiatives:

• Create the architecture blueprint describing various viewpoints for stakeholders.
• Map architecture blueprint to enterprise initiatives and solution architectures.

High-Level Architectures and Governance:

• Deliver high-level architectures to implementation teams.
• Establish enterprise architecture governance to handle deviations from planned architecture.

The architecture team delivered high-level architectures to implementation teams and left it to them to deliver the solutions. The enterprise architecture function was overall governance of the architecture and was responsible for making change decisions with regard to deviations requested from implementation teams from the originally planned enterprise architecture.

Output:

The outputs they had at the end of the project expected period were large inventories of documents of various assortments describing architecture requirements, user experience wireframes, development and test plans, test scripts, schedules, and a adhoc of working, but unintegrated code base.

Subsequently, the project board had to make a crucial decision to abruptly halt the entire program of work. They recognized the urgent need to reconsider their priorities and restructure their strategy. The bank was facing significant financial losses as the program encountered numerous bugs, integration issues, and the inability to launch the product as originally planned, leading to a lack of revenue generation.

Why?

Despite the team’s efforts to work in an agile manner and complete the assigned project according to architectural designs and business requirement documentation, there were inconsistencies in the process. The lengthy time required to create these documents and the size of the solution made it challenging to handle in a single iteration. As a result, development teams faced unaddressed architectural limitations. The absence of enterprise architecture governance iterations after the initial stages contributed to these issues.

Recommendations

Highlights of recommendations for resolving the problems:

1. Create software and IT delivery value streams aligned to real business outcomes.
2. Package work into small increments of business value in short batches, delivering continuously based on business priorities.
3. Focus on a single source system and its stakeholders instead of trying to cater to multiple stakeholders across various source systems.
4. Take a minimal and iterative approach, starting with an MVP and adding features gradually.
5. Begin with one small team aligned to a single value stream targeting the easiest and least complex business outcome.
6. Use a Pull model, prioritizing and validating business demand and value before building features.
7. Use cross-functional teams for each value stream, collaborating internally and engaging stakeholders as needed.
8. Take an experimental and hypothesis-driven approach due to uncertainties in the early stages of the program.

The delivery value streams will be facilitated through Architecture Development Sprints, agile, innovation-driven, and collaborative workshops.

Architecture Development Sprint(ADS)

In this, I will describe and illustrate with an example a pragmatic, agile process used in developing architectures for enterprise initiatives, with a strong focus on innovation and collaboration. This approach, known as Architecture Development Sprints, draws inspiration from a model originally utilized in the startup world, particularly from the book “Sprint, How to Solve Big Problems and Test New Ideas in Just Five Days” authored by Jake Knapp and others from Google Ventures. Over time, this method has gained popularity and is now increasingly being adopted by enterprises, with suitable adaptations to suit their specific environments.

image from the web

I will explain how innovative, lean, and agile architecture teams in large enterprises have adopted this method. Although the term “sprint” might evoke associations with Agile methodologies like Scrum, it’s important to note that the two concepts serve different purposes. However, they can complement each other effectively to streamline the overall concept-to-value streams within an enterprise. Let’s now briefly explore the Architecture Development Sprint method.

An Overview of Architecture Development Sprints (ADS)

A Typical Architecture Development Sprint (ADS) Overview:

• How: ADS is a time-boxed, collaborative series of workshops aimed at developing architectures in small batches through short iterations.
• Duration: Typically five days, but can be adjusted as needed.
• Objective: Optimize enterprise development and delivery value stream for continuous and incremental delivery of business value, with a strong focus on innovation.

image source: Sprint, How to Solve Big Problems and Test New Ideas in Just Five Days

• Stages:
  — Day One (Understanding Phase): Deep exploration of problem domains across various dimensions, including stakeholders, business opportunities, risks, technology capabilities, etc.
  — Day Two (Framing Phase): Individual and group exploration of problem frames and articulation of various perspectives and ideas for solving the problem.
  — Day Three (Synthesizing Phase): Narrowing down to a specific solution concept or alternative choices, considering desirability, feasibility, and viability criteria. Involvement of external stakeholders for validation.
  — Days Four and Five (Realizing Phase): Factor in feedback into the solution model, identify high-level job stories, and create a story map for incremental realization of the target state architecture and business outcomes.
  — Day Five: Creation of a minimal first iteration walking skeleton (potentially a throwaway proof of concept). Identification of next steps and clarification of specific areas through additional sprints if needed.
• Continuous Delivery: The objective is to rapidly and continuously deliver business value through iterations of ADS, Architecture Spikes, and development and delivery stages.
• Agility at Scale: Achieving agility at scale by delivering business value iteratively and incrementally.
• Lean Principles and Innovation: Weaving in lean principles and innovation into the development process to enhance efficiency and creativity.

ADS in action

Let’s discuss a realistic example of how an architecture development sprint can be facilitated. I will use the case study mentioned above from the CBC, I will walk through the sequence of activities that the team was involved in across all five days of the architecture development sprint.

Let’s begin by understanding the participants who take part in the sprint. The EA coach for the project portfolio can make the following recommendations or similar according to the organization structure for the roles that are meant to participate in the Architecture Development Sprint(ADS).

1. A business decision-maker who represents the business vision, strategic objectives, and other tactical needs and priorities of the business, and who can make decisions on behalf of the business.
2. A solution architect who is a hands-on architect representing the top-down architectural vision and the aspirational architectural roadmap for the payments domain to the team. He or she, through the ADS, will also help evolve an emergent architecture for the project by collaboratively working with other participants.
3. One or more customer or stakeholder spokespersons, who represent the voice of the customer, or stakeholder groups within the team.
4. A business analyst/Product Owner or Domain expert who focuses on the high-level process flows, the various business viewpoints that bring to light various business considerations, and constraints that need to be considered at a granular level.
5. A user experience specialist who contributes to the process from the perspective of offering the best and most streamlined user and stakeholder experiences.
6. An implementation specialist, typically a senior developer or DevOps professional represents the concerns and consideration of the development teams and other downstream teams that will deliver and operate the technology components of the solution.

In addition to these six roles, the Agile coach or the product owner him/herself assumes the role of a facilitator for the upcoming ADS sprint.

Now it is time to decide to go with the approach of vertically slicing the overall program along the lines of the business outcomes and designate each vertical slice as a delivery value stream.

As an example, let's take one business flow that is performing the payment processing of paper-based checks. Relatively, this can be east complex and had the lowest number of dependencies to or from other payment-processing workflows.

Conclusion:

The Architecture Development Sprint (ADS) emerges as a groundbreaking solution to the traditional architectural problems that have long plagued enterprises using the traditional Architecture Development Method (ADM). In the preceding article, We explored the challenges faced by organizations, such as prolonged development cycles, disconnected stakeholders, and an inability to adapt to evolving requirements. We introduced ADS as a transformative approach that leverages agile principles, hypothesis-driven development, and stakeholder collaboration to address these issues head-on.

By adopting ADS, organizations can break free from the constraints of the stage-gate approach, ensuring continuous feedback and validation throughout the architectural journey. This article has laid the foundation for our in-depth exploration of ADS, where we will delve into the specific activities, methodologies, and outcomes that make it an indispensable tool for fostering architectural excellence and success in the modern enterprise. Stay tuned for the next article, where We will dive deeper into the world of ADS and discover how it propels organizations toward innovation, adaptability, and business value.

Please refer next article here: https://dilankam.medium.com/embracing-agile-practices-part-2-architecture-design-sprint-151b886332d0

Resources:

1. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days — Jake Knapp

2. Becoming an Agile Software Architect: Strategies, practices, and patterns to help architects design continually evolving solutions — Rajesh R V