March/April 2005IEEE SOFTWARE - PDF document

March/April 2005IEEE SOFTWARE implications for the environment in which thearchitecture is to be deployed. We believe thatto dispel or reduce the ÒmagicÓÑlies in the ar- postmodern software design Jeff Tyree and Art Akerman, You can make orientation isnÕt the norm, many developersarenÕt familiar with component models andfor changes to the architectureÕs key aspects. Traditional ap-proaches donÕt clearly state the architectureÕs. Tradi-tional approaches tend to rely on modelstureÕs information. They donÕt focus onconsidered. Without these two key ele-. Traceability is chal-development lifecycle phase. The chal-quirements) to specific architectural ele-ments is unmanageable. We need a simplerway to ensure that the architecture meets. Tradi-tional approaches tend to rely on architec-WeÕve found it necessary to provide alter-To address these breakdowns, we believethat architecture decisions are the missinglink. If we elevate architecture decisions tosocialize them, they become an effective toolture. If an architect doesnÕt have time for any-as an effective tool for communication to cus-document all of them? We agree with RuthMalan and Dana Bredemeyer,who argue thatpossible, deferring the rest until later in thelifecycle. This lets the architect maintain a bal-technical organization. An architect absolutelysystemÕs key structural elements, their exter-nally visible properties, and their relation-To test a decisionÕs architectural signif-icance, an architect should ask the followingquestion: does this decision affect one or moresystem qualities (performance, availability,modifiability, security, and so on)? If so, an ar-ment it completely.cisions is critical because architects make themin complex environments and they involvetrade-offs. How many times have we looked atrified) by the decisions it was based upon? Ourfirst reaction is to ask several rhetorical ques-tions: ÒWhat were these people thinking? Hadthey never heard of sound principles of gooddesign? Did they think that the system wouldnÕtlive longer than a month?Ó Well, okay, maybecost and schedule constrained. However, look-inal system designers are long gone, we havehistory. All we can do is shake our heads in dis-IBMÕs e-Business Reference ArchitectureFramework, where architecture decisions are akey deliverable, has helped us learn how todocument these decisions.Table 1, derivedfrom the Rlists the essential information for each deci-WeÕve added two additional fields, re-IEEE SOFTWAREwww.computer.org/software in demystifying Generally, only two views of the decisionsexist. The architect provides the first, whichthe template above describes, to the technicaltechnical stakeholdersÕ interests. For example,. Wescheme (red, blue) to point out controversialor incomplete decisions. The architect pro-PowerPoint presentation. This view summa-Once the team reaches a final architecturaldecision, theyÕll need to ÒsocializeÓ the re-zation that theyÕve chosen appropriately. Thearchitecture decision template is useful be-cause it provides a common language for dis-decisionÕs status, rationale, and impacts. Inpractice, this has proven to be much morepowerful than reviewing, for example, compo-nent models. The team should socialize con-March/April 2005IEEE SOFTWARE IssueDescribe the architectural design issue youÕre addressing, leaving no questions about why youÕre addressing this issue now Following a minimalist approach, address and document only the issues that need addressing at various points in the life cycle. DecisionClearly state the architectureÕs directionÑthat is, the position youÕve selected. StatusThe decisionÕs status, such as pending, decided, or approved.GroupYou can use a simple groupingÑsuch as integration, presentation, data, and so onÑto help organize the set of decisions. Yocould also use a more sophisticated architecture ontology, such as John Kyaruzi and Jan van KatwijkÕs, which includes more abstract categories such as event, calendar, and location.For example, using this ontology, youÕd group decisions that deal with AssumptionsClearly describe the underlying assumptions in the environment in which youÕre making the decisionÑcost, schedule, technology, and so on. Note that environmental constraints (such as accepted technology standards, enterprise architecture, commonly em- ployed patterns, and so on) might limit the alternatives you consider. ConstraintsCapture any additional constraints to the environment that the chosen alternative (the decision) might pose.PositionsList the positions (viable options or alternatives) you considered. These often require long explanations, sometimes eand diagrams. This isnÕt an exhaustive list. However, you donÕt want to hear the question ÒDid you think about É ?Ó during a fireview; this leads to loss of credibility and questioning of other architectural decisions. This section also helps ensure that you ArgumentOutline why you selected a position, including items such as implementation cost, total ownership cost, time to market, and required development resourcesÕ availability. This is probably as important as the decision itself.ImplicationsA decision comes with many implications, as the R your decisionÕs implications can be very effective in gaining buy-in and creating a roadmap for architecture execution.Related decisionsItÕs obvious that many decisions are related; you can list them here. However, weÕve found that in practice, a traceability matrix, Related requirementsDecisions should be business driven. To show accountability, explicitly map your decisions to the objectiveYou can enumerate these related requirements here, but weÕve found it more convenient to reference a traceability matrix. You cassess each architecture decisionÕs contribution to meeting each requirement, and then assess how well the requirement is met across all decisions. If a decision doesnÕt contribute to meeting a requirement, donÕt make that decision. Related artifactsList the related architecture, design, or scope documents that this decision impacts.Related principlesIf the enterprise has an agreed-upon set of principles, make sure the decision is consistent with one or more of them. This helps NotesBecause the decision-making process can take weeks, weÕve found it useful to capture notes and issues that the team discus during the socialization process. cial organizationÕs IT systems. These systemsTo start addressing these challenges andof architectural visions is beyond this articleÕsEvolutionÓcovers it in detail.The companyÕs most urgent business needbatches, with notification by letter. An in-tem A in Figure 1). Its processing flow andbusiness rules are hard-coded with few config-which many customer-facing applications use.The objectives define a problem that a tech-nical solution must address. We start by iden-tifying the architecture decisions we need toHow can we transform the current batchend system to the client applications so itcan receive requests and respond with de-mentation of the interactive approval process.We consider three alternatives: rearchitectingveloping a replacement for System A.We first identify the criteria weÕll use to se-lect the best approach. Obviously, the ability tocompanyÕs offerings from its competitors. ThisIEEE SOFTWAREwww.computer.org/software Database B (commercial off-the-shelf)(Legacy)Internetclient AInternetclient BDesktopclient ADesktopclient BAPI-basedmiddleware Batch (FTP) interfacesReal-timeinterfaces (legacy) Batch (FTP) interfaces Figure 1. Current N2: Deploy the capability within sixmonths because of competitive pressures.N4: Reduce the infrastructureÕs operationalN5: Reduce risks associated with tightOur solution should also minimize potentialdisruptions to normal business operations (N6)March/April 2005IEEE SOFTWARE Rearchitect Extend ReplaceSelection criteria: will the solution ÉSystem ASystem BSystem A N1Enable interactive approval?YesYesYes N2Be ready for delivery in six months?YesYesNo N3Reduce time to market for future enhancements?NoYesYes N4Reduce costs?NoYesNo N5Reduce risks?NoYesNo N6Disrupt business operations as little as possible?UnknownUnknownNo N7Meet desired system characteristics?NoYesUnknown N8Support enterprise principles (reuse existing infrastructure, buy before build)?YesYesNo N9Use proven technologies?YesYesNo Decision D01: Extend System B to implement interactive approval processing IssueCurrent IT infrastructure doesnÕt support interactive approval functionality for most financial products.DecisionExtend System B beyond its original functional boundaries to implement interactive approval processing for the financia products it handles. StatusApproved GroupingSystem structuringAssumptionsWe must deliver new capabilities in six months.We canÕt increase the project budget by more than 10 percent. WeÕll use existing client applications. ConstraintsNonePositionsRearchitect existing batch logic in System A. ArgumentExtending System B to handle approval processing for all financial products will reduce duplicate business logic, let a familiar with the proposed technology.ImplicationsThe team will need to develop a real-time interface between online and phone client applications and System B. Systquate disaster-recovery procedures for this system. The rollout strategy should focus on minimizing the risk of negatively affecting System BÕs other financial products. Related decisionsSee Figure 2. Related requirementsSee Table 2. Related artifactsNoneRelated principlesReuse existing infrastructure, buy before build. Use proven technologies. NotesNone as performance, capacity, reliability, and so on(N7). Finally, it should be consistent with ex-. To meet time commitments to thebusiness, we need to reuse as much of thecurrent infrastructure as possible with theoped components with COTS componentsin the applicationÕs future releases (N8).promising technologies seem to be on thehorizon, itÕs unwise to put the business atWe could analyze the alternatives in a num-of each optionÕs pros and cons (see Table 2).Clearly, the second alternative has moreuse System B. However, we can mitigate thisrisk through a well-planned rollout strategy.Now we have our first decision: Extend System B to implement interactive ap-, which we document usingour standard format (see Table 3).As a result of this decision, we must analyzement different functions; others will addressdesign strategies (see Figure 2). We might evenwhole decision hierarchy (see Table 3Õs meta-model). Alternatively, we might find that anew middleware platforms (D09). WeÕd thenThe architect makes each decision using theIEEE SOFTWAREwww.computer.org/software D01–Extend System Bto implement interactiveapproval processingD02–Use message-basedmiddleware platformfor real-time interfacesD04–Rollout only newmarketing campaignson new platformD06–Use XMLas message formatD03–Continue to use System Adatabase to storeproduct-specific dataD05–Continue to populatedata warehousefrom System A databaseD07–All batch interfaceswill be replacedD08–Use API-basedmiddlewarefor current clientsD09–Create interfacesbetween message-basedand API-based middleware Figure 2. Architecturedecisions model for thefinancial-institution example. Nine decisions all connect viability. Together, these decisions paint a clearpicture of the final solution (see Figure 3):tem B). TheyÕll use the flexible rules-basedTo minimize the amount of new work,The team will use the new message-oriented middleware platform to facilitatereal-time interaction between client appli-To ensure the projectsÕ timely delivery, thedleware for these clients, which alreadyhave live connections with it. The mes-would require interfaces between twoThe architect should now review the deci-sions with the rest of the project team and theproject stakeholders. Once the architect ob-ther define the architecture. The next stepseries of architectural views (component mod-els, deployment models, and so on).In the beginning, we identified numerous. The decisions repre-and designers can understand easily. Theyissues. The team is informed about whereit should focus its attention. For example,Table 3 and understand how the team de-. Table 2 lets you traceprocess, the team doesnÕt have time towait for the architect to completely de-architect communicates each decision sep-arately, with the caveat that itÕs subject toMarch/April 2005IEEE SOFTWARE Database B Internetclient AInternetclient BDesktopclient ADesktopclient B (legacy) Batch (FTP) interfaces middleware middlewareSystem B(commercial off-the-shelf) Figure 3. Future architecture. ichi KomiyaÕs proposed extensions,rent KarsentyÕs study provides insight intoYou could use our article to definea framework for how the Views and Beyond ap-proach represents design rationale. However,the architectureÕs primary representation.in general could benefit from better modeling-tool support. WeÕve been using Rose to createdecision relationship maps; however, the nextin organizing and traversing decisions.We see opportunities for using decisions tosent a solutionÕs major building blocks, it makessense to use them to measure how well the solu-flicting decisions. You can also use the approachto prove that alternatives, documented in the de-cisions, donÕt provide the desired qualities. Inpart of a holistic traceability methodology.Finally, to quote Ruth Malan and DanaBredemeyer, an architecture is successful if Òitchitecture construction isnÕt technical, butarchitecture direction. WeÕve found that so-cializing architecture decisions provides a1.J. Putman, Architecting With RM-ODP2.P. Kruchten, ÒThe 41 View Model of Architecture,Ó3.P. Kruchten, , Addison-Wesley, 2000.4.R. Malan and D. Bredemeyer, ÒLess is More with Mini-, vol. 4, no. IEEE SOFTWAREwww.computer.org/software In this article, we describe architecture decisions simply as annearly two decades. For an overview of other approaches, seeDesign Rationale: Concepts, Techniques and Usedesign rationale. We attempt to address this still-relevant ques-Documenting Software Architectures: Views and BeyondPaul Clements and his colleagues emphasize design rationaleÕsimportance. They provide an outline for decision description aswell as guidelines on which decisions to justify. Clements statesthat Òperhaps the most important concept associated with soft-ware architecture documentation is that of the view.Ó We wouldargue that architecture decisions are the most important concept.Documenting Software Architectures in an Agile Worldthe Views and Beyond and agile approaches. They proposeiews and Beyond and agile approaches. They proposeproduce, given enough resources. É Choosing a view identi-solve and be able to express.Ó Our approach is different. Wefirst determine what decisions are important. These decisions1.T.P. Moran and J.M. Carroll, eds., Design Rationale: Concepts, Techniques,, Lawrence Erlbaum Associates, 1996.2.P. Clements et al., Documenting Software Architectures: Views and Beyond3.P. Clements et al., Documenting Software Architectures in an Agile Worldtech. report CMU/SEI-2003-TN-023, Software Eng. Inst., 2003. Other Approaches: Design Rationale and Views 5.L. Bass, P. Clements, and R. Kazman, , Addison-Wesley, 2003.6.G. Flurry and W. Vicknair, ÒThe IBM Application, vol. 40,7.P. Louridas and P. Loucopoulos, ÒA Generic Model forACM Trans. Software Eng. and8.J.K. Kyaruzi and J. van Katwijk, ÒBeyond Components-9.A. Akerman, J. Tyree, and L. Coglianese, ÒAn Architec-, vol. 2, no. 1, 2004, www.ftponline.com/chitectural Description of Software-Intensive Systems11.S. Komiya, ÒA Model for the Recording and Reuse ofProc. 3rd IntÕl Conf. Software Reuse: Advances in Soft-12.L. Karsenty, ÒAn Empirical Evaluation of Design Ratio-M.J. Tauber, ed., ACM Press, 1996, pp. 150Ð156.13.P. Clements et al., Views and Beyond14.J. Savolainen, ÒTools for Design Rationale Documentationin the Development of a Product Family,Ó 1999, www.15.F.M.T. Brazier et al., ÒModeling Conflict Management16.R. Malan and D. Bredemeyer, ÒSoftware Architecture:Central Concerns, Key Decisions,Ó 2002, www.bredemeyer.com/pdf_files/ArchitectureDefinition.PDF. Jeff TyreeHe received his masterÕs degree in mathematics from the University of Tennessee, Knoxville.Contact him at 11013 W. Broad St., Glen Allen, VA 23060; jeff.tyree@capitalone.com. Art AkermanWorld Wide Institute of Software Architects. His research interests include creation of formal edu-nity, and making architecture development more practical and less time consuming. He receivedhis masterÕs degree in management of information technology from the University of Virginia.Contact him at 11013 W. Broad St., Glen Allen, VA 23060; art.akerman@capitalone.com. EXECUTIVECOMMITTEEPresident:GERALD L.ENGEL* Computer Science & EngineeringUniv. of Connecticut, StamfordStamford, CT 06901-2315g.engel@computer.orgPresident-Elect:DEBORAH M.COOPER*Past President: CARL K.CHANG*MURALI VARANASI VP, Electronic Products and Services: JAMES W.MOOREVP, Conferences and Tutorials: YERVANT ZORIAN CHRISTINA M.SCHOBER*MICHAEL R.WILLIAMS (1ST VP)*VP, Standards Activities:SUSAN K.(KATHY) LAND*VP, Technical Activities: Secretary: STEPHEN B.SEIDMAN*Treasurer: RANGACHAR KASTURI 2004Ð2005 IEEE Division V DirGENE F.HOFFNAGLE 2005Ð2006 IEEE Division VIII Director: STEPHEN L.DIAMOND 2005 IEEE Division V Director-Elect: OSCAR N.GARCIA*DORIS L.CARVER Executive Director: DAVID W.HENNAGE * voting member of the Board of Governorsnonvoting member of the Board of GovernorsEXECUTIVE STAFFExecutive Director:DAVID W.HENNAGEAssoc. Executive Director:ANNE MARIE KELLYANGELA BURGESSAssistant Publisher:Director, Administration:VIOLET S.DOANDirector, Information Technology & Services: ROBERTCAREDirector, Business & Product Development: PURPOSEThe IEEE Computer Society is theworldÕs largest association of computing profes-sionals, and is the leading provider of technicalinformation in the field.members, affiliate society members, and othersThe IEEE Computer SocietyÕs Web site, at www.computer.org, offers information andsamples from the societyÕs publications and con-ferences, as well as a broad range of informationTerm Expiring 2005:Oscar N. Garcia, Mark A. Grant, Michel Israel, Rohit Kapur, Stephen B. Seidman, Kathleen M. Swigger, MakotoTakizawaTerm Expiring 2006:Term Expiring 2007:Jean M. Bacon, George V.Cybenko, Richard A. Kemmerer, Susan K. (Kathy)Next Board Meeting: 11 Mar. 2005, Portland, ORPresident: W.CLEON ANDERSONPresident-Elect: MICHAEL R.LIGHTNERPast President: ARTHUR W.WINSTONExecutive Director: Secretary: MOHAMED EL-HAWARYTreasurer: JOSEPH V.LILLIEVP, Educational Activities: VP, Pub. Services & Products: LEAH H.JAMIESONVP, Regional Activities: MARC T.APTERVP, Standards Association: JAMES T.CARLOVP, Technical Activities: RALPH W.WYNDRUM JR.IEEE Division V Director: GENE F.HOFFNAGLEIEEE Division VIII Director: STEPHEN L.DIAMONDPresident, IEEE-USA: GERARD A.ALPHONSEHeadquarters Office1730 Massachusetts Ave. NW Washington, DC 20036-1992E-mail: hq.ofc@computer.orgPublications Office10662 Los Vaqueros Cir., PO Box 3014Phone:+1 714 8218380E-mail: help@computer.orgMembership and Publication Orders:Phone: +1 800 272 6657 E-mail: help@computer.orgAsia/Pacific OfficeWatanabe Building1-4-2 Minami-Aoyama,Minato-kuTokyo107-0062, JapanPhone: +81 3 3408 3118 E-mail: tokyo.ofc@computer.org