Presentation is loading. Please wait.

Presentation is loading. Please wait.

Agenda Lab Intro TOGAF Preliminary Stage Business Architecture

Similar presentations


Presentation on theme: "Agenda Lab Intro TOGAF Preliminary Stage Business Architecture"— Presentation transcript:

0 How to Build TOGAF Architectures With System Architect
DAD TOGAF Workshop Lou Varveris WW Community of Practice Lead for EA

1 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

2 The NEED for Enterprise Architecture
Customer quote (paraphrased): ‘We get asked, on a regular basis -- usually at the last minute -- for artifacts that describe the business. The information is: Served up in Powerpoints and Excel spreadsheets Assembled in a scramble There is no correlation between the artifacts We don’t know where the documents came from, who owns them, how reliable the information is, nor what it doesn’t show, etc’ Need a delivery mechanism for this information so it is served up in a self-serve manner

3 The NEED for Enterprise Architecture
Customer quote (paraphrased): ‘With disruptive technologies, such as the cloud and mobile – the EA team – even at a formerly staid Health Care company – is being put in the spotlights (or headlights?) CEO wants to know: How can company react to demand for mobile and cloud technologies, and utilize these technologies for advantage What are the solution alternatives, and cost What is impact to current business What is the risk to current business CEO wants the information ASAP

4 Establish Sources of Record
EA Operations Center Cause-effect Analysis, Heatmaps, Business Analytics & Dashboards Leverage what everyone else is doing SA/Pub, SA/XT, SA/DM Harvest Reference Models Project Prioritization & Planning Core Business Processes These are the things we should do Enterprise Architecture Transition Planning & Roadmaps Business Capabilities These are our roadmaps Infrastructure The organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? From this, the company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions needed new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed. An enterprise architecture is a living thing with a lifecycle of its own. This diagram shows the ongoing EA processes. With the strategy and transition plan in place, EA execution begins. The transitoin plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and enter into, or continue, the solution development & delivery stage. As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization. If we’re not doing things the way we said we want them done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful. Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated. The colors in the diagram separate the organization’s strategy and vision, the enterprise architecture lifecycle components, and the solution development & delivery. Some argue the the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend at how you look at the process. If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective. In that case, it might be fair to consider it part of the EA. Or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it. Harvest EA Governance Harvest Apps Security Tools Apps APM tools Data Solution Design CMDB tools sniffing network Data Standards databases Disparate Spreadsheets Multiple Data Sources Clean up sources of record

5 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

6 Content Framework Core Concepts Extensions Core Core Governance
Motivation Core Concepts Extensions Core Core Services Infrastructure Consolidation Data Modeling Process Modeling

7 Architecture Development Method (ADM) -- Phases
Architecture Vision Stakeholder Management Approach Stakeholder Map Stakeholder Map Matrix Stakeholder Position Matrix Value Chain Diagram Business Architecture Actor/Role Matrix Business Footprint Diagram Business Interaction Matrix Business Service Information Diagram Business Service/Function Catalog Business Use-Case Diagram Contract/Measure Catalog Driver/Goal/Objective Catalog Event Diagram Functional Decomposition Diagram Goal Objective Service Diagram Location Catalog Organization Decomposition Diagram Organization Unit/Actor Catalog Process Flow Diagram Process/Event/Control/Product Catalog Product Lifecycle Diagram Role Catalog Application Architecture Application and User Location Diagram Application Communication Diagram Application Interaction Matrix Application Migration Application Portfolio Catalog Interface Catalog Process/System Realization Diagram Role/System Matrix Software Distribution Diagram System Use-Case Diagram System/Function Matrix System/Organization Matrix Preliminary Phase Principles Catalog Data Architecture Class/Entity Relation Diagram Data Data Dissemination Diagram Data Entity/Business Function Matrix Data Entity/Data Component Catalog Data Migration Diagram Data Security Diagram System/Data Matrix Technology Architecture Environments and Locations Diagram Network Concept Diagram Platform Decomposition Diagram System/Technology Matrix Technology Portfolio Catalog Technology Standards Catalog The diagram types supported in SA Opportunities & Solutions Project Context Diagram

8 ..beyond identifying solutions
Architecture Change Management Rational Change Log & Manage change requests System Architect Carry out governed changes Implementation & Governance System Architect Deployment Modelling EA Compliance Reviews DOORS Gather detailed requirements RSA Build Detailed Designs Migration Planning Focal Point Gather priorities for projects and opportunities Business Value Analysis Roadmapping Opportunities & Solutions System Architect Gap analysis Impact analysis Risk Analysis Cost Analyis Really talking about how SA and other Rat products fit together to suppor ttogaf

9 How EA Establish Vision of EA & Stages of Success
Start Small – Establish Project where you can establish deadline and ROI Grow the EA Show value in analytics Show value in cleaning up sources of record Show value in visibility “I want some of that” EA becomes systematic 9

10 Core Content Framework

11 TOGAF 9 Extended Content Metamodel

12 Perform Labs 1 & 2: TOGAF Preliminary Phase
Make sure SA & the Workshop Folder are Available Lab 2 Create the EA Repository Establish the EA Metamodel

13 Metamodel Extended Disaster Recovery Properties
Application Portfolio Analysis Location Risk

14 Metamodel Extended Customer Facing Process
Strategic Value of Functions

15 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

16 Business Architecture within Context of EA – TOGAF
1 TOGAF Metamodel We want to understand Capabilities Functions Processes (that orchestrate Functions) Services (that encapsulate Functions) People (that own Functions & Apps) Applications (enabling Services or Functions) Information (data) Technologies (used by Applications & Services) Locations (of Apps, Technologies & People) 2 3 5 9 4 8 7 6

17 Functions, Processes, Services, Applications
Function = something that an organization does. According to TOGAF, a function "delivers business capabilities closely aligned to an organization, but not explicitly governed by the organization." Process = how the organization performs a function. There are many cross function processes, and cross organizational processes. According to TOGAF, a process "is a flow of interactions between functions and services that cannot be physically deployed. All processes should describe the flow of execution for a function and therefore the deployment of a process is through the function it supports; i.e., an application implements a function that has a process, not an application implements a process."

18 Functions, Processes, Services, Applications
Follow the purple crayon: Function is realized by Process. Function is bounded by a Business Service which may be automated by an IS Service, which is further implemented by an Application. In this workshop we are not specifically modeling Business Services or Information System (IS) Services; we use the direct relation between Function and Application.

19 Functions, Processes, Services, Applications
From TOGAF spec: Function encapsulates Business Service Business Service encapsulates Functions Business Service can be performed by Information System (IS) Service IS Service part of Application Component

20 Business Process Modeling (BPMN) Input to EA
EA Cockpit 3.3.1 SA/Pub, SA/XT, SA/DM BPMN Modeling in SA 3.3.1 Leverage what everyone else is doing Reference Models Mobile Loans Decision Making Platform: Cause-effect Analysis, Heatmaps, Business Analytics & Dashboards EA Transition Planning Approval Process Enterprise Architecture Delivery Business Process Modeling, Capturing & Redesigning 3.3.2 Solution Design The organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? From this, the company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions needed new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed. An enterprise architecture is a living thing with a lifecycle of its own. This diagram shows the ongoing EA processes. With the strategy and transition plan in place, EA execution begins. The transitoin plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and enter into, or continue, the solution development & delivery stage. As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization. If we’re not doing things the way we said we want them done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful. Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated. The colors in the diagram separate the organization’s strategy and vision, the enterprise architecture lifecycle components, and the solution development & delivery. Some argue the the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend at how you look at the process. If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective. In that case, it might be fair to consider it part of the EA. Or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it. IBM BlueWorksLive System Architect BPMN Modeling in SA/XT RSA Visio Models Import w SA-Visio Mapper Utility

21 Perform Lab 3.1: Business Architecture
Import business Functions Auto-Build Functional Decomposition Diagram Add New Functions Understand Function Owners

22 Functional Hierarchy & BPMN 2.0 Process Flows
Decomposition

23 SA/XT – Live BPMN Modeling on Web Browser
Model on BPMN near-zero footprint web interface Only JavaScript to enable Model and save directly in SA repository Can use SA rich-client on same repository at same time System Architect XT System Architect BPMN modeling in SA/XT Microsoft IIS Server System Architect Server OSLC SQL Server or Oracle Database

24 SA – Visio Integration through Mapper Utility
C SA – Visio Integration through Mapper Utility SA-Visio Mapper Utility available for free on DeveloperWorks Map any Visio diagram to System Architect Mapper Utility reads Visio diagram and provides side-by-side mapping interface to user Landscape diagram in Visio Diagram imported into SA

25 IBM BlueworksLive D Easy web interface
Engage line of business users in process discovery, documentation, & simple process automation Import/Export: Import Visio XML diagram format (.vdx) Bidirectional support for BPMN 2.0 interchange Bidirectional support for XPDL 2.1 Generate IBM Websphere Business Modeler XML (Version 7.0) Generate to Microsoft Excel (.xls)

26 SA-BlueWorksLive Integration via BPMN 2.0 Interchange
D SA-BlueWorksLive Integration via BPMN 2.0 Interchange 1 BPMN in BlueWorksLive IBM BlueWorksLive to SA via BPMN 2.0 Interchange Bi-directional 2 Export in BlueWorksLive 3 Export Choices in BlueWorksLive 5 BPMN model in SA after import 4 BPMN Import into SA

27 Use of Reference Models to Jump Start EA Effort
IBM Is a member of the APQC.org, and has helped develop several industry process frameworks, including: Aerospace & Defense Automotive Banking Broadcasting Consumer Products Electric Utilities Petroleum Downstream Petroleum Upstream Pharmaceutical Telecommunications Pre-established 5-layer process framework can be import into modeling tools Example: APQC Process Framework for Banking which IBM helped develop

28 Using APQC According to APQC's John Tessmer, "The PCF was originally envisioned and is still based on the premise that it is a classification system or taxonomy of business processes, similar to how a dictionary classifies words. The categorization does not imply that organizations structure their internal operations according to the taxonomy; it merely provides a facility to help define processes so that they can be understood and referenced in a consistent manner. Similarly, a dictionary won't instruct you in proper grammar or sentence construction — you would have to refer to a style guide for that."

29 Perform Labs 3.2 and 3.3: Business Architecture
Examine APQC Process Framework for Banking Lab 3.3 Model a Process Flow with BPMN 2.0 Utilize BPMN 2.0 Interchange to Import BlueWorks Flow Link Processes with Functions they Orchestrate Create Function/Process Parent/Child Navigation Links

30 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

31 Business Service A Business Service can be manual or automated
It provides governed interface to access Functions It supports business Processes It can be implemented by an Information System (IS) Service -- a fully automated service, similar to what the industry might call a SOA service

32 FEA Services Reference Model (SRM)
US Federal Enterprise Architecture (FEA) Service Reference Model (SRM) Part of the Consolidated Reference Model Contains a taxonomy of all of the services performed by all agencies of the United States government, as specified by the US Office of Management and Budget (OMB). Agencies must show that any system they wish funded support a service in the SRM The commercial industry has adopted the SRM as a guide to what their business is doing/should be doing

33 FEA Services Reference Model (SRM)
Best Practice: After importing the SRM, the Enterprise Architect can delete Business Services not used in the organization, and add Business Services that are used. The SRM is used to jump start the EA effort

34 FEA Services Reference Model (SRM)
For this Workshop: Metamodel of the SRM we use in workshop is modified from SRM provided by the US government. In workshop metamodel, decomposition property of the Service definition has been utilized to provide hierarchy of services. In the US government's SRM, the metamodel starts with highest level Service Domain, then breaks down into Service Type, and then Service Component (lowest level). The SA FEA Reference model add-in allows you to import that SRM (provided by the US government via an xml file on whitehouse.gov), align your architecture with it, & produce reports mandated by OMB

35 Perform Lab 4: Business Service Layer
Import Modified Version of FEA Services Reference Model (SRM) Add Business Service to the Architecture

36 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

37 Logical vs Physical App Components (and Tech Components)
Optional to model Logical Application Components Example: Sales Licensing tool Web development tool Enterprise Architecture tool Enables better analysis Understand how many Process Modeling tools you have Understand why a tool is being used (Photoshop for Web Dev) In SA, Application Component definition has toggle for “Physical”; if not toggled, it is logical app component Note in TOGAF metamodel, Logical App Component not connected to Logical Tech Component

38 Examples of Logical & Physical App & Tech Components
Application Component (Logical) Enterprise Architecture tool Requirements Management tool Software Design tool Change Management Collaborative Development tool Application Component (Physical) System Architect DOORS Rational Software Architect Rational Team Concert Technology Component (Logical) Relational Database Operating System Mobile Operating System Web Browser Script Language Technology Component (Physical) Microsoft SQL Server database Windows Android JavaScript

39 Use of Application, Data, and Technical Reference Models
Application, Data, & Process Reference Models: Telecommunications Forum Telecom Applications Map (TAM) of TMForum Used by Telecom & other industries Also: SID – Standard Information Database Also: eTom – Business Process Framework IBM & System Architect are TMForum Certified Encyclopedia provided prepopulated with TAM, eTOM, & SID IBM provides Telecom Catalog Order Management Solution – maps IBM solutions to SID, eTOM, TAM IBM Catalog Driven Order Management Solution Mapping to SID Mapping to eTOM

40 Perform Lab 5: Information Systems Architecture
Import Spreadsheet of Physical Applications Visualize Physical Application Interfaces Import Pre-Built Explorer Reports & Analytic Collections Visualize Application Interfaces Add an Application Lab 6 Utilize TMForum TAM for Logical Application Reference Model Map Logical to Physical Apps Build Report for Functions, Logical Apps, Physical Apps Generate Report to HTML Generate Report to Grid Generate ‘Partial’ Report Model Data Flows between Logical Apps (Optional)

41 Report to HTML Functions, their Logical Applications, and their related Physical Applications

42 Report to Grid Functions, their Logical Applications, and their related Physical Applications

43 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

44 Application Portfolio Analysis & Management
Assess Applications using APM tools Cost of application Invest, Divest, Maintain Dev bandwidth What are the business priorities? What is working well? What is unnecessary, redundant or obsolete? Where can costs be cut? Query workforce – example: vote on usefulness and usability of applications used

45 Application Portfolio Management
Set values for assessment Review financial details

46 Lab 7 instructions come after next section

47 Agenda Lab Intro TOGAF Preliminary Stage Business Architecture
Business Service Layer Information Systems Architecture Application Portfolio Management Analysis

48 Gap Analysis and Cause-Effect Analysis
Use the architecture to answer questions: Budget Constraints If a System is retired, what Capabilities are affected? How many projects are underway to supply similar capabilities? If I want to field a new system, what other systems do I currently have that are similar to it, based on functions they perform? Disaster Recovery If a System is put out of service, what Capabilities are affected? Risk If an operating system is changed, what Capabilities could be affected?

49 Cause-Effect Analysis Example: Traverse relationships Capability to ActivityPartOfCapability to Activity to ActivityPerformedbyPerformer to Performer

50 Cause-Effect Analysis
See what Systems enable what Capabilities, by traversing Activities and System Functions

51 Cause-Effect Analysis
Isolation analysis – hide all lines and only show how a single Capability is enabled

52 Analytics and Heatmaps
Use the architecture to answer questions: Budget Constraints How can we reduce costs to meet budget constraints but still provide needed Capabilities What are the costs associated with Activities and Systems that support a Capability? Unintended effects of cost reduction – if we virtualize servers, what Apps are affected; what Activities are affected; what Capabilities are put at risk? Lots of ways to calculate costs: Activity Based Costing, Cost of Purchased Systems, Maintenance, Manpower, etc Disaster Recovery What capabilities are at risk if different systems go down at certain locations? Is there a disaster recovery plan in place for important systems?

53 sgfsdfs Example uses Activity Based Costing rolled up to System cost

54 Perform Lab 7: Application Portfolio Analysis
Import APM Information from APM tool Perform Cause-Effect Analysis Create Landscape View Perform Heatmap Analysis

55 End of Current Workshop Exercises
The Next Sections Are for Theory Only

56 TOGAF Metamodel Extensions for Infrastructure
Metamodel Additions Needed to Model Application and IT Portfolio to Version and Instance Level

57 TOGAF Metamodel Extensions for Infrastructure
Configuration Item = A physical device or executable software that is part of an enterprise’s current infrastructure. Is abstract Is instantiated by Physical Application Instance Server Instance Database Instance Device Instance

58 TOGAF Metamodel Extensions for Infrastructure
Application Component (Logical) Enterprise Architecture tool Requirements Management tool Software Design tool Change Management Collaborative Development tool Application Component (Physical) System Architect DOORS Rational Software Architect Rational Team Concert Physical Application Component Version System Architect DOORS 10.1 RSA 8.0 Physical Application Component Instance System Architect License 1 Technology Component (Logical) Relational Database Operating System Mobile Operating System Web Browser Script Language Physical Technology Component Type Microsoft SQL Server database Windows Android JavaScript Technology Component (Physical) Microsoft SQL Server 2008 R2 Microsoft Windows 7 JavaScript 4 Database Instance SQL Server 2008 R2 Running Instance Operating System Instance Windows 7 Running Instance Device Instance Lenovo Laptop S/N 1234

59 TOGAF 9.1 Extensions for Infrastructure by IBM
Application Component (Log) EA Tool Application Component (Phys) SA Technology Component (Logical) Physical Application Version Laptop SA Technology Component (Logical) Physical Application Instance Operating System SA L1234 Operating System Instance Technology Component (Physical) Physical Technology Component Type Windows 7 – L1234 Windows 7 Windows Device Instance Technology Component (Physical) Physical Technology Component Type Lenovo W510 S#1234 Lenovo W510 Lenovo Laptop Base TOGAF 9.1 IBM extensions for infrastructure

60 Simplified TOGAF 9.1 Extensions – SA 11.4.3.2
Application Component (Log) EA Tool Application Component (Phys) SA Technology Component (Logical) Physical Application Version Laptop SA Technology Component (Logical) Physical Application Instance Operating System SA L1234 ,<Operating System> Operating System Instance Technology Component (Physical) Physical Technology Component Type Windows 7 – L1234 Windows 7 Windows Device Instance Technology Component (Physical) Physical Technology Component Type Lenovo W510 S#1234 ,<Device> Lenovo W510 Lenovo Laptop Base TOGAF 9.1 IBM extensions for infrastructure

61 Tivoli Application Dependency Discovery Manager (TADDM)
Application Mapping with Dependencies Agent-less and Credential-free Discover interdependencies between Applications, middleware, servers and network components) TADDM can/does discover applications on a system. However, there's some nuances to that statement to go over. Here the come: TADDM will discover any 'running' application (in memory, consuming resources) TADDM will discover any registered application (i.e. it's in the RPM registry, the windows installed app registry, Etc.). TADDM will NOT discover applications that are installed on the disk that do not meet the above two criteria (e.g. you copy a binary to your home directory and it's not running when TADDM scans). Inventory tools will find that type of app, but not TADDM Also: A level 2 scan (TADDM has 3 different types of scans), will find the apps and who they're communicating with. So you'll know that WebSphere is communicating with DB2, Etc, Etc. That's the "Dependency" part of the "Tivoli Application Dependency Discovery Manager" TADDM Discovers and maps data using a physical and logical (Configuration Item) CI relationship. I.e. This host, has this OS, this application who's talking to that host, that os and that application. So it discovers the info in your table but also much more.

62 Tivoli Application Dependency Discovery Manager (TADDM)

63 System Architect – TADDM Integration
TADDM produces XML output file SA-TADDM Integration provides VBA integration that utilizes XML Mapping file to import TADDM info into SA definition/property set TADDM Export SA-TADDM Mapping File SA-TADDM Integration in SA

64 Perform Lab 8: Infrastructure Analysis
Import Infrastructure Info from CMDB tool Create Heatmap

65 Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS document is distributed "AS IS" without any warranty, either express or implied. In no event shall IBM be liable for any damage arising from the use of this information, including but not limited to, loss of data, business interruption, loss of profit or loss of opportunity. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.

66 Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM expressly disclaims all warranties, expressed or implied, including but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at:

67 Thank You Your Feedback is Important!
Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.


Download ppt "Agenda Lab Intro TOGAF Preliminary Stage Business Architecture"

Similar presentations


Ads by Google