Transcription
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAn Architectural Decision Modeling Framework for SOA andCloud DesignDr. Olaf ZimmermannIBM Research – Zuricholz@zurich.ibm.com1 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsSession AbstractIn this presentation, we demonstrate how reusable architectural decision modelscan support Service-Oriented Architecture (SOA) and cloud design: We presentan architectural decision modeling framework called SOA Decision Modeling(SOAD) which treats recurring architectural decision as first-class architecturedesign artifacts. SOAD provides a technique to systematically identify suchrecurring decisions.We also present a reusable architectural decision model for SOA that wascreated with SOAD. This model separates long lasting platform-independentdecisions from rapidly changing platform-specific ones; the alternatives in aconceptual model level reference architectural patterns. SOAD has its roots in ourindustry projects conducted since 2001; it has been leveraged successfully bypractitioners since 2006.SOAD is not only applicable to enterprise application, SOA, and cloud design, butalso to other application genres and architectural styles. It supports use casessuch as education, knowledge exchange, design method, review technique,governance instrument, and architecture change management.2 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation and case study Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-Role Collaboration and Tool Integration Emerging tool support (demo) Discussion and summary3 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation and case study Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-Role Collaboration and Tool Integration Emerging tool support (demo) Discussion and summary4 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsArchitectural Decisions: Current Trends Decision capturing support soonto be mandatory in architecturedescriptions conforming nfohttp://www.architecting.co.uk/index.php Popular text books and maturemethods promote the concept Practitioner demand No tools yet5 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsWhat are Architectural Decisions? Why Bother? “The design decisions that are costly to change” (Grady Booch, 2009) Our definition (from ctural decisions capture key design issues and the rationale behind chosensolutions. They are conscious design decisions concerning a software system as awhole, or one or more of its core components, with impact on non-functionalcharacteristics such as software quality attributes.” 6From IBM UMF work product description ART 0513 (previous name: ARC 100):“The purpose of the Architectural Decisions work product is to:– Provide a single place to find important architectural decisions– Make explicit the rationale and justification of architectural decisions– Preserve design integrity in the provision of functionality and its allocation to systemcomponents– Ensure that the architecture is extensible and can support an evolving system– Provide a reference of documented decisions for new people who join the project– Avoid unnecessary reconsideration of the same issues” 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsCase Study: Telco Service OrdersVSP – Virtual Service ProviderPSTN – Public Switched Telephone NetworkFirefox is a registered trademark of the Mozilla Foundation7 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsImportant Non-Functional Requirements (NFRs)1.2.3.4.5.6.7.8The software system supporting the two order management processes must beaccessible both over a private industry-sponsored network and the Internet. TheVSPs and the backend systems to be integrated (e.g., billing system) change overtime.Business volumes are approximately 20,000 “Create PSTN service” requests and15,000 “Move PSTN service” requests per month.–Given up to 20 steps per process, and a peak hour load of 30% above average, thisequates to a peak load of about 4,550 steps executed per hour (based on corebusiness hours of ten hours per day, 20 days per month)Initially, process instances must be able to persist from first step to last for threehours; however, this time will be extended to up to 24 hours in the future.VSPs are spread across a number of time zones, operating 23 hours per day andseven days per week.Average response time targets vary by process step, typically 3-5 seconds; 95%of the user interactions need to complete execution in 5-8 seconds.Domain-specific architecture design challenges include: 1. Address validationcompleteness and timeliness, 2. Releasing reserved resources (coppertransmission path, telephone number) when a process instance fails or customerwalks away.Communication patterns and protocols must support multiple platforms. 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsArchitecture Overview Diagram (Informal)Firefox is a registered trademark of the Mozilla Foundation9 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation and case study Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-Role Collaboration and Tool Integration Emerging tool support (demo) Discussion and summary10 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsThree Usage Scenarios for Architectural DecisionsKnowledge Engineer(EA Specialty)Solution ArchitectScenario 2:Active Method GuidanceSolution ArchitectScenario 1:After-the-FactDecision Capturing1.1 Document decisions made andtheir rationale (supporting decision logreport generation)112.1 Distinguish decisions required(issues) from decisions made(outcomes)2.2 Share issues and related bestpractices via guidance models2.3 Assign design work items (issueswith open outcomes) to teammembers and track decision makingprogress (a.k.a. “backlog”)EA Staff (e.g. CoE)Project Team (C/ALM)External Parties (e.g. Auditors)Scenario 3:Cross Role Collaboration3.1 Identify issues in requirementsartifacts and trace their resolution3.2 Bind architectural decisions toenterprise-wide architecturalprinciples and reusable assets suchas pattern repositories3.3 Enforce decisions in UML andtopology models3.4 Integrate with process tasks3.5 Measure decision makingpractices (model analysis) 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation and case study Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-Role Collaboration and Tool Integration Emerging tool support (demo) Discussion and summary12 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsScenario 1 (Documentation): A Story from the Case Study (2004-2005)“According to our method, I have to create awork product called ‘ArchitecturalDecisions’. It is supposed to record the keydecisions made on the order managementSOA project, and the rationale behind them.”“This will help me survive the upcoming technicalquality assurance review requested by theworld-wide SOA subject matter expert they will beflying in shortly. And hopefully it will stop theseendless and pointless discussions ‘whySOA’ that our developers have been raising since theproject start.“Solution Architect“So let’s create an architectural decisions work product:1.2.3.We decided for process-enabled SOA because the business scenario is a long running, multichannel, multi actor scenario with heavy resource coordination requirements. There are 20backend systems, only a few of which are transactional.We decided for BPEL because it is a standardized workflow language with emerging tool and runtimesupport. The out-of-the-box support for compensation will help us meet the coordination requirements.We decided for IBM WebSphere products because this the preferred vendor of the client. The IBM BPELengine can easily handle the required load. BPEL is new (July 2004), so lab advocacy will be needed.This is getting tedious in MS Word although I have all insight I need. Will capture the next few ones later.I really need a tool that supports decision capturing and sharing.”13 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsArchitectural Decision (AD) about Integration Style –Documented according to IBM Unified Method Framework (UMF)14Subject AreaProcess and service layer designTopicIntegrationNameIntegration StyleAD ID3Decision MadeWe decided for RPC and the Messaging pattern (Enterprise Integration Patterns)Issue or ProblemHow should process activities and underlying services communicate?AssumptionsProcess model and requirements NFR 1 to NFR 7 are valid and stableMotivationIf logical layers are physically distributed, they must be integrated.AlternativesFile transfer, shared database, no physical distribution (local calls)JustificationThis is an inherently synchronous scenario: VSP users as well as internal T staffexpect immediate responses to their requests (NFR 5). Messaging will give usguaranteed delivery (NFR 3, NFR 6).ImplicationsNeed to select, install, and configure a message-oriented middleware.DerivedRequirementsMany finer grained patterns are now eligible and have to be decided upon:message construction, channel design, message routing, message transformation,system management (see Enterprise Integration Patterns book).Related DecisionsNext, we have to decide on one or more integration technologies implementing theselected two integration styles. Many alternatives exist, e.g., Java MessageService (JMS) providers. 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsArchitectural Decision Making in Context – Decision DriversReference Information(Industry Models,Enterprise Architecture)TechnicalDriversFunctional Requirements(BPM, Use Cases, User Stories)Existing Systems(Capabilities, Limitations)Non-Functional Requirements(incl. SoftwareQuality Attributes)Phase (Ph.)n-1Zimmermann O.,An Architectural Decision ModelingFramework for SOA Design.Dissertation.de, 2009Ph. n4 1 VPsPh. n 1PastArch. DecisionsArchitecture Design Work4 1 VPsFutureArch. DecisionsNontechnicalDriversStakeholder Goals(Existing Practices,Strategic Directions)15Project Budgetand TimelinesSkills, Experience,Preferences in Team 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsValid Justifications and Counter Examples Convincing rationale:– Direct link to (non-)functional requirements, quality attributes in particular– Positive experience on previous project– Existing skills, license agreements Poor justifications:– Market momentum (technology or vendor push)– Only one alternative known/considered– Keep CVs of team members current More examples are given in this IBM developer works ture/library/ar-knowwiki1/16 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation and case study Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-role Collaboration and Tool Integration Emerging tool support (demo) Discussion and summary17 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsScenario 2 (Guidance): The Case Study Continues“This is going to be aninteresting assignment.According to the PPT chartsthat outline the architecture, theteam decided for SOA but doesnot know much about thedesign issues that it has toresolve now. These issuesinclude service granularity,transaction boundaries,message exchangepatterns.”KnowledgeEngineer(SOA SME)“Are we the first IBM client that implements aprocess-based SOA with BPEL? If not, I’d love tohave a look at the architecture designdocumentation from the previous projects. Whichdetailed design issues did the teamencounter? Which patterns and technologyalternatives did they consider? Why did theydecide for the ones they eventually picked? Didthey work? Do they have other best practicesto share?“Solution Architect“This decision-centric approach to knowledge sharing, architecture design, and reviewing worked reallywell. In each workshop, we looked at selected issues to be resolved, which apparently came from some reusable asset (calledguidance model if I remember correctly). We based the selection (called tailoring) on various factors such as projectscope, risk and cost, and amount of experience in the local team. The issues come with alternatives that areknown to have worked on previous projects, and with links to additional issues to be investigated. Without thisknowledge base, I would have had no idea that I have to worry about the system transaction boundaries inside thebusiness processes and the underlying Web services, let alone where in the IBM BPEL engine to configure these settings.Same for my developers by the way.”“If we succeed with this project, I will harvest and contribute to the guidance model the additional issues that weencountered, the alternatives we chose, and the rationale for these decisions.”18 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsFrom AD Documentation to Active Method GuidanceBusinessExecutive Levelfor each project600 Decisions in IBMSOA Decision Guidance Model(SOAD)ArchitecturalStyle(SOA or other?)Decision Made/Alternative SelectedSOAConceptual Levelfor each serviceService CompositionParadigm(Processes? Classes?)Process-Enabled SOAProcess-Enabled SOATechnology LevelArchitecturalDecision Issue(with Alternatives)Message Exchange Pattern(Request-Reply? One Way?)Transaction Boundaries?Service Granularity?Message Confidentiality?Synchronous Request-Replyfor each processWorkflowLanguage(BPEL? Other?) BPEL 2.0Transport Protocol(SOAP over HTTP?)Transaction Qualifiers in SCA?Operations per WSDL Port Type?HTTPS or WSSE?SOAP/HTTP 1.1Vendor AssetLevelBPEL Engine(IBM WPS? Other?)19 SOAP Engine(Apache Axis2?)IBM WebSphere Transaction Settings?Eclipse WTP/Apache Axis2 Usage?Apache/WebSphere Configuration? 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsEntity Types and Associations in UML MetamodelGuidance ModelDecisions Requiredand CandidateSolutionsProblem and criteria“We decided for the MVCalternative to resolve the webpage flow issue because wegained positive experience withit on many similar projects.”“When designing apresentation layer,you will have toselect a pattern tocontrol the Webpage flow.”“Model View Controller(MVC) is a commonarchitectural pattern tocontrol the Web pageflow.”Our extension20Decision ModelDecisions ActuallyMade on ProjectsChosen solutionand justificationPotential solutions with pros and consUMF template (ART 0513/ARC 100) 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsTemplate Used to Present Issues and AlternativesIdentifyingModel orDiagramPhaseRoleDecision driversScopeEnforcingModel orDiagramIssue: Name (SOA Guidance Model Level)Other Issue(InboundDependency)Problem StatementBackground readingAlternative 1:NameAlternative 2:NameDescriptionDescriptionProsAlternative 3:Other n Identification21Decision MakingDecision Enforcement 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsIntegration Layer Design Issue: Message Exchange PatternScope:OperationServiceModelDecision drivers: Reliabilityneeds, systemsmanagement capabilities,availability of providerPhase: Macro DesignRole: Integration ArchitectWSDLIssue: Message Exchange Pattern (Conceptual/Technology Level)Do consumer and provider communicate synchronously or asynchronously?Background reading: Hohpe/Woolf “Enterprise Integration Patterns”IntegrationStyleAlternative 1:Request-ReplySOAP/HTTPAlternative 2:One Way over ReliableTransportJMS or WS-RMSimple to manage,but no guaranteeddelivery, so*might* have todeal withundelivered areJMS:Java MessagingServiceWS:Web ServicesRM:Reliable MessagingCombination ofAlternative 1 onapplication integrationlayer,Alternative 2 onunderlying transportlayerIntegrationTechnologySame as Alternative 1,but guaranteeddeliveryRecommendation: Do not follow an MOM hype – decoupling in time is just one of severaldimensions of loose coupling. The equation (NOT RM NOT SOA) does not hold true.Decision Identification22Consumer and providerup times can differ;guaranteed delivery (onceand only once) whenusing persistentmessages. Must managedead letter queue.Alternative 3:Pseudo-AsynchronousDecision MakingDecision Enforcement 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsIssues Dealing with System Transaction Boundaries TopicWBM or RSAProcessModelScope:Activity/OperationDecision drivers: Resourceprotection needs, datacurrency, performancePhase: Macro DesignRole: ApplicationArchitectIssue: Invocation Transactionality Pattern (Conceptual Level)WorkflowpatternselectionShould a business process, its activities, and the service components itinvokes run in a single or in multiple system transactions?CompensationPatternsSee ICSOC 2007 paper by Zimmermann et al. for available patterns.WorkflowengineselectionTx: rabilitySCA:Service ComponentArchitecture23Alternative 1:Transaction IslandsAlternative 2:Transaction BridgeAlternative 3:Stratified StiltsDo not share TxcontextShare Tx contextUse asynchronousmessaging andsuspend TxBest performance,loose coupling, butno full ACIDprotection forresources.Best resourceprotection, butlarge, long runningTx tightly couplingactivities andservices.SCA qualifiers,BPEL serverconfiguration,WS-AT usageSupports, loosecoupling best, but nofull ACID protection.Recommendation: Use Transaction Islands as default, Stratified Stilts for longrunning, distributed processes. Decision injection into model transformationor BPEL code in WebSphere Integration Developer is possible.WIDBPELProcess Model 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsIssues Dealing with Service Granularity TopicServiceModelScope:Service OperationRole:Service ModelerPhase:Macro DesignDecision drivers: Functional requirements (domain model), capabilities of BPEL, SOAP,WSDL, XML processors (verbosity), interoperability, network topology, number ofdeployment artifacts and generated code structure, strong vs. weak typing philosophy.WSDL,XML SchemaContractsXMLProfilingIssue: In Message Granularity (Conceptual/Technology Level)BusinessGranularityProblem Statement: How many message parts should be defined in theservice contract? How deep should the part elements be structured?The four alternatives have not been published as patterns yet.ServiceTypeEnterpriseData ModelAlternative 1:Dot PatternAlternative 2:Bar PatternSingle scalarparameterSingle complexparameterEasy to process forSOAP/XMLengines, muchwork forprogrammerDeep structure andexotic types cancauseinteroperabilityissues.Alternative 3:Dotted LinePatternMultiple scalarparametersHandled by allcommon engines,some programmerconvenience.Alternative 4:Comb PatternMultiple complexparametersCombination ofoptions 2 and 3,biggest overheadfor processingengines.Recommendation: All alternatives have their place; alternatives 2 and 3 are often chosen.Base decision on layer and service type. Avoid overly deep nesting of data structuresunless you want to stress test the XML processing. Minimize message verbosity.24Out MessageGranularityOperation ToServiceGroupingComponentWrappingWDSL, XSDEditorSelection 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsConceptual/Technology Issues about nsSSL/TLS:Secure SocketsLayer/TransportLayer SecurityWSSE:Web ServicesSecurityExtensionsScope: OperationDecision drivers:Confidentiality needs,performance, number ofintermediariesPhase: Macro DesignRole: Security SpecialistWSDL, XSDIssue: Encryption Layer and Technology (Technology Level)Where and how should service messages be encrypted?See book by Weerawarana et al: “Web Services Platform Architecture”Alternative 1:Transport-LayerEncryptionAlternative 2:Message-LayerEncryptionSSL/TLS (HTTPS)XML digitalsignatures WSSEWell adopted onthe Web, but noend-to-endsecurity.Allows end-to-endsecurity acrossintermediaries, butis expensive.SSL ProviderSelection(SW, HW)WSSE EngineSelection(SW, HW)EngineConfiguration(HTTP,WSSE)Recommendation: Stick to SSL/TLS unless message-level security required dueto business requirements; use HW accelerator when deciding for WSSE25 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsVendor Asset Level Clustering IssuesNFRs,ComponentModelScope: NodeDecision drivers: Availabilityneeds, budget, logical servicedesign (session affinity)Phase: Macro DesignRole: Infrastructure ArchitectOperationalModelIssue: WebSphereClustering (Vendor Asset Level)RuntimeTopologyDirectionsShould WebSphere Application Server be deployed in a standalone or in a highavailability configuration?See WebSphere Info Center and platform patterns documentsAlternative 1:Single ServerAlternative 2:ClusterNo node managerEnable node manager,have multiple nodes thatcan take over from eachotherEasy to manage, butservice consumerscan not be servedwhen WAS instanceor server HW aredown. Server failureleads to loss ofsession data.Higher availability fromconsumers perspective,hot/cold session takeoverrequired. Systemsmanagement onsClusterConfiguration(WAS)Recommendation: Stick to Alternative 1 unless business requirements and NFRs force youto use Alternative 2. Design services to be able to run in clustered configuration(e.g., store only serializable Java objects and only a few KB in HTTP session object)26 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsSOA Design Issues Organized by Levels and LayersBusinessExecutive LevelApplication ArchitectureInfrastructure y LevelFunctional VP:TechnologyDecisionsConsumer LayerProcess LayerService LayerComponent LayerResource LayerVendor AssetLevelConsumer LayerFunctional VP:Vendor/AssetDecisionsProcess LayerService LayerComponent LayerResource Layer27Operational VP:TechnologyDecisionsQoS LayerResource LayerOperational VP:ConceptualDecisionsQoS LayerComponent LayerQoS LayerService LayerIntegration LayerProcess LayerIntegration LayerFunctional VP:ConceptualDecisionsConsumer LayerPlatform PreferencesIntegration LayerConceptual LevelExecutiveDecisionsExampleOperational VP:Vendor/AssetDecisionsMessage Exchange PatternTransport ProtocolDataPower ConfigurationVP – Viewpoint 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsAgenda Motivation Usage scenarios for architectural decision modeling Scenario 1: After-the-Fact Decision Capturing Scenario 2: Active Method Guidance Scenario 3: Cross-Role Collaboration and ToolIntegration Emerging tool support (demo) Discussion and summary28 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsScenario 3 (Cross Role): Desired State in the Case Study“The requirements people are using this new tool whichsupports decision model tailoring and outcomeinstance creation. So I already know that twobusiness processes with about 100 Web servicesactivities have to be realized. We’ll have to use HTTPSto connect Web channels to the system. We’ll also pick aclustered topology. This really accelerates thearchitecture design work.““I am not supposed to worryabout technical details of theSOA solution too much, butquite a few architecturallysignificant requirementssuch as confidentiality and24x7 availability have beenstated. I will mark them assuch. I’ll be interested to tracewhether and how thearchitecture satisfies them.”Business AnalystSolution Architect“In recent times, developers have criticized myarchitecture design as too high level and toodifficult to implement. I am not always sure how toenforce my architectural decisions so thatthe implementation reflects them properly. With thenew collaboration tooling, I can track them asdesign work items and link them todevelopment tasks. Some of the enforcement caneven be automated by code generators.”29Developer“The new collaboration tooling has its goods and itsbads from my perspective. On the positive side, Ican always find somebody who knows aboutthe design goals and decisions made so far. Andwe all are informed about project health.However, the architects are much closer involvednow; I can no longer create and hide my owndesigns. And some of the routine coding andconfiguration steps were taken over bymodel transformations.” 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsFrom Requirements to Architectural DecisionsFunctional requirements Processes to be automatedand integrated Services to be built or reused Data to be managed acrosslife cycleReference information(industry models,enterprise architecture)Existing systems(capabilities, limitations)Non-functional requirements Software quality attributes Service level agreements Regulatory constraints Data managementHow to build the processes/services and satisfy theirquality requirements and constraints?Architectural DecisionsRecurring decisions carry best practices regarding pattern adoption30 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsActive Method Guidance (Meta Issue Level):Handshakes between Design Models and Decision ModelsDecision ModelGuidance ModelIdentifyingDesign ModelElement (DME)scope(of Issue)Chosen Alternative(in Outcome)Pattern SelectionDecision Pattern SelectionDecisionEnforcingDMEPattern AdoptionDecisionsPattern AdoptionDecisionsChosen Alternative EnforcingDMETechnologySelection Decision TechnologySelection DecisionChosen AlternativeEnforcingDMETechnologyProfiling DecisionsTechnologyProfiling DecisionsChosen Alternative EnforcingDMEAsset SelectionDecisionAsset SelectionDecisionChosen Alternative EnforcingDMEAsset ConfigurationDecisionsAsset ConfigurationDecisionsChosen Alternative EnforcingDMEConceptual LevelTechnology LevelIdentifyingDMEscopeVendor Asset LevelIdentifyingDMEscopeDecision Identification31Decision MakingDecision Enforcement 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge Tools(Meta) Issue Identification in High-Level Component ModelsLegend:Overall Layer/UnitOrganization?Layer/Noden 1Interface r/Node nreplyDesign Model Element(Functional, Operational)Meta Issue(Decision Required)Interface QoS?Internal Layer/UnitStructure?Component/Unit 1UtilitiesLayer AccessControl?Component/Unit 2State?ComponentInteractions?Component/Unit LayerActivityLogging?Transition to Next RealizationLevel (e.g., Conceptual toSpecified to ImplementationComponent Model andConceptual to Specified toPhysical Operational Model?)Interface ace(Provider)–Each concrete component and connector inchosen reference architecture yields concreteissues derived from meta issuesE.g. Web service component, WebSpheretopology unit 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsConceptual Operational Model (COM) and Rational SoftwareArchitect Topology: Decisions Made/RequiredDecision made: Model a single location for entire order management system, rationale: physical separation/mirroring not requiredDecision made: Let this location host two identicalconceptual servers, rationale: medium to advancedavailability and performance NFRs; requests must not be lost.Decision made:Host fourDeployment Units(DUs),rationale: UMLcomponentlayering, bestpractice stated inSOAInfrastructureReferenceArchitectureDecisions now required (identified in this model):Transition to Specified OM, specification of realization linksDeployment Perspective – Topology Model – Topology Diagram Editor33 2010 IBM Corporation
IBM Research – ZurichServices Management/Architectural Decision Knowledge ToolsScenario 3: Cross Role Collaboration (Continued)“The order management project was a big success. The team learned a lot about the design of process-driven SOA. Weplan to apply this architectural style on several new projects; hence, we would like to establish architecturalprinciples such as loose coupl
can support Service-Oriented Architecture (SOA) and cloud design: We present an architectural decision modeling framework called SOA Decision Modeling (SOAD) which treats recurring architectural decision as first-class architecture design artifacts. SOAD provides a techn
