Published on

An presentation I gave in 2007 on architecture and the architecture process

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • More than 30 years ago (1975)
  • We don’t want to get there- right?What is architectureWhat’s the architect roleHow are we going to get from nothing to a working, breathing architecture
  • IEEE 1471 – recommended practice for architecture description of software intensive systemSoftware architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attributes (i.e. requirements). The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size). If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.Architectural decisions are global tied to quality attributesDesigns decisions are local –tied to functionality
  • The Tao of Software Architect
  • ColumbosAlan DershowitzAt the age of 28 he became the youngest full professor in Harvard law school historySuccessfully defended high profile clientsO.J. SimpsonClaus von BülowFrank Lloyd WrightFrank Lloyd Wright (June 8, 1867 – April 9, 1959) was one of the most prominent and influential architects of the first half of 20th century. He not only developed a series of highly individual styles over his extraordinarily long architectural career (spanning the years 1887-1959), he influenced the whole course of American architecture and building. To this day he remains probably America's most famous architect. (wikipedia)
  • A teacherA visionaryA renaissance manAn architect is someone who has an holistic view of something (Natty Gur)
  • constraints limit the (architectural) solution space Vs. requirements that set goals for the systemStakeholders should therefore not only specify requirements, but also constraints!Technical – Platform/technology (e.g. use .NET)Financial – Budget (don’t event think about that fancy Rule Engine)
  • decompose and refines the business goals and quality attributesThe root of the tree is “utility” – the overall “goodness” of the systemSelect the most important quality goals to be the high-level nodesE.g. performance, modifiability, security, and availabilityThe tree reflects the hierarchical nature of quality attributes and provides the basis for prioritization
  • Remote user requests a database report via the Web during peak period and receives it within 5 seconds.Growth scenarioAdd a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week.For a new release, integrate a new component implementation in three weeks.Exploratory scenarioHalf of the servers go down during normal operation without affecting overall system availability.ResponseUnder normal conditions update 100 moving objects on the map < 200 miliseconsLatencyUnder normal or stress conditions, a critical alert generated by the system will be displayed to the user in less than 1 secondData lossUnder all conditions a message acknowledged by the system shall not be lost (10^5 probability)Availability Hardware failureWhen a mission is in progress, upon a server mal-function, the system will be fully operable within 30 seconds or lessChangeability Add FeatureAdd a new sensor-type to the system in 2 man-months or less
  • Block diagram, UMLs DSL
  • DSLI can’t show you an example from a tool we’ve made to – simulate and integrate systems.Software Factories, MDAOnce we had “Model” -> “code” (CASE tools) – didn’t work because of “The Generation Gap”Model + framework -> code +frameworkModel -> Model -> Model -> model + framework -> code + framework
  • Patterns- package an experience Context and solutions (not “best practices”)Encapsulate forces and challenges ConsiderationsRemember that patterns are not a silver bullet either..
  • Viewpoints,Document architecture at the last responsible moment
  • On PaperSEIATAM; SAAM; ARIDLAAAMActive Design ReviewsIn CodePOCsprototypeSkeleton
  • Lets try to think about architectural risks in our little project…
  • SEIATAM; SAAM; ARIDLAAAMActive Design Reviews
  • Each dimension is rated on a five point scale, from High to LowValue Operational costDevelopment costEach dimension is given a weight, to express its importance relative to the other dimensionsAssessment is performed in two passes:Treat each cell as independentNormalize across each row
  • Making sure the architecture really fits the problemMaking sure the architecture is followedTip: Short iterations allow for better feedback loopConsider SCRUM’s 30 day sprints
  • Not a process guidanceJust a framework of activities that can be used in a variety of ways
  • But we’ve learned that Waterfall is problematic
  • Iterative is better – but essentially we are doing smaller waterfalls…Incremental we are doing “mini-waterfalls”In Agile we don’t We can’t fixTime boxing gives us rhythmPotentially shippable softwareManage requirements changesIncrease trust (demonstration)
  • This is what hacks look like38 years of construction – 147 builders 0 architects160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors65 doors to blank walls, 13 staircases abandoned, 24 skylights in floorsNo architectural blueprint exists
  • Just Enough Design Up Frontinstead of Big Design Up FrontLean Architecture
  • Architect product ownerEmphasize FlexibilityPostpone decisionsAnother statement Johanna made, which I wholeheartedly agree with, is that you should let the architecture evolve. Evolving an architecture sounds very compelling but it is not a simple feat. Architectural decisions tend to have system wide implications which means that changing one too late in the game you'd get a lot of rewrite and/or refactoring to do. My strategy to solve that conflict is to:Set the first one or two iterations as architectural ones. Some of the work in these iterations is to spike technological and architectural risk. Nevertheless most of architectural iterations are still about delivering business value and user stories. The difference is that the prioritization of the requirements is also done based on technical risks and not just business ones. By the way, when you write quality attribute requirements as scenarios makes them usable as user stories helps customers understand their business value.Try to think about prior experience to produce the baseline architecture One of the quality attributes that you should bring into the table is flexibility - but be weary of putting too much effort into building this flexibility inDon't try to implement architectural components thoroughly - it is enough to run a thin thread through them and expand then when the need arise. Sometimes it is even enough just to identify them as possible future extensions.Try to postpone architectural decisions to the last responsible moment. However, when that moment comes -make the decision. try to validate the architectural decisions by spiking them out before you introduce them into the projectThese steps don't promise that the initial architecture sticks, but in my experience it makes it possible to minimize the number of architectural decisions but still have a relatively solid foundation to base your project on
  • Scott Ambler told me that “agile ones do”, Jim Coplien “Architect Also Implements” patternReports that they’ve seen this time and time again in successful projects.For instance, In one presentation I heared Jim mentioned one stellar team- the dev. Team of Quatro pro where the architects had a daily standup (that was 93 mind-you)In my experience Architect should almost never own features I don’t find a lot of value in architects implementing production code unless there are enough architects to go aroundArchitect must know how to implementArchitect must be able to prove his design in codeArchitect can pair program to mentor/validate/solve problem and provide guidance -> this solves the getting recognition by developers part and better
  • Services interactions are message drivenServices should be Loosely coupledEdges should provide location transparencyBusiness logic and edge are separate layersScale inside the serviceYou can use workflows for long-running interactions again - inside the service
  • SAF

    1. 1. Getting SPAMMED forarchitectureArnon Rotem-Gal-OzBiometrics Line Development ManagerRafael LTD.Haifa,
    2. 2. Famous Last Words…“It is a very humbling experience to make amultimillion-dollar mistake, but it is alsovery memorable….”(Fred Brooks - “Mythical Man-Month” p.47)
    3. 3. We don’t want to get there
    4. 4. So, What is SoftwareArchitecture exactly?
    5. 5. Software architecture is thefundamental organization of a system,embodied in its components, theirrelationships to each other and theenvironment, and the principlesgoverning its design and evolution
    6. 6. The architect doesnt talk, he acts.When this is done,the team says, "Amazing:we did it, all by ourselves!" (17)The architect observes the worldbut trusts his inner vision.He allows things to come and go.His heart is open as the sky. (12)Philippe Kruchten -
    7. 7. ExplorerDesignerAdvocateThe role of the architectRon JacobsYeah – but a better analogy is
    8. 8. The Role of the Architect – take IIDesignerRenaissance ManVisionary & LeaderMentor
    9. 9. At the end of the day it is theArchitect who is ultimatelyresponsible for the quality of thesystem/product
    10. 10. First, who are we working for?
    11. 11. The Usual SuspectsCustomer End-User Project Manager ManagementDevelopers Maintainers Security AnalystsProject New comers Testers Customer’s IT group
    12. 12. Mapping Stakeholderslow HighlowHighConcernImportance(or Power)InterestMonitor(Minimum Effort)KeepInformedKeepSatisfiedManageCloselyBased on Schekkerman - IEAD
    13. 13. Architecture PrinciplesSet the direction for the solutionInitial guidelines to consider for the solution
    14. 14. And there are always someconstraints
    15. 15. Next, we have to thinkabout the quality Attributes
    16. 16. Quality Attributes• Performance• Availability• Usability• Security Maintainability Portability Reusability TestabilityEnd User’s viewDeveloper’s view Time To Market Cost andBenefits Projected lifetime Targeted Market Integration withLegacy System Roll backScheduleBusinessCommunityviewA list of quality attributes exists inISO/IEC 9126-2001 Information Technology – Software Product Quality
    17. 17. UtilityPerformanceResponseUnder normal conditions -update of an entity in thepersistent storage <0.5SecondLatencyUnder normal or stressconditions, critical alertgenerated by the system willbe displayed in less than 1seconds (for generation)Data Lossunder all conditions, amessage acknowledged bythe system will not be lostAvailability Hardware IssuesUnder all conditions, when aserver crash, the system willresume operation in lessthan 30 secondsUsabilityComplianceThe system should complywith maritime datastandards (e.g. Mercatorprojection)OperabilityThe system should handleuser request withoutimpeding the users ability tocontinue controlling thesystem (e.g. initiateadditional requests)SecurityUnauthorizedusersunder normal conditions andconnectivity the systemshould alert an unauthorizedlogin attempt (intrusion)within 1 minuteAdaptability More UsersWhen additional users needaccess to the system, addnew /more hardware (tosupport load) under 4 manweeksIdentifyscenariosandprioritizethem usingUtility trees
    18. 18. Just remember that theyactually look like this…
    19. 19. The secret to quality attributeanalysis is the scenarios
    20. 20. Anatomy of a scenario– Under normal operation, perform a database transactionin under 100 milliseconds.Context StimulusResponse
    21. 21. Oh yeah – there’s alsomodeling and design…
    22. 22. RepositoryPCUIEntityPCPCMapUIC+UICUICUIEntityUIEntityMAPBusIBUSSomeServiceMessageHandlerRootUICPCMessageHandlerMessageHandlerUICCorrelatorPortal
    23. 23. sd Portal - Send MessagePortal CorrolatorServiceMsg1IBus MessageHandler MessageMapperUIC RepositoryServiceMsg2opt Needs new entityloop All message handlers1.01.1 Register1.2 Send(ServiceMessage,Service)2.0 message:=2.1 handle(message)2.2 entity:= Build(message)2.3 insertEntity(entity)2.4 RepositoryChanged2.5 CorrelatedMessageRecieved2.6 callback(cookie,EntitiesAffected)
    24. 24. Metacase –
    25. 25. Pattern can saveyou the trouble ofreinventing thewheel
    26. 26. If you want thearchitecture tobe effective ithas to becommunicated
    27. 27. Two roads diverged in a yellow wood,And sorry I could not travel bothAnd be one traveler, long I stoodAnd looked down one as far as I couldTo where it bent in the undergrowth(The road not taken, Robert Frost 1915)
    28. 28. When you present an architectureyou should consider yourtarget audience
    29. 29. Compare this:id Service ViewUI«Service»COP«Service»Navigation«Service»OwnSiteESB«Service»Alerts
    30. 30. With thisCOPAlertsUI OwnSiteNavigationESB
    31. 31. Technology Mapping
    32. 32. vHuman WorkflowECM DW OLTPDALService AgentsBusiness RulesActivityWorkflowAuthorizationMonitoringFaçadeLog&TraceExceptionManagementConfigurationAuthenticationSigningRich UI Web UILogistics E-PublishFinance
    33. 33. K2SQL 2005 SQL 2005Generated C#ILOG RulesC#BizTalk 2004Tamuz+Win2003CAUnicenterWCFEnterpriseLibraryEnterpriseLibraryEnterpriseLibraryAzManSigningOutlook + C# ASP.NET 2.0 on IIS 6.0DocumentumWCFSAPLogisticsAdobeElementsSAP 4.6DFIBizTalk 2004
    34. 34. Where are we at?ArchitectureQualityAttributesTechnologyPatterns &Anti-patternsPrinciplesCommunityexperienceStakeholdersArchitectpeopleA “deliverable”ProduceKeyIs an inputConstraints
    35. 35. OK then, so we are all set
    36. 36. The architecturehas to beEvaluated to makesure it is any good
    37. 37. Test EarlyTotal Risk ExposureRisk Exposure ReductionTimeRiskRisk ReductionPeriodControlled risk management periodTotal RiskExposure
    38. 38. Sometimes we need to do moreformal evaluationsATAM flow – SEI -
    39. 39. Formal Evaluation Example LAAAM• Assessment Matrix– Evaluate suitability of strategies againstscenariosValueCostStrategiesScenariosBased on Jeromy Carriere
    40. 40. LAAAM – Example (1/2)StrategyScenario Analysis WeightA. Performnorearchitecting. Maintainwith minimaleffort theexisting ABCapplicationarchitecture.Introduce nonewdependencies on ABCcomponents.B.Incrementally wrapexisting ABCapplicationcomponentsin the modelprovidedwith .NET.C.Completely portexistingABCapplications to .NET.D.CompletelyportexistingABCapplicationsto J2EE,usingexistingenterpriseframeworks.1. A newapplicationleverages theXYZ data store.Value 1 Moderate Moderate-HighModerate ModerateDevelopmentCost1.5 High Low High HighOperationsCost1 Low Low-ModerateLow Low-ModerateAssessment 3 6 3 2.5Based on Jeromy Carriere
    41. 41. LAAAM – Example (2/2)Scenario Analysis Weight A B C D2. The XYZapplicationspresentationis customizedby the user todeterminelayout andcontent.Value 1 Low Moderate-HighHigh HighDevelopmentCost1.5 N/A Moderate Moderate-HighModerate-HighOperationsCost1 N/A Low-ModerateLow Low-ModerateAssessment 0 4.5 4.75 4.253. The peaktransactionrate for theXYZapplicationincreases by10x (afterscenario 2).Value 1 Low Moderate-HighHigh HighDevelopmentCost1.5 High Low-ModerateModerate-HighHighOperationsCost1 High Moderate Low ModerateAssessment 0 4.75 4.75 3Based on Jeromy Carriere
    42. 42. All we have todo now is todeploy thearchitecture
    43. 43. StakeholdersPrinciplesAttributesModelingMappingEvaluationDeployment
    44. 44. It is “easy” in waterfall& incremental
    45. 45. Requirements Architecture Design Code Integration TestRequirements& planninggameR,A,D,C,I,T(Time boxed)R,A,D,C,I,T(Time boxed)R,A,D,C,I,T(Time boxed)R,A,D,C,I,T(Time boxed)Final TestRequirements ArchitectureDesign, Code, Integrate,TestDesign,Code,Integrate,TestFinal Integration Final TestMoving from Waterfall to AgilewaterfallIncrementalAgilebased on Johanna Rothman
    46. 46. Building in small iterationscan be dangerous
    47. 47. Winchester Mystery House
    48. 48. Can you do Agile Architecture?
    49. 49. JEDUF vs. BDUFComponent AComponentBComponentCComponentDComponentFComponentHComponentI
    50. 50. Evolve thearchitecture
    51. 51. Architect mustimplement?
    52. 52. StakeholdersPrinciplesAttributesModelingMappingEvaluationDeployment