reality checking agile's architectural inner workings

Download Reality checking agile's architectural inner workings

Post on 20-Aug-2015




0 download

Embed Size (px)


  1. 1. Cognizant 20-20 InsightsReality Checking Agiles ArchitecturalInner WorkingsBy demystifying Agile constructs, and how architects fit into thedevelopment process, organizations can find and follow best practicesand deliver benefits that advance accelerated coding objectives andmeet strategic business needs.Executive Summaryteam 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 timearchitecture confusing. On one hand, they hear designing and implementing various movingdont 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-cuttingdoes not design early, it will face major challenges concerns. Rather, it makes more sense to simplyin proceeding with software visioning and/or build the minimal amount of code needed toframework development. connect all of the basic pieces (some of which mayAgile philosophy warns organizations to notstill be in the conceptual state) and start buildingattempt big design up front because doing so the actual functionality on top thus providing anmay 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 implementationof numerous reasons: changed market require- which is usually mocked up for the first fewments, staying ahead of the competition, etc. And Sprints. And as iterations progress, the actualthis dilemma forces Agile advocates to ponder, implementation is incrementally completed, ashow much architecture is just right in Agile? guided by the need of the other functional partsAlthough there may be no absolute answer to this of the application.quandary, this paper will explore how an Agileteam can find the best balance of up-front archi-Here is a guideline on getting started with antecture 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 thestanding 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 projects context andcognizant 20-20 insights | february 2013
  2. 2. Agile Architecture: A Sequential Process for Getting Started Identify BusinessObjectives Inspect Establish andArchitectureImproveObjectives Create Candidate IdentifyArchitectural Major SolutionsFlows IdentifyDesignDraw an CouplingApplicationPointsOverviewFigure 1 Establisharchitecture objectives: Identify knowledge to course-correct the architecture. technical challenges, understand/identify theSo, 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 businesss altered needs. And in this process, security/performance attributes. we dont have to design our architecture over asingle iteration. Neither should organizations get Identifymajor flows: Draw the major flowslost in the details. They should start by setting those that impact business operation,their focus on the big steps and build a framework key scenarios/use cases, etc. that help inon which teams can base their architecture and validating the requirements on a preexisting foundation. Draw an application overview (using a simple wireframe/screen mock-up/prototype): As aArchitecture 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 futurewe 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- Inspectand improve: Once your candidateditional lead architect, or someone new to the is ready, start rolling the development andworld of Agile development? continue improving it as you progress.Well, anyone who is experienced enough, skilledOrganizations need to understand that Agile enough to drive the architecture and is sensibledevelopment starts even before the outcome is enough to understand business needs could befully understood or envisioned. Design and devel- this person. However, be advised: This is indeedopment approaches are adjusted as development a challenging role. The product owner will requireprogresses, and teams use empirical data andarchitectural counseling as and when he/she cognizant 20-20 insights2
  3. 3. 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 architectments and architecture envisioning so thatwith a heinous look. During Sprint planning, teams are able to answer critical questionsthe team will need its architects to define theabout the scope, cost, schedule and technicaltechnology boundary of the work-items. The strategy of their projects.organization will expect architects not only toprovide system architecture, but also to considerThe question then becomes whether to engage inthe big picture of enterprise architecture.up-front design or not.Ironically, if the organization looks at traditional Big Up-Front Designing vs. Nonearchitects 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 theresistance is attributed to the widespread myths other pole. Agile architecture, however, is aboutof Agile architecture and its associated roles.some short small up-front design (SSSUFD). KeepThese 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 Agilemethods are architecturally weak, dis- can ignore.connected from the realities of delivering largesystems in complex enterprise environments. Agile architecture is about impactful choices 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 theirproject organized and moving in the rightSo, how much rough up-front design (RUFD) isdirection. But they dont need a detailed spec enough?per se. It depends. Agile encourages waste reduction, as devel-opment is based on a moving target. But that Let it giveyou enough confidence to move forward, but dont rush.doesnt mean Agile is architecturally weak.Rather, it helps us to be more aligned to It can take as long as two Sprints and be asrealities and helps drive success by deliveringshort as about a week.complex enterprise projects.Articulating Agile Architecture Envision InitialArchitecture Communicate/ArticulateFeedback Update ArchitectureComponentsWork on It/Use ItFeedbackFigure 2 cognizant 20-20 insights3
  4. 4. Deliver your architecture as code, as abstract However, the work evolves to reflect greaterbase classes and some base-lined documents.understanding and knowledge of the develop- ment team. Itgrounds you in reality and gives you theplatform to take off and implement the userIn addition, the following best practices shouldstories as you go forward. be followed once the foundational thinking is in Spike it (i.e., create a technical debt item andplace:drive it). Think about the future, but dont overbuild theAgile is, and has always been, driven by movingarchitecture.targets (i.e., changing/evolving needs). Its archi-tecture, however, has never wavered. Be open about your architecture encourage 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. Organizations need to work faster at first, due Allow requirements to drive your architecture the greater need to set the foundation of aproject.About the AuthorArijit Sarbagna is a Senior Manager of Projects within Cognizants Advanced Solutions Group. He spe-cializes in helping companies realize efficiency gains by adopting Agile principles and practices such asScrum (and Extreme Programming). Arijit started his technology career in 1998 as a software developer,a development lead/manager, a business development manager and a variety of other jobs beforesettling on his true calling, project and program management in Agile space. Arijit is also the localChapter Engagement Representative (CER) from PMI Agile Community of Practice (CoP) and representsthe West Bengal, India chapter. He can be reached at Arijit.Sarb


View more >