Introduction to Enterprise Architecture, Exams of Computer Networks

Download Introduction to Enterprise Architecture and more Exams Computer Networks in PDF only on Docsity! 1 Software Engineering Session 5 – Main Theme High-Level Analysis and Design Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 2 3 Architecture Blueprinting 4 Sample Architecture Blueprints Agenda 1 Introduction 5 Architectural Mapping Process Illustrated 7 Summary and Conclusion 2 High-Level Analysis and Design 6 Reference Architecture Cataloguing Framework 5 Icons / Metaphors 5 Common Realization Information Knowledge/Competency Pattern Governance Alignment Solution Approach 6 3 Architecture Blueprinting 4 Sample Architecture Blueprints Agenda 1 Introduction 5 Architectural Mapping Process Illustrated 7 Summary and Conclusion 2 High-Level Analysis and Design 6 Reference Architecture Cataloguing Framework 7 High-Level Analysis and Design  The goal of high-level analysis and design is to quickly produce a high-level model that reflects the current understanding of the future state architecture  This high-level model is helpful in putting together high-level program/project estimate and providing a view of the future state that can be used as a starting point  Various architecture models may be used to represent this view and they are typically based on blueprinting notations/process and blueprints that have been standardized within the Enterprise working on the high-level analysis and design  There are currently no industry standard blueprinting notation/process and/or blueprints; the blueprinting process typically goes top down to document the various facets of the future state architecture starting from the Enterprise level and going through the business, and technology architectures  Technology architecture blueprinting can be conducted in parallel at the application, data, and technical levels Sample Application Server Reference Architecture 4 DESIGN/DEVELOP => JBoss Developer Studio Fully integrated Seon dev environment De Uae ET Migrated | 10 11 Reference Architecture Models  A “reference” architecture model is an accepted representation of the architecture that drives the mapping of business capabilities onto IT capabilities  A reference architecture model may not represent any specific organization needs  A reference architecture model is rarely developed using a top-down or bottom-up approach, it is typically put together by integrating requirements from various architectural domains according to accepted heuristics (e.g., reuse via unification or best practices / standardization) and using accepted frameworks 12 Enterprise Architecture Modeling Heuristics Coordination Shared customers / products / product data / suppliers Operationally autonomous and unique business units  Transactions impact other business units Unification  Customers and suppliers may be local or global Business units with similar or overlapping operations Globally integrated business processes supported by Enterprise systems Diversification  Few, if any, shared customers or suppliers  Operationally autonomous and unique business units  Independent transactions Replication  Few, if any, shared customers  Operationally similar business units Independent transactions aggregated at a higher level Autonomous business units with limited discretion over processes B u s in e s s p ro c e s s i n te g ra ti o n High Low Business process standardization High Optional Required Key customers Linked and standard (core) processes Shared data Linking and automating technologies Shared customers Shared data Integrating technology Linked processes 15 Sample Architecture and Solution Engineering Asset Catalog Business A n a ly s is /D e s ig n P ro d u c t Im p le m e n ta ti o n D e p lo y m e n tA rc h it e c tu re a n d S o lu ti o n E n g in e e ri n g V ie w s Information Application Technology Enterprise Perspectives  In this context, relevant views are those that match the phases of an solution development life cycle 16 Conceptual business architecture framework <> Business Channels BPM Processes Business Services Business Entities Product Development Underwriting Finance and Accounting Servicing Claim Processing Sales and Marketing Business Capabilities Business Users Business Events Process metrics BRM Rules Value Chain Bond Business Users Agents/ B2B Partners Bond Business Users Agents/ B2B Partners $$ Customers Bond Business Users Agents/ B2B Partners $$ Customers Public Bond Business Users Bond Business Users Agents/ B2B Partners Bond Business Users Agents/ B2B Partners $$ Customers Public Claims Enterprise Business Unit Surety Management Liability 17 Underwriting <> Business Channels BPM Processe s Business Services Business Entities Business Capabiliti es Business Users Business Events Process metrics BRM Rules Value Chain Product Selection Submission Rate Quote* Bind Bill and Issue Agent Portal Underwriting via agent self service and Straight Through Processing Agents/ B2B Partners Agents/ B2B Partners Agents/ B2B Partners Agents/ B2B Partners New Business Fulfillment Product browser UI Submission UI Bind UI eDoc delivery UI # of Products selected by agents Submission counts by agents/products Count of ratings delivered Count of exceptions Count of successful bids Number of policies issued Product category, Related product rules Submission validation Form selection Rating Binding Billing, Delivery routing Product selector, Product info publisher Submission data capture Questionnaire builder Form selector Rating service Quote publisher Binding service Electronic signature capture ePOA Billing configuration Delivery manager Agent profile, Product catalogue Form templates, Form metadata, Submission data Ratable data, Rating decision, Rates, Quotes Binding data, Policy data Policy/Bond data, Power of Attorney data, Billing data Conceptual Business Architecture Framework Illustration 20 What is a Blueprint?  A blueprint is an architectural drawing » Created using a consistent representation to represent a high-level model of the as-it, to-be, or in- transition IT environment  Unlike UML models, which are software engineering level diagrams, blueprints are at an architectural-level of detail and provide the context needed to visualize the “big picture” » As such, blueprints are analogous to the “city- planning” level in the building construction industry » They enable architects to communicate the overall design of the city as opposed to the design of the individual buildings that make up the city 21 What Does a Blueprint Look Like and How is it Used?  The appearance of a blueprint varies considerably depending upon a number of factors including: » The architectural domain being modeled (e.g., application architecture versus technical architecture) » The scope of the blueprint (e.g., Enterprise, Portfolio, Project) » The level of abstraction (e.g., Presentation, Conceptual, Logical, Physical) » The communication objectives of the model  Blueprints are also used to document and define three different states of technology evolution » A current state called the As-Is or POD » A future state called the To-Be or POA (typically 12 - 24 months out) » One or more transition states, each one called a Transition or planned landing point between the as-is and to-be state • Once implemented, a Transition represents a new As-Is state 22 Why is there a Need for a Common Way to Document Architectures?  In the absence of standardized blueprinting techniques, architectural models would be highly individualized and would range from artifacts that may be fairly structured to models that would be very general and stylistic  As a result, the readers interpreting the models would be required to ask (and assume an answer to) a number of critical questions including: » What concepts is the model attempting to explain? » Are the concepts highly abstract or is the model depicting a precise design? » What do the symbols on the diagram represent? » What architecture domain is being modeled? » Does the design apply to the Enterprise as a whole, a LOB, a portfolio, or a project? » Does the model represent the As-Is , To-Be, or Transition architecture? » If the model represents a Transition architecture, what changes to the IT environment are being planned? » etc. 25 Legend Box  The Legend Box is a text box that must appear on all blueprints. It is used to denote important information that is needed by the reader to correctly interpret a blueprint. The following information is included in the Legend Box:  Architecture Domain - Used to specify what aspect of the environment is the subject of architecture artifact - One of the following domains must be specified: • Business Architecture —specify this when the model depicts the company’s business capabilities, business processes, organizational structure, major locations, or relationships with partners and customers • Application Architecture — specify this when the model depicts the application assets that support business capabilities and processes • Data Architecture —specify this when the model depicts the company’s business rules, business data and/or information types, along with their interrelationships • Technical Architecture —specify this when the model depicts hardware and facilities, system software, data storage resources, networks, and other underlying technologies • Technical architecture provide the platform that supports the activities and interfaces of the other domains Architecture Domain: Application Scope: Project Blueprint Type: Info Flow Diagram Abstraction: Logical State: As-Is Revision Date: 06/14/09 Status: Working Draft Revised By: John Doe Architect Approved By: Jane Doe Architect Sample Legend Box 26 Legend Box (continued)  Scope - Defines the breath (or scope of authority) for a blueprint. Several different scopes are recognized: • Enterprise - A model that generally depicts a company’s environment as a whole • Portfolio - A model that depicts the architecture of a portfolio (e.g., Field Management) • Program/Project – A model that depicts the architecture of a program or project • Asset - A diagram that depicts the architecture of an asset  Abstraction - Refers to how far the model is removed from “practical” considerations such as application servers, programming languages, etc » Four different levels are recognized: Presentation, Conceptual, Logical and Physical  State – Used to answer the question: Does this model represent the current state or some proposed future state? Three different states are typically recognized: » As-is - the current state. » To-be - the desired future state that is to be achieved in a specified time period (typically 12 – 24 months). In reality, the to-be state is a moving target that generally represents an aspiration, as opposed to a fixed target that will be achieved » Transition - a planned landing point between the current state and the to-be state • A Transition diagram shows progress towards the future state • Once implemented, a transition architecture represents the new As-Is and the previous current As-Is becomes the As-Was 27 Importance of the Scope of a Blueprint  Specifying the scope of a diagram is critical because there is a direct correlation between the scope and the amount of detail that can be depicted on a blueprint. The reason is that the amount of generalization (e.g., simplification, feature selection, grouping, etc.) must increase with the scope of the blueprint. The following examples illustrate this key point: Scope = Enterprise Scope = System/Project Scope = Portfolio Pgm 1 App D App A App B XYZ Com p As-is Application Architecture for “App D” Daily Extract Daily Extract D e g re e o f G e n e ra li z a ti o n / i n fo rm a ti o n h id in g Tran DB Scope = Subsystem/ program As-is Application Architecture for “Pgm 1” Lots App Portfolio A App Portfolio B App Portfolio C Application Architecture As-Is Application Architecture for App Port “C” Map Analogy Scope = United States Scope = State of Minnesota Scope = City of Minneapolis Scope = Downtown Minneapolis Little Blueprints Sample Enterprise Architecture Blueprint for Diversification Oper. Model Enterprise Architecture for Carlson’s Diversification Operating Model Customer Requirements Business Initiatives Travel Management Loyalty Hotel Distribution CRM Enterprise Portal Presentation Application Data Trust Security Middleware Data Object Platform Network ‘Common Infrastructure | IT Resilience Center for Information Systems Research © 2006 MIT Sloan CISR — Ross Source: Carlson Conwpany 30  Sample Enterprise Architecture Blueprint for Coordination Oper. Model Enterprise Architecture for 4 MetLife’s Coordination Model Application Presentation Tier Application Business Logic and Data Tier i Licensi Suitabilit Portal — ne ensing Rates & Ul jity sss Presentation ntitiements Calcs eee Customers oman Screen Entry & Validation Sign-on Marketing I <AcoRD Hite) re Store Business Producer++ | Navigation Illustrations <a te) Data Store Rules I Search Order Entry I Sales Sessions aes Ottice™* ued iting «econ a, Qa Sa Hub +" Management Billing/ Payment I Underwriter<+ Senice I So Eligibility & issue I Call Center-- Claims Product Admin Service aes Provider” Portals Events Service Workflow Recording ‘Center for Information Systems Research ‘62008 MIT Sloan CISR — Ross Source: Adapted from MetLife documents - used with permission. 31 Sample Enterprise Architecture Blueprint for Replication Operating Model Enterprise Architecture for 4 ING DIRECT’s Replication Model Cry Customer Contact: Selt-Service: Call Center, IVR, E-mail, Internet, MinTel, ATM, Direct mail — WAP, (WebTV) Center for Information Systems Research Souree: Robertson, D. “ING DIRECT: The IT challenge (By, 2003, IMD-3-1345. © 2006 MIT Sloan CISR - Ross. Used with permission. 32 35 Product Sales C li e n t F o c u s (C li e n t a n d C h a n n e l M g m t) Business Management and Support (Information Technology, etc.) Service R isk a n d F in a n c ia l M g m t Sample High-Level Business Architecture Blueprint Who is initiating ree nee classification of the business event What channels are provided to initiate the business event? What is the method used to digitize recognized business events? Bond Business Event Types Business Users How are business events digitally managed during their life cycle? What automation organizations, and processes are needed to support digital business event management? Bond Business Operations - User Event Public User Emall | ms Uc=mibey [aLUBUD Desktop (intranet? Internet) Dx Web Seve ca * Instant Messaging IM Server Business Process Management (BPM) STP Path Human Actor Path Processing Exception <2 (Understand and J") +4] Model Processes Busess |__tPA Tons Process Manage Bus Analyst Pracess Behavior Priority + Push/Pull iness Unit Process | __ Mgmt é Metrics | o | a off Ra Manage Enterprise iA Process Workers Advisors * Work Collaboration * Work Hierarchy oe * Skills BasedRouting * Process Params pel FE Marketing Specialists IT Solution Services * Services Orientation * Human Driven ‘Applications ‘Web Services * Business Rules ze Bond i. Business prchitect 36 37 Business Services Financial Professional Contract Holder Firm Employee Electronic Business Gateway Prospect Participants Interaction Components Clearinghouse Vendor / Partner Systems Integration (Application Bus) Technical Services Text Message Phone PDA Forms Email Browser Services Process Services Atomic Services Composite Services Get Contract Get FP Detail Get Last Touch Contract Setup Check Appoint. Security Services Session Management Event Management Connection Management Party Product Contract Activities Commissions Other Components P a c k a g e E x is ti n g A s s e ts C u s to m E x te rn a l Financial Professional Contract Holder Service Sales Other Views Processes Party Product Contract Activities Commissions Data Rules Process Product Navigation New Business – Form based Death Spousal Continuance Remittance Programmed Reallocation Valuation Other Services Other Stores Security Media Views Sample Application Architecture Blueprint 40 3 Architecture Blueprinting 4 Sample Architecture Blueprints Agenda 1 Introduction 5 Architectural Mapping Process Illustrated 7 Summary and Conclusion 2 High-Level Analysis and Design 6 Reference Architecture Cataloguing Framework 41 Mapping Dimensions to Consider  Levels of abstraction  Breadth (i.e., architectural domain)  Depth (i.e., services/facilities needed)  Specialization (i.e., styles and related pattern)  Integration of various patterns results in integration variants/hybrids  Mapping relies on the selection of standards and products that implement that standard » e.g., JEE – IBM WebSphere Application Server 42 Interaction Integration Bus. Process Integration Application Integration Service Integration Data Integration Infrastructure Integration Separation of concerns through layering enables high cohesion and low coupling across the application components Q ua lit ie s Interaction Integration Interaction Services Business Process Integration Application Integration Service Integration Data Integration Q ualities Qualities R eu sa bl e C om po ne nt s / S er vi ce s M on ito rin g M an ag em en t S ec ur ity Qualities M on ito rin g M an ag em en t S ec ur ity T oo ls a nd U til iti es Business Processes Application Services Services Services Data Services Channels Channels B uild-T im e S ervices Hardware Network Network Services Operating System Services Infrastructure Integration Sample Reference Logical Application Architecture Blueprint (OMA / SOA Hybrid) 45 3 Architecture Blueprinting 4 Sample Architecture Blueprints Agenda 1 Introduction 5 Architectural Mapping Process Illustrated 7 Summary and Conclusion 2 High-Level Analysis and Design 6 Reference Architecture Cataloguing Framework 46 Challenges of an Architecture Continuum Catalog  Any Enterprise is likely to have many Solutions and Architectures  Different Segments of the Enterprise, Product lines or Divisions  Different Levels of Detail suitable for different purpose and audience  Time horizon of an Architecture Scope and Detail of Architectures  Generic Architectures common to all industries  Industry Specific Architectures  Reference Architecture of a particular Organization  … Specialization Hierarchy of Architectures  Business Domain, Information Domain, Application Domain, Infrastructure Domain  A Master Architecture can cover all these domains at a high level  Each Domain can have a single comprehensive view of an Architecture  Each Domain can have multiple views to cover an Architecture  Specialized views for specific purposes within each domain Domains and Views of an Architecture Specialization Hierarchy for Architectures (TOGAF -Centric) Architecture Continuum Common Foundation Systems Industry Organization Architectures Architectures Architectures Architectures Guides oN Gudes a Guides oN Gudes a <> <-> Products & Systems Industry Organization Services Solutions Solutions Solutions Solutions Continuum 47 A Reference Architecture Cataloguing Framework Dimensions 1a D1 D2 D3 D4 Level of wee oo oe. Architecture Area of Specificity Area of applicability Breath of Applicability High Foundation common Organization Enterprise services Low security Finance Mogan Portfolio Stanley Generic | management Industry Citi Project monitoring = etc AT&T Telecom - TOGAF a Verizon ht D5 D6 D7 Ds D9 B10 Depth of Level of Combination Domain Scope Specialization Product Mapping Abstraction type Implementation Business services Model Style style Standard Product presentation integration Application facilities Generic Generic N/A N/A conceptual package Technology integration Hybrid Mix Mix logical Information package Package COM+ MS DNA physical IBM Views OMA CORBA JEE Websphere SOA ESB CORBA2 | __VisiBroker etc etc WS-I -NET SOA etc ete 50 Reference Architecture Catalogue Processes Dimensions Selection : Diagram #1 Deemer ‘Low Level Low Level HighLevel Flow Chart Reference Architecture Blueprint (RFB) Catalog Framework Activity Diagram 51 52 Reference Architecture Cataloguing Framework at Work Sample from Joint NYU-CTS ITP Project (Fall 2009) 55 Course Assignments  Individual Assignments  Reports based on case studies / class presentations  Project-Related Assignments  All assignments (other than the individual assessments) will correspond to milestones in the team project.  As the course progresses, students will be applying various methodologies to a project of their choice. The project and related software system should relate to a real-world scenario chosen by each team. The project will consist of inter-related deliverables which are due on a (bi-) weekly basis.  There will be only one submission per team per deliverable and all teams must demonstrate their projects to the course instructor.  A sample project description and additional details will be available under handouts on the course Web site 56 Team Project  Project Logistics  Teams will pick their own projects, within certain constraints: for instance, all projects should involve multiple distributed subsystems (e.g., web- based electronic services projects including client, application server, and database tiers). Students will need to come up to speed on whatever programming languages and/or software technologies they choose for their projects - which will not necessarily be covered in class.  Students will be required to form themselves into "pairs" of exactly two (2) members each; if there is an odd number of students in the class, then one (1) team of three (3) members will be permitted. There may not be any "pairs" of only one member! The instructor and TA(s) will then assist the pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly three (3) pairs if necessary due to enrollment, but students are encouraged to form their own 2-pair teams in advance. If some students drop the course, any remaining pair or team members may be arbitrarily reassigned to other pairs/teams at the discretion of the instructor (but are strongly encouraged to reform pairs/teams on their own). Students will develop and test their project code together with the other member of their programming pair. 57  Document Transformation methodology driven approach  Strategy Alignment Elicitation  Equivalent to strategic planning  i.e., planning at the level of a project set  Strategy Alignment Execution  Equivalent to project planning + SDLC  i.e., planning a the level of individual projects + project implementation  Build a methodology Wiki & partially implement the enablers  Apply transformation methodology approach to a sample problem domain for which a business solution must be found  Final product is a wiki/report that focuses on  Methodology / methodology implementation / sample business-driven problem solution Team Project Approach - Overall (on o = fe) 4 a @ =} So Pa) = <x 61 Next Session: Detailed-Level Analysis and Design