Architecture Definition & Analysis Survivable Network Analysis Security  Architectures Security Architecture and Analysis:...
<ul><li>Security Architecture and Analysis:  Session 2a </li></ul><ul><li>Topics: </li></ul><ul><li>Session 1 Review </li>...
Session 1 Review
REVIEW: Architecture Defined <ul><li>An information system architecture </li></ul><ul><li>is a  specification  for  develo...
REVIEW: Concepts of System Architectures  <ul><li>Architectures are comprised of components and connectors: </li></ul><ul>...
REVIEW: Concepts of System Architectures  <ul><li>Architecture properties: </li></ul><ul><ul><li>Functional properties </l...
REVIEW: Architectural Styles Example: A Bank ATM System Style: Hierarchical, client server, layered ATM ATM ATM ATM ... AT...
Presentation Business Rules Data Access DBMS Fat Client Two Tiers Desktop: Server(s): Presentation Business Rules Data Acc...
REVIEW: Architecture Impact of COTS Products <ul><li>Long history </li></ul><ul><ul><li>Started with environment support <...
REVIEW: An Architecture Framework Architecture Best Practices: Enterprise modeling and requirements specification Applicat...
REVIEW: Box Structure Reasoning for Components  <ul><li>Box Structures </li></ul><ul><ul><li>A systematic model for compon...
<ul><li>The example of  black box behavior:   A hand calculator  </li></ul>REVIEW: Box Structure Reasoning for Components:...
<ul><li>Opens up a black box to reveal retained data; allows reasoning about  </li></ul><ul><li>the state  </li></ul><ul><...
REVIEW: Compositional Reasoning for Networks A Bank ATM System ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM ATM ATM ATM ......
REVIEW: Compositional Reasoning for Networks <ul><li>What happens from viewpoint of ATM user submitting a transaction? </l...
REVIEW: Compositional Reasoning for Networks <ul><li>Another pin number composition  </li></ul>ATM Server ATM Server ATM S...
REVIEW: Compositional Reasoning for Networks When you buy gas at a pump with a speedpass, what is a possible architecture ...
REVIEW: Compositional Reasoning for Networks  <ul><li>Many systems are designed to preserve composition and isolate </li><...
Architecture Life Cycle, Work Products,  and Processes
Architecture Fundamentals  Architecture Practices Client Environment:  enterprise arch. legacy systems initial requirement...
<ul><li>If it exists and is current </li></ul><ul><ul><li>May define business models </li></ul></ul><ul><ul><li>May define...
<ul><li>Legacy reuse and integration </li></ul><ul><ul><li>Data, software, and networks involved </li></ul></ul><ul><ul><l...
<ul><li>Often not fully known by client </li></ul><ul><ul><li>Effective requirements discovery is essential </li></ul></ul...
<ul><li>Partners and alliances  </li></ul><ul><ul><li>Partnering can reduce costs and spread risk </li></ul></ul><ul><li>C...
<ul><li>EAI architectures  </li></ul><ul><ul><li>Data-, application-, portal-, process-oriented, … </li></ul></ul><ul><ul>...
<ul><li>Computation & communication hardware </li></ul><ul><ul><li>Processing power and bandwidth  </li></ul></ul><ul><ul>...
Architecture Fundamentals  Architecture Practices Client Environment:  enterprise arch. legacy systems initial requirement...
<ul><li>Discovery and reconciliation </li></ul><ul><ul><li>Requirements analysis with client </li></ul></ul><ul><ul><li>Us...
<ul><li>Prototype goals </li></ul><ul><ul><li>Requirements elicitation and finalization </li></ul></ul><ul><ul><li>Proof o...
<ul><li>Architecture is the integrating foundation of the project </li></ul><ul><ul><li>A complete abstraction of the fina...
<ul><li>Architecture defines </li></ul><ul><ul><li>External behavior design (system specification) </li></ul></ul><ul><ul>...
<ul><li>Provide specifications for every component </li></ul><ul><ul><li>Function </li></ul></ul><ul><ul><li>Usage  </li><...
<ul><li>Validate architecture functionality </li></ul><ul><ul><li>Every required user function must be present </li></ul><...
<ul><li>Architecture is a driver of vendor agreements </li></ul><ul><ul><li>Incorporates vendor components </li></ul></ul>...
<ul><li>Defines development environment </li></ul><ul><ul><li>Enabling technologies </li></ul></ul><ul><ul><li>Development...
Architecture Fundamentals  Architecture Practices Client Environment:  enterprise arch. legacy systems initial requirement...
<ul><li>Embedded within project schedule </li></ul><ul><ul><li>Supports project dependencies </li></ul></ul><ul><li>Entry ...
<ul><li>Defines work products </li></ul><ul><ul><li>Project-specific architecture artifacts </li></ul></ul><ul><li>Defines...
<ul><li>Understand the client and resources </li></ul><ul><ul><li>Client problem </li></ul></ul><ul><ul><ul><li>Enterprise...
<ul><li>Define development environment </li></ul><ul><li>Define development and testing steps  </li></ul>Perspective Consu...
Architecture Fundamentals  Architecture Practices Client Environment:  enterprise arch. legacy systems initial requirement...
<ul><li>External behavior design maps requirements into specifications </li></ul><ul><li>External behavior design plus net...
<ul><li>The first idea is rarely the best idea </li></ul><ul><li>Iteration drives evaluation and improvement </li></ul><ul...
Upcoming SlideShare
Loading in...5
×

Lecture 2a charts.ppt

811

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
811
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lecture 2a charts.ppt

  1. 1. Architecture Definition & Analysis Survivable Network Analysis Security Architectures Security Architecture and Analysis: Course Roadmap Architecture Development Management Session 1 (Linger) What: Methods for defining and reasoning about system architectures. Why: The architecture level is cost-effective and intellectually manageable for analysis and design of system security and survivability capabilities. Session 2, 3a (Linger) What: Survivability analysis improves preservation of critical mission capabilities. Why: No amount of security can guarantee that systems will not be compromised; essential services and assets must be maintained. Sessions 4, 6, 7. 9, 11 (Longstaff) What: Analysis of vulnerabilities and methods for improving system security. Why: System security can be improved by a variety of techniques at the network, operating system, and application level. Session 13 (Linger) What: Architecture development with COTS components Why: Most security vulnerabilities are the result of poor system development and acquisition practices. From a security perspective, good practices and management methods are critically important. <ul><li>Plus: </li></ul><ul><li>Student team project in survivability analysis (Mead) </li></ul><ul><li>Guest lectures on special topics </li></ul><ul><li>Student presentations </li></ul>
  2. 2. <ul><li>Security Architecture and Analysis: Session 2a </li></ul><ul><li>Topics: </li></ul><ul><li>Session 1 Review </li></ul><ul><li>Architecture Life Cycle, Work Products, and Processes </li></ul>
  3. 3. Session 1 Review
  4. 4. REVIEW: Architecture Defined <ul><li>An information system architecture </li></ul><ul><li>is a specification for development of a system </li></ul><ul><li>composed of hardware and software components and connectors </li></ul><ul><li>whose external behavior satisfies the enterprise mission and </li></ul><ul><li>business requirements </li></ul>Enterprise mission and business requirements System architecture System development System operation Validate Design Validate Design
  5. 5. REVIEW: Concepts of System Architectures <ul><li>Architectures are comprised of components and connectors: </li></ul><ul><li>Components (Computation) </li></ul><ul><ul><li>Hardware: </li></ul></ul><ul><li>Workstations, servers, mainframes, printers, sensors, actuators, … </li></ul><ul><ul><li>Software: </li></ul></ul><ul><li>Operating systems, data base systems, middleware, </li></ul><ul><ul><ul><li>browsers, applications, utilities, firewalls, ... </li></ul></ul></ul><ul><li>Connectors (Communication) </li></ul><ul><ul><li>Hardware: </li></ul></ul><ul><ul><li>Communication links: routers, switches, public telephone </li></ul></ul><ul><ul><li>network, leased lines, virtual private networks, … </li></ul></ul><ul><ul><li>Software: </li></ul></ul><ul><ul><li>Communication protocols: TCP/IP, SNMP, HTTP, FTP …, Linkage </li></ul></ul><ul><ul><li>conventions: procedure calls, remote procedure calls, thread </li></ul></ul><ul><ul><li>initiation, ... </li></ul></ul>
  6. 6. REVIEW: Concepts of System Architectures <ul><li>Architecture properties: </li></ul><ul><ul><li>Functional properties </li></ul></ul><ul><ul><ul><li>Must satisfy domain-specific functional requirements </li></ul></ul></ul><ul><ul><ul><li>and specifications </li></ul></ul></ul><ul><ul><li>Non-functional properties (the “ilities”) </li></ul></ul><ul><ul><ul><li>Must satisfy performance, availability, reliability, safety, security, survivability, maintainability, usability, manageability, … properties </li></ul></ul></ul><ul><li>Architecture trade-offs: </li></ul><ul><ul><li>Properties can conflict </li></ul></ul><ul><ul><li>Trade-offs seek optimal combinations of properties </li></ul></ul><ul><ul><li>based on cost/benefit analysis </li></ul></ul>
  7. 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 Layer Domain/Enterprise Logic/ Data Layer
  8. 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 Gartner’s Two-Tier and Multi-Tier Enterprise Architectures:
  9. 9. REVIEW: Architecture Impact of COTS Products <ul><li>Long history </li></ul><ul><ul><li>Started with environment support </li></ul></ul><ul><ul><ul><li>Operating systems, data bases, language processors, … </li></ul></ul></ul><ul><ul><li>Moving up the food chain </li></ul></ul><ul><ul><li>Specialized applications, middleware, network services, ... </li></ul></ul><ul><li>Most architectures today are “assembled” from COTS products </li></ul><ul><ul><li>Domain-specific vendors </li></ul></ul><ul><ul><li>Bend business processes to match software capabilities </li></ul></ul><ul><ul><li>“ Glue code” ties incompatible products together </li></ul></ul><ul><li>COTS characteristics: </li></ul><ul><ul><li>Ties your system capability and evolution to vendors </li></ul></ul><ul><ul><li>Cost savings possible, but risks must be managed </li></ul></ul><ul><ul><li>Functionality and security are what vendor says they are </li></ul></ul><ul><ul><ul><li>Actual capabilities may differ </li></ul></ul></ul><ul><ul><li>Source code usually not available </li></ul></ul><ul><ul><li>Knowledge of quality and reliability difficult to acquire </li></ul></ul><ul><ul><li>Acceptance testing and configuration management are critical </li></ul></ul>
  10. 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, & usage requirements 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 validation Architecture patterns and properties COTS evaluation and integration Ability to Develop Marketplace Environment: Partners and alliances COTS 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 systems Operating systems Hardware and Network View (Physical Infrastructure): Computing hardware: servers, mainframes, PCs,mass storage, … Networks, wired & wireless: media, devices, topology, protocols System Requirements: function, and properties of reliability, performance, scalability, security, usability, cost, … SYSTEM ARCHITECTURE
  11. 11. REVIEW: Box Structure Reasoning for Components <ul><li>Box Structures </li></ul><ul><ul><li>A systematic model for component analysis and design </li></ul></ul><ul><ul><li>Five fundamental component characteristics: “ BURST” </li></ul></ul><ul><ul><ul><li>Boundary: What is inside and what is outside? </li></ul></ul></ul><ul><ul><ul><li>Users: Who are the users? </li></ul></ul></ul><ul><ul><ul><li>Responses: What is the set of possible responses? </li></ul></ul></ul><ul><ul><ul><li>Stimuli: What is the set of possible stimuli? </li></ul></ul></ul><ul><ul><ul><li>Transactions: What are the possible mappings from stimuli to responses? </li></ul></ul></ul><ul><ul><li>Three fundamental component representations: </li></ul></ul><ul><ul><ul><li>Black box: Component behavior based on history of use </li></ul></ul></ul><ul><ul><ul><li>State Box: Component behavior based on retained data </li></ul></ul></ul><ul><ul><ul><li>Clear box: Component behavior based on procedure (another course!) </li></ul></ul></ul>
  12. 12. <ul><li>The example of black box behavior: A hand calculator </li></ul>REVIEW: Box Structure Reasoning for Components: Black Boxes <ul><li>The black box of a component in diagram form </li></ul>Stimulus (S) Response (R) Stimulus Stimulus history Response 716 5 7165 716C 5 5 <ul><li>Black box behavior depends on more than the current stimulus, </li></ul><ul><li>it also depends on the history of use </li></ul><ul><li>Transition function of a black box description </li></ul><ul><li>(stimulus history, stimulus)  (response) </li></ul>
  13. 13. <ul><li>Opens up a black box to reveal retained data; allows reasoning about </li></ul><ul><li>the state </li></ul><ul><li>Transition function of a state box description </li></ul><ul><ul><li>(stimulus, current state) --> (response, new state) </li></ul></ul>REVIEW: Box Structure Reasoning for Components: State Boxes <ul><li>The state box of a component in diagram form </li></ul>Stimulus (S) Response (R) state trans
  14. 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 Layer Domain/Enterprise Logic/ Data Layer
  15. 15. REVIEW: Compositional Reasoning for Networks <ul><li>What happens from viewpoint of ATM user submitting a transaction? </li></ul>ATM Server Mainframe Server ATM <ul><ul><li>[User] o [ATM] o [server] o [mainframe] o [server] o [ATM] o [User] </li></ul></ul><ul><ul><ul><li>“ o” is composition operator </li></ul></ul></ul><ul><ul><ul><li>“ [, ]” denote the transition function of the component </li></ul></ul></ul><ul><ul><ul><li>Note that each use of a component is in the composition </li></ul></ul></ul><ul><li>Component compositions are also known as architecture traces </li></ul><ul><li>ATM Security: Composition with wrong pin number (U for user) </li></ul>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. 16. REVIEW: Compositional Reasoning for Networks <ul><li>Another pin number composition </li></ul>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 <ul><li>Compositional reasoning is concerned with the net effect of </li></ul><ul><li>all the components in a composition </li></ul><ul><li>Net effect means the overall change </li></ul><ul><ul><li>From the stimuli to the first component </li></ul></ul><ul><ul><li>To the response from the last component </li></ul></ul>U U U U U U U U U U U
  17. 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. 18. REVIEW: Compositional Reasoning for Networks <ul><li>Many systems are designed to preserve composition and isolate </li></ul><ul><li>asynchronous behavior </li></ul><ul><li>Bank system preserves independence of transactions based on </li></ul><ul><li>account numbers </li></ul><ul><li>In general, systems are designed for compositional operations </li></ul>A Bank ATM System ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM ATM ATM ATM ... Server Server ... Mainframe Server Users Users ...
  19. 19. Architecture Life Cycle, Work Products, and Processes
  20. 20. Architecture Fundamentals Architecture Practices Client Environment: enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies INPUTS Architecture Life Cycle: Inputs
  21. 21. <ul><li>If it exists and is current </li></ul><ul><ul><li>May define business models </li></ul></ul><ul><ul><li>May define IT infrastructure </li></ul></ul><ul><ul><li>May define evolutionary objectives </li></ul></ul><ul><ul><li>May provide guidance for architecture development </li></ul></ul><ul><li>If it exists and is not current </li></ul><ul><ul><li>Opportunity to update </li></ul></ul><ul><ul><li>Guidance is suspect </li></ul></ul>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 Def’n
  22. 22. <ul><li>Legacy reuse and integration </li></ul><ul><ul><li>Data, software, and networks involved </li></ul></ul><ul><ul><li>Potential major costs or savings </li></ul></ul><ul><ul><li>Impacts architecture, development, & deployment </li></ul></ul><ul><li>Many alternatives possible </li></ul><ul><ul><li>Wrapping, rewriting, transforming, rehosting, … </li></ul></ul><ul><li>Decision making </li></ul><ul><ul><li>Legacy systems are often difficult to modernize </li></ul></ul><ul><ul><li>Assessment of legacy capabilities is crucial </li></ul></ul><ul><ul><li>Business valuation of legacy assets </li></ul></ul><ul><ul><li>is crucial </li></ul></ul><ul><ul><li>New uses for old data </li></ul></ul><ul><ul><li>Business case, cost/benefit analysis </li></ul></ul>Perspective Analyze legacy capabilities wrt client requirements Understand evolution plans for legacy assets Treat legacy integration on a par with new components Architect for firm future uses of legacy elements Architecture Life Cycle: Inputs: Legacy systems
  23. 23. <ul><li>Often not fully known by client </li></ul><ul><ul><li>Effective requirements discovery is essential </li></ul></ul><ul><ul><li>Enterprise and business models are the basis </li></ul></ul><ul><li>Functional requirements </li></ul><ul><ul><li>User tasks and workflows </li></ul></ul><ul><ul><li>System services and transactions </li></ul></ul><ul><ul><li>Use cases are a popular method </li></ul></ul><ul><li>Usage requirements </li></ul><ul><ul><li>User types and roles </li></ul></ul><ul><ul><li>Usage patterns and traffic levels </li></ul></ul><ul><li>Non-functional (property) requirements </li></ul><ul><ul><li>Reliability, performance, scalability, </li></ul></ul><ul><ul><li>security, survivability, usability, cost, … </li></ul></ul>Perspective Never architect against presumed requirements Avoid late-life-cycle requirements surprises Iterate requirements definition with clients Involve all client roles and stakeholders Treat requirements as an architecture entry condition Develop prototypes to elicit requirements from clients Establish requirements baselines to manage change and prevent scope creep Architecture Life Cycle: Inputs: Initial Requirements
  24. 24. <ul><li>Partners and alliances </li></ul><ul><ul><li>Partnering can reduce costs and spread risk </li></ul></ul><ul><li>COTS products </li></ul><ul><ul><li>Extensive, comprehensive capabilities available </li></ul></ul><ul><ul><li>Vendor capability and track record can be issues </li></ul></ul><ul><ul><li>Product function and quality can be issues </li></ul></ul><ul><ul><li>Trend to standard, integrated solutions </li></ul></ul><ul><li>User groups and standards </li></ul><ul><ul><li>Provide experience benchmark, </li></ul></ul><ul><ul><li>enable interoperability </li></ul></ul>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 others Architecture Life Cycle: Inputs: Marketplace Environment
  25. 25. <ul><li>EAI architectures </li></ul><ul><ul><li>Data-, application-, portal-, process-oriented, … </li></ul></ul><ul><ul><li>XML, middleware, RPCs, message brokers, … </li></ul></ul><ul><ul><li>Packages: SAP, PeopleSoft, BizTalk, … </li></ul></ul><ul><li>E-commerce architectures </li></ul><ul><ul><li>B2C, B2B, B2G, G2C… </li></ul></ul><ul><ul><li>Content, payments, orders, fulfillment, … </li></ul></ul><ul><ul><li>Security, trust, privacy, QoS… </li></ul></ul><ul><ul><li>Packages, ISPs, … </li></ul></ul><ul><li>Industry standard architectures </li></ul>Perspective Capitalize on applicable domain architectures Maintain knowledge of evolving domain methods Architecture Life Cycle: Inputs: Domain Architectures
  26. 26. <ul><li>Computation & communication hardware </li></ul><ul><ul><li>Processing power and bandwidth </li></ul></ul><ul><ul><li>Intel, Cisco, … </li></ul></ul><ul><ul><li>Hardware in continual evolution </li></ul></ul><ul><li>Integration environments </li></ul><ul><ul><li>Applications, middleware, operating systems, … </li></ul></ul><ul><ul><li>Microsoft, Sun, Oracle, … </li></ul></ul><ul><ul><li>Environments in continual evolution </li></ul></ul><ul><li>Integration enablers </li></ul><ul><ul><li>HTML, XML, security, … </li></ul></ul><ul><ul><li>Enablers in continual evolution </li></ul></ul>Perspective Maintain knowledge of evolving technologies Where possible, build on existing client environments Recognize enabler selections tie clients to supply chains Architect for component and environment evolution Architecture Life Cycle: Inputs: Enabling Technologies
  27. 27. Architecture Fundamentals Architecture Practices Client Environment: enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final Requirements Prototypes & Models Architecture Design Architecture Provisioning Architecture Validation Vendor Agreements Development Plan INPUTS WORK PRODUCTS Architecture Life Cycle: Work Products
  28. 28. <ul><li>Discovery and reconciliation </li></ul><ul><ul><li>Requirements analysis with client </li></ul></ul><ul><ul><li>User experience with prototypes </li></ul></ul><ul><ul><li>User needs vs. product capabilities </li></ul></ul><ul><li>Requirements trade-offs </li></ul><ul><ul><li>Optimal non-functional property mix </li></ul></ul><ul><ul><li>Functional trade-offs: </li></ul></ul><ul><li>Goal is no project impact </li></ul><ul><ul><li>Customer understands trade-offs </li></ul></ul><ul><ul><li>Customer agrees to requirements baseline </li></ul></ul><ul><ul><li>Schedule and budget remain intact </li></ul></ul>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 doesn’t 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. 29. <ul><li>Prototype goals </li></ul><ul><ul><li>Requirements elicitation and finalization </li></ul></ul><ul><ul><li>Proof of concept </li></ul></ul><ul><li>Model goals </li></ul><ul><ul><li>Simulation, prediction of system performance </li></ul></ul><ul><ul><li>Proof of concept </li></ul></ul><ul><li>Prototyping and Modeling </li></ul><ul><ul><li>Key risk management strategies </li></ul></ul><ul><ul><li>Can be a phase in multi-phase project </li></ul></ul>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 inputs Match modeling effort to project stakes Architecture Life Cycle: Work Products: Prototypes & Models
  30. 30. <ul><li>Architecture is the integrating foundation of the project </li></ul><ul><ul><li>A complete abstraction of the final system </li></ul></ul><ul><ul><li>Defers details without losing them </li></ul></ul><ul><ul><li>Development and usage become envisionable </li></ul></ul><ul><ul><li>Basis for reasoning, discussions, and decisions </li></ul></ul><ul><li>Satisfies client needs </li></ul><ul><ul><li>Functional and non-functional requirements </li></ul></ul><ul><ul><li>Traceability of requirements into architecture is important </li></ul></ul><ul><li>Prescribes system development </li></ul><ul><ul><li>Architecture should leave nothing out at </li></ul></ul><ul><ul><li>its level of abstraction </li></ul></ul><ul><ul><li>Development should refine, not </li></ul></ul><ul><ul><li>invent, architecture </li></ul></ul>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. 31. <ul><li>Architecture defines </li></ul><ul><ul><li>External behavior design (system specification) </li></ul></ul><ul><ul><ul><li>User tasks and workflows </li></ul></ul></ul><ul><ul><ul><li>Stimulus/response behavior </li></ul></ul></ul><ul><ul><li>Data and software design (logical infrastructure) </li></ul></ul><ul><ul><ul><li>Retained state, application software, … </li></ul></ul></ul><ul><ul><ul><li>Middleware, operating systems, databases, … </li></ul></ul></ul><ul><ul><ul><li>Partitioning of function and data in an architectural style </li></ul></ul></ul><ul><ul><li>Hardware and network design (physical infrastructure) </li></ul></ul><ul><ul><ul><li>Servers, mainframes, PCs, … </li></ul></ul></ul><ul><ul><ul><li>Media, devices, topology, protocols, … </li></ul></ul></ul><ul><ul><li>Non-functional properties </li></ul></ul><ul><ul><ul><li>Property definitions </li></ul></ul></ul><ul><ul><ul><li>How properties are satisfied </li></ul></ul></ul><ul><ul><li>User skills and training </li></ul></ul>Architecture Life Cycle: Work Products: Architecture Design II
  32. 32. <ul><li>Provide specifications for every component </li></ul><ul><ul><li>Function </li></ul></ul><ul><ul><li>Usage </li></ul></ul><ul><ul><li>Non-functional properties </li></ul></ul><ul><li>Provide source for every component </li></ul><ul><ul><li>As-is or modified legacy or COTS </li></ul></ul><ul><ul><li>As-is or modified partner product </li></ul></ul><ul><ul><li>Enabling environment or technology </li></ul></ul><ul><ul><li>New development </li></ul></ul><ul><ul><li>ISP, ASP, … </li></ul></ul><ul><ul><li>Various combinations </li></ul></ul>Perspective Select sources based on component specifications Satisfy 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. 33. <ul><li>Validate architecture functionality </li></ul><ul><ul><li>Every required user function must be present </li></ul></ul><ul><ul><li>All functions must operate harmoniously </li></ul></ul><ul><li>Validate non-functional properties </li></ul><ul><ul><li>Every required property must be satisfied </li></ul></ul><ul><ul><li>All properties must co-exist harmoniously </li></ul></ul><ul><li>Validation processes </li></ul><ul><ul><li>Verify “as-designed” against “as-specified” </li></ul></ul><ul><ul><li>Many methods may be employed </li></ul></ul><ul><ul><li>Team inspections are a key technique </li></ul></ul>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. 34. <ul><li>Architecture is a driver of vendor agreements </li></ul><ul><ul><li>Incorporates vendor components </li></ul></ul><ul><ul><li>Basis for development plan </li></ul></ul><ul><ul><li>Defines component deliverables </li></ul></ul><ul><ul><ul><li>Provisioning strategies </li></ul></ul></ul><ul><ul><ul><li>Requirements and specifications </li></ul></ul></ul><ul><ul><li>Defines service deliverables </li></ul></ul><ul><ul><ul><li>Scope and QoS </li></ul></ul></ul><ul><ul><ul><li>Staffing and skills </li></ul></ul></ul>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. 35. <ul><li>Defines development environment </li></ul><ul><ul><li>Enabling technologies </li></ul></ul><ul><ul><li>Development and testing processes </li></ul></ul><ul><li>Defines development steps </li></ul><ul><ul><li>Incremental development is essential </li></ul></ul><ul><ul><li>Stepwise completion of system parts </li></ul></ul><ul><ul><li>Client feedback from early increments </li></ul></ul><ul><ul><li>Tasks and schedules </li></ul></ul>Perspective Define environment early to drive staffing and training Define steps so that system accumulates into final form Be prepared for development feedback to architecture Evaluate early increments wrt required properties Architecture Life Cycle: Work Products: Development Plan
  36. 36. Architecture Fundamentals Architecture Practices Client Environment: enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final Requirements Prototypes & Models Architecture Design Architecture Provisioning Architecture Validation Vendor Agreements 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. 37. <ul><li>Embedded within project schedule </li></ul><ul><ul><li>Supports project dependencies </li></ul></ul><ul><li>Entry conditions (rarely satisfied) </li></ul><ul><ul><li>Stable and complete requirements </li></ul></ul><ul><ul><li>Availability of appropriate staff and resources </li></ul></ul><ul><li>Exit condition </li></ul><ul><ul><li>Architecture work products are complete and validated </li></ul></ul>Perspective Failure to meet schedule is a non-starter Surface schedule-impacting problems early Work at level of abstraction compatible with schedule Architecture Life Cycle: Arch. Development: Schedule
  38. 38. <ul><li>Defines work products </li></ul><ul><ul><li>Project-specific architecture artifacts </li></ul></ul><ul><li>Defines tasks </li></ul><ul><ul><li>Activities that will produce the work products </li></ul></ul><ul><li>Defines internal schedules and resources </li></ul><ul><ul><li>Task sequencing and resource allocation </li></ul></ul><ul><li>Defines risks and mitigations </li></ul><ul><ul><li>Key risks and uncertainties </li></ul></ul><ul><ul><li>Actions for recognition and control </li></ul></ul>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 risk Architecture Life Cycle: Arch. Development: Management Plan
  39. 39. <ul><li>Understand the client and resources </li></ul><ul><ul><li>Client problem </li></ul></ul><ul><ul><ul><li>Enterprise architecture and business models </li></ul></ul></ul><ul><ul><ul><li>Legacy systems </li></ul></ul></ul><ul><ul><ul><li>Requirements </li></ul></ul></ul><ul><ul><ul><li>From present operations to envisioned future operations </li></ul></ul></ul><ul><ul><li>Potential resources </li></ul></ul><ul><ul><ul><li>Marketplace offerings </li></ul></ul></ul><ul><ul><ul><li>Domain architectures </li></ul></ul></ul><ul><ul><ul><li>Enabling technologies </li></ul></ul></ul><ul><li>A project-long activity </li></ul><ul><ul><li>May require experimentation, training </li></ul></ul><ul><ul><li>Document understandings for decision-making </li></ul></ul>Perspective Never stop learning about the problem and resources Architecture Life Cycle: Arch. Development: Analysis
  40. 40. <ul><li>Define development environment </li></ul><ul><li>Define development and testing steps </li></ul>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. 41. Architecture Fundamentals Architecture Practices Client Environment: enterprise arch. legacy systems initial requirements Marketplace Environment Domain Architectures Enabling Technologies Final Requirements Prototypes & Models Architecture Design Architecture Provisioning Architecture Validation Vendor Agreements 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 Iterations Schedule Mgmt. Plan Planning Architecture Life Cycle: Arch. Development: Design Activities
  42. 42. <ul><li>External behavior design maps requirements into specifications </li></ul><ul><li>External behavior design plus network traffic, etc., drives data and software design </li></ul><ul><li>Data and software design plus network traffic, geography, etc., drives hardware and network design </li></ul><ul><li>Non-functional requirements drive everything </li></ul><ul><li>System evolution requirements drive everything </li></ul>Perspective Refinement process allows divide, connect, and conquer strategy Refinement helps maintain intellectual control Refinements can be verified wrt their specifications Can’t design the top without knowing the bottom Last intellectual pass is top down Architecture Life Cycle: Arch. Development: The Refinement Process
  43. 43. <ul><li>The first idea is rarely the best idea </li></ul><ul><li>Iteration drives evaluation and improvement </li></ul><ul><li>Iteration permits systematic convergence to a solution </li></ul><ul><li>Iteration has desirable properties similar to requirements change control </li></ul><ul><li>Iterations document design decisions </li></ul>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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×