Upload
timothy212
View
798
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
2.
3. Session 1 Review 4. REVIEW: Architecture Defined
Enterprise mission and business requirements Systemarchitecture Systemdevelopment Systemoperation Validate Design Validate Design 5. REVIEW: Concepts of System Architectures
6. REVIEW: Concepts of System Architectures
7. REVIEW: Architectural Styles Example: A Bank ATM System Style: Hierarchical, client server, layered ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM ATM ATM ATM ... Server Server ... Mainframe Server Users Users Users ... Presentation/User Interface Layer Infrastructure/ Communications LayerDomain/Enterprise Logic/ Data Layer 8. Presentation Business Rules Data Access DBMS Fat Client Two Tiers Desktop: Server(s): Presentation Business Rules Data Access DBMS Plump Client Two Tiers Presentation Thin Client Multi-tier Ultra-Thin Client Multi-tier Browser Business Rules Data Access DBMS Business Rules Data Access DBMS REVIEW: Architectural Styles Gartners Two-Tier and Multi-Tier Enterprise Architectures: 9. REVIEW: Architecture Impact of COTS Products
10. REVIEW: An Architecture Framework Architecture Best Practices: Enterprise modeling and requirements specification Application analysis and design Data analysis and design System integration Network analysis and design Incremental system development Enabling Technologies: Computing & comm. components Microsoft technologies JAVA technologies Web technologies XML technologies Security technologies Architecture patterns Development methods and tools Domain Architectures: EAI architectures E-commerce architectures Directory architectures System management architectures Middleware architectures Industry standard architectures Client Environment: Client relations, people, and culture Enterprise architectures, business models, workflows, & legacy systems Functional, non-functional, & usagerequirements and constraints Processes for Developing Tools for Developing Framework for Developing Goals for Developing Architecture Fundamentals: Architecture role and life cycle Architecture representation and reasoning Architecture processes and work products Architecture analysis and design Architecture modeling and validationArchitecture patterns and properties COTS evaluation and integrationAbility to Develop Marketplace Environment: Partners and alliancesCOTS and component products Service and consultation offerings User groups and standards Parts for Developing System Environment:enterprise architecture, business models, system usage and evolution External Behavior View(System Specification): User tasks and workflows Function and information Stimulus/response behavior Data and Software View(Logical Infrastructure): Middleware and applications Databases and storage systemsOperating systemsHardware and Network View(Physical Infrastructure): Computing hardware: servers, mainframes, PCs,mass storage, Networks, wired & wireless: media, devices, topology, protocolsSystem Requirements:function, and properties of reliability, performance, scalability, security, usability, cost, SYSTEM ARCHITECTURE 11. REVIEW: Box Structure Reasoning for Components
12.
REVIEW: Box Structure Reasoning for Components: Black Boxes
Stimulus (S) Response (R) Stimulus Stimulus history Response 716 5 7165 716C 5 5
13.
REVIEW: Box Structure Reasoning for Components: State Boxes
Stimulus (S) Response (R) state trans 14. REVIEW: Compositional Reasoning for Networks A Bank ATM System ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM ATM ATM ATM ... Server Server ... Mainframe Server Users Users ... Presentation/User Interface Layer Infrastructure/ Communications LayerDomain/Enterprise Logic/ Data Layer 15. REVIEW: Compositional Reasoning for Networks
ATM Server Mainframe Server ATM
ATM Server ATM Server ATM Server ATM Try again wrong pin Try again wrong pin Access denied User User U U U U U U U U 16. REVIEW: Compositional Reasoning for Networks
ATM Server ATM Server ATM Server ATM wrong pin Try again wrong pin Try again right pin Access denied Server ATM Access granted wrong pin
U U U U U U U U U U U 17. REVIEW: Compositional Reasoning for Networks When you buy gas at a pump with a speedpass, what is a possible architecture trace of your transaction? ? pump pump User User Despite the fact that thousands of users may be accessing the system at the same time, the system is designed to maintain the compositional integrity of the architecture traces of all the users. It appears to you as though you are the only user. 18. REVIEW: Compositional Reasoning for Networks
A Bank ATM System ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM ATM ATM ATM ... Server Server ... Mainframe Server Users Users ... 19. Architecture Life Cycle, Work Products,and Processes 20. Architecture FundamentalsArchitecture Practices Client Environment:enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies INPUTS Architecture Life Cycle: Inputs 21.
Perspective Know the status of enterprise architecture definition Analyze existing enterprise architecture IT infrastructure Evaluate requirements wrt existing infrastructure Architecture Life Cycle: Inputs: Enterprise Architecture Defn 22.
Perspective Analyze legacy capabilities wrt client requirements Understand evolution plans for legacy assets Treat legacy integration on a par with new components Architect forfirm future usesof legacy elementsArchitecture Life Cycle: Inputs: Legacy systems 23.
Perspective Never architect against presumed requirementsAvoid late-life-cycle requirements surprises Iterate requirements definition with clients Involve all client roles andstakeholders Treat requirements as an architecture entry condition Develop prototypes to elicit requirements from clients Establishrequirements baselinesto manage change andprevent scope creep Architecture Life Cycle: Inputs: Initial Requirements 24.
Perspective Capitalize on alliance strategies and agreements Perform due diligence assessments of vendors Evaluate function and quality of COTS products Reconcile COTS capabilities with client requirements Recognize COTS selections tie clients to supply chains Capitalize on accepted standards, avoid othersArchitecture Life Cycle: Inputs: Marketplace Environment 25.
Perspective Capitalize on applicable domain architectures Maintain knowledge ofevolving domain methods Architecture Life Cycle: Inputs: Domain Architectures 26.
Perspective Maintain knowledge ofevolving technologies Where possible, build on existing client environments Recognize enabler selections tie clients to supply chainsArchitect for component and environment evolution Architecture Life Cycle: Inputs: Enabling Technologies 27. Architecture FundamentalsArchitecture Practices Client Environment:enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final RequirementsPrototypes & Models Architecture Design Architecture ProvisioningArchitecture Validation VendorAgreementsDevelopment Plan INPUTS WORK PRODUCTS Architecture Life Cycle: Work Products 28.
Perspective Challenge and confirm key requirements Find any under-represented stakeholders Review property trade-offs with client The baseline plus controlled changes are the final reqs. It doesnt matter how well the wrong system is built Cost Benefit High High Low Low No Go Discuss Go Discuss Architecture Life Cycle: Work Products: Final Requirements 29.
Perspective Target prototypes to specific questions and objectives Evolving prototypes into products can be very risky Model results are only as good as model fidelity Model results are only as good as model inputsMatch modeling effort to project stakes Architecture Life Cycle: Work Products: Prototypes & Models 30.
Perspective Get all the guidance, advice, and review you can find Simple and straightforward solutions are best Use what is known to work -- capitalize on similar projects Architecture Life Cycle: Work Products: Architecture Design I 31.
Architecture Life Cycle: Work Products: Architecture Design II 32.
Perspective Select sources based on component specificationsSatisfy cost objectives Define level of effort for component provisioning Carefully weigh benefits of buy vs. build Develop components as a last resort Architecture Life Cycle: Work Products: Provisioning 33.
Perspective Treat validation as a distinct task Apply validation entry and exit conditions Ensure artifacts are in shape for validation Validate conformance of artifacts to specifications Document evidence for conformance Iterate validation and rework until artifacts pass Use validation defect rates to manage quality Architecture Life Cycle: Work Products: Validation 34.
Perspective Define deliverables for vendor agreements Perform due diligence on vendor capabilities Define checkpoints for assessing vendor progress Define testable acceptance criteria for deliverables Define implications of acceptance failure Manage risk with plan B for critical components Architecture Life Cycle: Work Products: Vendor Agreements 35.
Perspective Define environment early to drive staffing and training Define steps so that systemaccumulates into final form Be prepared for development feedback to architectureEvaluate early increments wrt required propertiesArchitecture Life Cycle: Work Products: Development Plan 36. Architecture FundamentalsArchitecture Practices Client Environment:enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final RequirementsPrototypes & Models Architecture Design Architecture ProvisioningArchitecture Validation VendorAgreements Development Plan INPUTS WORK PRODUCTS ITERATIVE ARCHITECTURE DEVELOPMENT Ent. Arch., Legacy, Reqs., Market, Domain, Enablers Env. and Steps Analysis Devel. Planning Schedule Mgmt. Plan Planning (Architecture Development) Architecture Life Cycle: Arch. Development 37.
Perspective Failure to meet schedule is a non-starterSurface schedule-impacting problems early Work at level of abstraction compatible with schedule Architecture Life Cycle: Arch. Development: Schedule 38.
Perspective Plan is a sequencing of tasks plus risk management Define tasks to accumulate into work products Use the plan to manage the architecture work Track actual vs. predicted performance Discovery/experimentation tasks can reduce riskArchitecture Life Cycle: Arch. Development: Management Plan 39.
Perspective Never stop learning about the problem and resources Architecture Life Cycle: Arch. Development: Analysis 40.
Perspective Consult with developers to arrive at a consensus plan Consult with customers on staging of deliverables Architecture Life Cycle: Arch. Development: Development Planning 41. Architecture FundamentalsArchitecture Practices Client Environment:enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final RequirementsPrototypes & Models Architecture Design Architecture ProvisioningArchitecture Validation VendorAgreements Development Plan INPUTS WORK PRODUCTS ITERATIVE ARCHITECTURE DEVELOPMENT External Behavior Data & Software Hardware & Network Design Refine Refine Refine Design Design Ent. Arch., Legacy, Reqs., Market, Domain, Enablers Env. and Steps Validation Checkpoint Analysis Inspection Devel. Planning IterationsSchedule Mgmt. Plan Planning Architecture Life Cycle: Arch. Development: Design Activities 42.
Perspective Refinement process allows divide, connect, and conquer strategy Refinement helps maintain intellectual control Refinements can be verified wrt their specifications Cant design the top without knowing the bottom Last intellectual passis top down Architecture Life Cycle: Arch. Development: The Refinement Process 43.
Perspective Use iteration to achieve informed agreement Use iteration to uncover gaps and misunderstandings Continually challenge assumptions and decisions Architecture Life Cycle: Arch: Development: The Iteration Process