Reality Checking Agile's Architectural Inner Workings
Total Page：16
File Type：pdf, Size：1020Kb
• Cognizant 20-20 Insights Reality Checking Agile’s Architectural Inner Workings By demystifying Agile constructs, and how architects fit into the development process, organizations can find and follow best practices and deliver benefits that advance accelerated coding objectives and meet strategic business needs. Executive Summary team members. Ultimately, it is up to the team to figure out how much to architect up front — Although Agile has been around since 2001, by applying their collective wisdom. However, some organizations still find the concept of “Agile in general, the idea is to not spend much time architecture” confusing. On one hand, they hear designing and implementing various moving “don’t do up-front design” — but this is often parts — hinged-to layers and tiers, with interde- counteracted by the fact that if an organization pendencies or responsibilities and cross-cutting does not design early, it will face major challenges concerns. Rather, it makes more sense to simply in proceeding with software visioning and/or build the minimal amount of code needed to framework development. connect all of the basic pieces (some of which may Agile philosophy warns organizations to not still be in the conceptual state) and start building attempt “big design up front” because doing so the actual functionality on top — thus providing an may result in teams scrapping a major chunk of early end-to-end experience of the results. hard work if the business decides to change its So the focus is more on the API level of the infra- approach. Such a change can arise from any one structure and not the actual implementation of numerous reasons: changed market require- — which is usually mocked up for the first few ments, staying ahead of the competition, etc. And Sprints. And as iterations progress, the actual this dilemma forces Agile advocates to ponder, implementation is incrementally completed, as how much architecture is just right in Agile? guided by the need of the other functional parts Although there may be no absolute answer to this of the application. quandary, this paper will explore how an Agile team can find the best balance of up-front archi- Here is a guideline on getting started with an tecture work. Agile architecture, distilled to seven simple steps: Assessing Architecture Requirements • Identify business objectives: Focus on under- Honestly, there is no single, fixed answer to the standing “why” the business wants to build this, question of how much architecture is just enough. rather than “what” the business is planning. The answer depends on the project’s context and cognizant 20-20 insights | february 2013 Agile Architecture: A Sequential Process for Getting Started Identify Business Objectives Inspect Establish and Architecture Improve Objectives Create Candidate Identify Architectural Major Solutions Flows Identify Design Draw an Coupling Application Points Overview Figure 1 • Establish architecture objectives: Identify knowledge to course-correct the architecture. technical challenges, understand/identify the So, architecture is a team effort. Also, instead of technology stack, define major hardware/ prescribing a specific approach, Agile architec- software requirements, agree on design ture offers flexible solutions, thereby providing patterns, identify component/service reuse, options in case one approach no longer serves create high-level diagrams and define quality/ the business’s altered needs. And in this process, security/performance attributes. we don’t have to design our architecture over a • Identify major flows: Draw the major flows single iteration. Neither should organizations get — those that impact business operation, lost in the details. They should start by setting key scenarios/use cases, etc. — that help in their focus on the big steps and build a framework validating the approach. on which teams can base their architecture and design requirements on a preexisting foundation. • Draw an application overview (using a simple wireframe/screen mock-up/prototype): As a Architecture Responsibilities team, use the white board to draw the appli- Spelled Out cation overview, communications behavior, Agile is all about team, with everyone on the team dependencies and layers/tiers. responsible for architecture. But there are two key • Identify design coupling points: While driving drawbacks: People may have different opinions, the design, you need to carefully identify the and the approach may not scale (especially when couplings so enough room remains for future we have a large, distributed team). realigning. The solution is clear: Identify an architecture Create architectural candidate solutions: • owner. Come to an agreement as a team and extract an architectural candidate solution. Make it Agile Architects transparent and open for criticism, and then Now the question for organizations is how to fine-tune it further based on feedback. identify an architect owner. Should it be the tra- • Inspect and improve: Once your candidate ditional lead architect, or someone new to the is ready, start rolling the development and world of Agile development? continue improving it as you progress. Well, anyone who is experienced enough, skilled Organizations need to understand that Agile enough to drive the architecture and is sensible development starts even before the outcome is enough to understand business needs could be fully understood or envisioned. Design and devel- this person. However, be advised: This is indeed opment approaches are adjusted as development a challenging role. The product owner will require progresses, and teams use empirical data and architectural counseling as and when he/she cognizant 20-20 insights 2 creates a new vision. Developers are usually on • Part of the up-front effort are initial require- their toes and may even glance at the architect ments and architecture envisioning so that with a heinous look. During Sprint planning, teams are able to answer critical questions the team will need its architects to define the about the scope, cost, schedule and technical technology boundary of the work-items. The strategy of their projects. organization will expect architects not only to provide system architecture, but also to consider The question then becomes whether to engage in the big picture of enterprise architecture. up-front design or not. Ironically, if the organization looks at traditional Big Up-Front Designing vs. None architects moving into the Agile sphere, there Big up-front designing (BUFD) is on one extreme, is a palpable sense of resistance in the air. This whereas no up-front designing (NUFD) is the resistance is attributed to the widespread myths other pole. Agile architecture, however, is about of Agile architecture and its associated roles. some short small up-front design (SSSUFD). Keep These include: in mind: • Sprint 0 is the time for a detailed architectural • Agile architecture is not a blueprint. spec. • Agile architecture is about what changes you • Agile methods are architecturally weak, dis- can ignore. connected from the realities of delivering large Agile architecture is about impactful choices systems in complex enterprise environments. • up front that will make later choices easy. Agile discourages “up-front” designing. • • Agile architecture is subject to change. However, the facts suggest: • Agile architecture is about stable ground, but not frozen (static) ground. • During “Sprint 0,” teams need to get their project organized and moving in the right So, how much rough up-front design (RUFD) is direction. But they don’t need a detailed spec enough? per se. • It depends. Agile encourages waste reduction, as devel- • Let it give you enough confidence to move opment is based on a moving target. But that • forward, but don’t rush. doesn’t mean Agile is architecturally weak. Rather, it helps us to be more aligned to • It can take as long as two Sprints and be as realities and helps drive success by delivering short as ’’about a week.’’ complex enterprise projects. Articulating Agile Architecture Envision Initial Architecture Communicate/Articulate Feedback Update Architecture Components Work on It/Use It Feedback Figure 2 cognizant 20-20 insights 3 • Deliver your architecture as code, as abstract • However, the work evolves to reflect greater base classes and some ’’base-lined’’ documents. understanding and knowledge of the develop- • It grounds you in reality and gives you the ment team. platform to take off and implement the user In addition, the following best practices should stories as you go forward. be followed once the foundational thinking is in • Spike it (i.e., create a technical debt item and place: drive it). • Think about the future, but don’t overbuild the Agile is, and has always been, driven by moving architecture. targets (i.e., changing/evolving needs). Its archi- Be open about your architecture — encourage tecture, however, has never wavered. • criticism, and allow your architecture to evolve. Evolving Architecture • Use spikes; validate your model through imple- Some thoughts to consider as your organization mentation. ponders Agile architecture: • Travel light — do not create a five-page document when a diagram will do. • Architecture emerges over time, incrementally. Allow requirements to drive your architecture Organizations need to work faster at first, due • • updates. to the greater need to set the foundation of a project. About the Author Arijit Sarbagna is a Senior Manager of Projects within Cognizant’s Advanced Solutions