Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reality checking agile's architectural inner workings


Published on

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.

Published in: Technology
  • Be the first to comment

Reality checking agile's architectural inner workings

  1. 1. • Cognizant 20-20 InsightsReality Checking Agile’s 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 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
  2. 2. 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 OverviewFigure 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 single iteration. Neither should organizations get• Identify major flows: Draw the major flows lost 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 in on which teams can base their architecture and validating the approach. 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, 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 and architectural counseling as and when he/she cognizant 20-20 insights 2
  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 architect ments 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 the about 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 consider The 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 large systems 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 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- opment is based on a moving target. But that • Let it give you enough confidence to move 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 FeedbackFigure 2 cognizant 20-20 insights 3
  4. 4. • 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- ment team.• It grounds you in reality and gives you the 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 theAgile is, and has always been, driven by moving architecture.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 updates. to the greater need to set the foundation of a project.About the AuthorArijit Sarbagna is a Senior Manager of Projects within Cognizant’s 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 CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 156,700 employees as of December 31, 2012, Cognizant is a member ofthe NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: Email: Email:©­­ Copyright 2013, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.