using togaf as a pragmatic approach to architecture 15 april 2009 jaarbeurs, utrecht kivi niria,...
Post on 31-Mar-2015
212 Views
Preview:
TRANSCRIPT
Using TOGAF as a pragmatic approach to architecture
15 april 2009Jaarbeurs, UtrechtKIVI NIRIA, afd. Informatica
Danny Greefhorst
dgreefhorst@archixl.nl
1
Contents
• Introducing ArchiXL• Introducing architecture • Introducing TOGAF• Principles for pragmatic architecture• Essential TOGAF viewpoints
2
ArchiXL
• IT-architecture consulting firm, founded in 2008
• Based in Amersfoort, the Netherlands
• Focus on financial and public sector
• Knowledge areas:– IT architecture (BPM,
EAI/SOA, ECM, IDM, BI, Portals)
– Enterprise architecture methods and techniques (TOGAF, ArchiMate)
– Sector knowledge (insurance, municipalities, education)
3
What is architecture?
“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution”
IEEE 1471
4
Why practice architecture?
• Architecture helps in optimising the service portfolio of an organisation, aligning IT supply to business demand
• Architecture contributes to a healthy project portfolio, ensuring that projects that contibute most to the long term vision will be realised
• Architecture improves the quality of individual solutions, simplifying their development and maintenance en prolonging their life time
5
What does an organisation without architecture look like?
6
Down-loadfile
Down-loadfile
Down-loadfile
Screenscrape
Screenscrape
Browser
HTTP/XML
Trans-action
file
Trans-action
file
Trans-action
file
Trans-action
file
Messagequeue
Messagequeue
Messagequeue
FTP
Sockets
Message
XML/HTTP
Gateway RPC
CICS gateway
APPC
SMTP
CICS gateway
ORB
Applications From Mergers and Acquisitions
Legacy Applications
Purchased Packages
Applications in Trading Partners
E-Marketplaces
End-User Development
Autonomous Divisions
Outsourced and ASP Applications
Architecture fundamentals
Slide 7
Slide 8
The origin: Zachman framework
DATA Implementation
DATAWhat
FUNCTIONHow
NETWORKWhere
e.g. Data Definition
Entity = FieldRel. = Address
e.g., Physical Data Model
Entity = Tables/Segments/etc.Rel. = Key/Pointer/etc.
e.g., Logical Data Model
Entity = Data EntityRel. = Data Relationship
e.g., Semantic Model
Entity = Business EntityRel. = Business Relationship
List of Things - Important to the Business
Entity = Class ofBusiness Thing
List of Processes -the Business Performs
Function = Class ofBusiness Process
e.g., Application Architecture
Process.= Application FunctionI/O = User Views
e.g., System Design
Process= Computer FunctionI/O =Data Elements/Sets
e.g. Program
Process= Language StatementI/O = Control Block
FUNCTIONImplementation
e.g., Business Process Model
Process = Business ProcessI/O = Business Resources
List of Locations -in which the Business Operates
Node = Major BusinessLocation
e.g., Logistics Network
Node = Business Location Link = Business Linkage
e.g., Distributed System Architecture
Node = IS FunctionLink = Line Characteristics
e.g., Technical Architecture
Node = Hardware/System SoftwareLink = Line Specifications
e.g. Network Architecture
Node = AddressesLink = Protocols
NETWORKImplementation
MOTIVATIONWhy
TIMEWhen
PEOPLEWho
e.g. Rule Specification
End = Sub-conditionMeans = Step
e.g., Rule Design
End = ConditionMeans = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business ObjectiveMeans = Business Strategy
List of Business Goals and Strategies
Ends/Means=Major BusinessGoal/Critical Success Factor
List of Events -Significant to the Business
Time = Major Business Event
e.g., Processing Structure
Time = System EventCycle = Processing Cycle
e.g., Control Structure
Time = ExecuteCycle = Component Cycle
e.g. Timing Definition
Time = InterruptCycle = Machine Cycle
SCHEDULEImplementation
e.g., Master Schedule
Time = Business EventCycle = Business Cycle
List of Organizations -Important to the Business
People = Class of People andMajor Organizations
e.g., Work Flow Model
People = Organization UnitWork = Work Product
e.g., Human Interface Architecture
People = RoleWork = Deliverable
e.g., Presentation Architecture
People = UserWork = Screen/Device Format
e.g. Security Architecture
People = IdentityWork = Job
ORGANIZATIONImplementation
STRATEGYImplementation
e.g., Business Plan
SCOPEPlanner
SYSTEM MODELDesigner
TECHNOLOGYCONSTRAINED
MODELBuilder
DETAILEDREPRESEN-
TATIONSSubcontractor
ENTERPRISE MODEL
Owner
contextual
conceptual
logical
physical
out-of-context
FUNCTIONINGENTERPRISE
perspectives
abstractions
ArchiMate
Business
Application
Technology
Passieve structuur Gedrag Actieve structuur
DeviceSystem software
Infrastructure service
Artifact Network
Infrastructureinterface
Applicationcomponent
Application function
Application service
Dataobject
Application interface
Business actor
Businessrole
Business process
Business service
Business object
Event
Represen-tation
Businessinteraction
Businesscollaboration
9
TOGAF Overview
Slide 10
PART I: Introduction
PART II: Architecture Development Method
PART III: ADM Guidelines and Techniques
PART IV: Architecture Content Framework
PART V: Enterprise Continuum & Tools
PART VI: TOGAF Reference Models
PART VII: Architecture Capability Framework
What’s new in TOGAF 9?
• Modular Structure - The specification content is structured in a modular way, which allows for the concepts in each part to be developed with limited impacts on other parts.
• Content Framework - Provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the architectural building blocks that artifacts represent.
• Extended Guidance on Adopting TOGAF within an Enterprise - An extended set of concepts and guidelines to support the establishment of an integrated hierarchy of architectures
• ADM Guidelines & Techniques - Show in more detail how the ADM can be applied to specific situations.
• Additional ADM Detail - More detailed information supporting the execution of the ADM.
• TOGAF Document Categorization Model - Structures the release management of the TOGAF specification.
– .
Architecture Development Method
12
Classes of Enterprise Architecture Engagement
Slide 13
Business Transformation Readiness Assessment
Steps
• Determine the readiness factors that will impact the organization
• Present the readiness factors using maturity models
• Assess the readiness factors, including determination of readiness factor ratings
• Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
• Work these actions into Phase E and F Implementation and Migration Plan
Factors• Vision • Desire, Willingness, and Resolve • Need• Business Case • Funding• Sponsorship and Leadership • Governance • Accountability • Workable Approach and Execution
Model • IT Capacity to Execute• Enterprise Capacity to Execute• Enterprise Ability to Implement
and Operate
Slide 14
Capability-Based Planning
Slide 15
Content framework
Slide 16
Building blocks
17
18
Artefacts
• Preliminary– Principles Catalog
• Architecture Vision– Stakeholder Map Matrix– Value Chain Diagram– Solution Concept Diagram
• Business Architecture– Organization/Actor Catalog– Role Catalog– Business Service/Function Catalog– Business Interaction Matrix– Actor/Role Matrix– Business Footpr int Diagram– Business Service/Infor mation Diagram– Functional Decomposition Diagram– Product Lifecycle Diagram
• Data Architecture – Data Entity/Data Component Catalog– Data Entity/Business Function Matrix– System/Data Matrix– Class Diagram– Data Dissemination Diagram
• Application Architecture– Application Portfolio Catalog– Interface Catalog– System/Organization Matrix– Role/System Matrix– System/Function Matrix– Application Interaction Matrix– Application Communication Diagram– Application and User Location Diagram– System Use-Case Diagram
• Technology Architecture – Technology Standards Catalog– Technology Por tfolio Catalog– System/Technology Matrix– Environments and Locations Diagram– Platform Decomposition Diagram
• Opportunities and Solutions – Project Context Diagram– Benefits Diagram
• Requirements Management – Requirements Catalog
Slide 19
Deliverables
• Architecture Building Blocks• Architecture Contract• Architecture Definition Document• Architecture Principles• Architecture Repository• Architecture Requirements• Architecture Roadmap• Architecture Vision• Business Principles, Business
Preliminary Goals, and Business Drivers
• Capability Assessment• Change Request
• Communications Plan• Compliance Assessment• Implementation and Migration
Plan• Implementation Governance
Model• Organizational Model for
Enterprise Architecture• Request for Architecture Work• Requirements Impact Assessment• Solution Building Blocks• Statement of Architecture Work• Tailored Architecture Framework• Transition Architecture
Enterprise continuum
20
Reference architecture classification
21
Organisation architecture classification
22
TOGAF 9 Certification
• TOGAF 9 Foundation (level 1)– To provide validation that the Candidate has gained knowledge of the
terminology, structure, and basic concepts of TOGAF 9, and understands the core principles of Enterprise Architecture and TOGAF. The learning objectives at this level focus on knowledge and comprehension.
• TOGAF 9 Certified (level 2) – To provide validation that in addition to the knowledge and comprehension
of TOGAF 9 Foundation, the Candidate is able to analyze and apply this knowledge. The learning objectives at this level therefore focus on application and analysis in addition to knowledge and comprehension.
• Bridge from TOGAF 8 to TOGAF 9 Certified– To enable individuals who are TOGAF 8 Certified to obtain TOGAF 9
Certified (level 2) certification. The bridging option exists to recognize the existing investment in TOGAF certification for individuals who have achieved the TOGAF 8 Certified qualification.
23
Principles for pragmatic architecture
• Use of open standards• Reusing best-practices• Iterative approach • Concrete and usable results• Responsibility for result• Close interaction with stakeholders• “just-enough” architecture• Focus on knowledge, not on rule enforcement
24
Use of open standards
25
TOGAF ArchiMate
Key message: standards are a good starting point, but use them wiselyKey message: standards are a good starting point, but use them wisely
Tip: use formalised models for architects and engineers, use simple powerpoint models for management and users
Tip: use formalised models for architects and engineers, use simple powerpoint models for management and users
Reusing best practices
26
Key message: reuse reference architectures in the market, and make your ownKey message: reuse reference architectures in the market, and make your own
Tip: separate your architecture into an organisation-specific an a generic part; the latter can be stored in the reference library
Tip: separate your architecture into an organisation-specific an a generic part; the latter can be stored in the reference library
Iterative approach
27
Key message: deliver fast, deliver often and make sure every delivery provides added valueKey message: deliver fast, deliver often and make sure every delivery provides added value
Tip: make a plan for defining your architecture with clear milestones and a deadline
Tip: make a plan for defining your architecture with clear milestones and a deadline
Concrete and usable results
28
Key message: be clear on what you deliver, and focus on the goals and requirementsKey message: be clear on what you deliver, and focus on the goals and requirements
Tip: show your sponsor examples of previous architecture deliverables to let him understand what he will get
Tip: show your sponsor examples of previous architecture deliverables to let him understand what he will get
Responsibility for result
29
The Lead Enterprise Architect is responsible for ensuring that the architecture is technically coherent and future-proof.The Lead Enterprise Architect is responsible for ensuring that the architecture is technically coherent and future-proof.
Key message: do not run away after creating the architecture, guide the implementationKey message: do not run away after creating the architecture, guide the implementation
Tip: plan your involvement in the implementation for at least one day in the week
Tip: plan your involvement in the implementation for at least one day in the week
Close interaction with stakeholders
30
Key message: talk to all key stakeholders, bring them together in workshops to get consensusKey message: talk to all key stakeholders, bring them together in workshops to get consensus
Tip: reserve time with the people that have the knowledge; they can provide you with the information you really needTip: reserve time with the people that have the knowledge; they can provide you with the information you really need
Tip: don’t forget to have your architecture reviewed by other architects
Tip: don’t forget to have your architecture reviewed by other architects
“just-enough” architecture
31
Key message: do not overdeliver; focus on the 20% artefacts that deliver 80% of the valueKey message: do not overdeliver; focus on the 20% artefacts that deliver 80% of the value
Tip: first deliver a high-level architecture with only the goals, guiding architecture principles, high-level diagrams, and major changes
Tip: first deliver a high-level architecture with only the goals, guiding architecture principles, high-level diagrams, and major changes
Tip: deliver more detailed architectures for specific themes that require business attention
Tip: deliver more detailed architectures for specific themes that require business attention
Focus on knowledge, not on rule enforcement
32
Key message: architects provide value through skills and knowledge, but they don’t know everythingKey message: architects provide value through skills and knowledge, but they don’t know everything
Tip: look at the intent of principles and guidelines and not so much at their formulation
Tip: look at the intent of principles and guidelines and not so much at their formulation
Tip: deviating from principles and guidelines can be justified if there is a really good motivation
Tip: deviating from principles and guidelines can be justified if there is a really good motivation
Where is the essence?
33
Principle: corporate information is stored only once and retrieved from the source when needed
Motivation• Duplication of information
leads to inconsistencies• Inconsistencies lead to errors
in business processes and/or additional effort in reconciling these inconsistencies
Implications• Information that is needed
throughout the enterprise is stored in a single information providing application
• Information providing applications expose their information through a number of generic application services
• Information providing applications are high available (>99,9%)
34
Tip: interactively define architecture principles with the stakeholders using powerpointTip: interactively define architecture principles with the stakeholders using powerpoint
Tip: reuse existing architecture principles in TOGAF and reference architecturesTip: reuse existing architecture principles in TOGAF and reference architectures
Functional decomposition diagram (business functions)
35
Primary business functions
MaintainProviderRelations
MaintainCustomerRelations
Sales Claims Handling
AssetManegement
FinancialHandling
Secondary business functions
IT Development& Management
HumanResource
Management
FacilityManagement
FinancialManagement Communications
Controlling business functions
Strategic Control EnterpriseArchitecture
QualityManagement
InternalReporting
ProductDevelopment Marketing
ExternalReporting
MaintainIntermediary
Relations
Legal Procurement
PolicyAdministration
BusinessImprovement
System/function matrix
36
Primary business functions
MaintainProviderRelations
MaintainCustomerRelations
Sales Claims Handling
AssetManagement
FinancialHandling
ProductDevelopment
Marketing
MaintainIntermediary
Relations
PolicyAdministration
CustomerPortal
B2BPortal
B2BPortal
Call CenterDesktop
Sales ProcessSupport
Party InformationManagement
Party InformationManagement
Party InformationManagement
ContactAdministration
ContractAdministration
IntegratedCustomer View
P & C PolicyAdministration
Health PolicyAdministration
Life PolicyAdministration
DataWarehouse
BusinessIntelligence &
Reporting
AssetManagement
P & C ClaimsHandling
Health ClaimsHandling
Life ClaimsHandling
FinancialAdministration
Primary business functions
MaintainProviderRelations
MaintainCustomerRelations
Sales Claims Handling
AssetManegement
FinancialHandling
Secondary business functions
IT Development& Management
HumanResource
Management
FacilityManagement
FinancialManagement Communications
Controlling business functions
Strategic Control EnterpriseArchitecture
QualityManagement
InternalReporting
ProductDevelopment Marketing
ExternalReporting
MaintainIntermediary
Relations
Legal Procurement
PolicyAdministration
BusinessImprovement
Impact of drivers/goals/objectives on business functions
37
Impact of new customer group:1.Introduce new products for that group2.Change marketing approach3.Change sales process for new customer group and new products4.Change policy administration for new products
Impact of new customer group:1.Introduce new products for that group2.Change marketing approach3.Change sales process for new customer group and new products4.Change policy administration for new products
11
Tip: determine impact of drivers/goals/objectives on high-level business, application and technology views
Tip: determine impact of drivers/goals/objectives on high-level business, application and technology views
22 33 44
Value chain diagram (roles and information flows)
Insurer
Customer/Intermediary
Customer/Intermediary
Damage Expert
Damage Repair
Car RegistrationCenter
IndemnificationFoundation
Legal ReportCenter
Insurance FraudRegistration
CentralBank
Bank
Request for information,policy acceptance, policy changes
Product information, policy, invoice
Claim
Claim rejection, claim acceptance
Damage assessment order
Damage report
Repair order
Invoice
Car information request
Car information
Request for indemnification
Indemnification approval or rejection
Request for legal report
Legal report
Request information, report fraud
Fraud information
Indemnation payments,premium collections
Account statements
Regulatory report
Application portfolio catalog (application components)
39
Channels Front Office
Party InformationManagement
Back Office
ContractAdministration
P & C PolicyAdministration
Health PolicyAdministration
Life PolicyAdministration
Call CenterDesktop
CustomerPortal
IntegratedCustomer View
Interactive VoiceRecognition
Sales ProcessSupport
ElectronicArchive
InputManagement
ContactAdministration
OutputManagement
Supporting
PersonnelAdministration
FinancialAdministration
ProjectManagement
TimeRegistration
Data Warehouse
B2BPortal
Multi ChannelRouting
E-mailManagement
AssetManagement
BusinessIntelligence &
Reporting
P & C ClaimsHandling
Health ClaimsHandling
Life ClaimsHandling
FacilityAdministration E-mail
Channels Front Office
PartyInformation
Management
Back Office
ContractAdministration
P & C PolicyAdministration
Health PolicyAdministration
Life PolicyAdministration
Call CenterDesktop
CustomerPortal
IntegratedCustomer
View
InteractiveVoice
Recognition
Sales ProcessSupport
ElectronicArchive
InputManagement
ContactAdministration
OutputManagement
Supporting
PersonnelAdministration
FinancialAdministration
ProjectManagement
TimeRegistration
DataWarehouse
B2BPortal
Multi ChannelRouting
E-mailManagement
AssetManagement
BusinessIntelligence &Reporting
P & C ClaimsHandling
Health ClaimsHandling
Life ClaimsHandling
FacilityAdministration E-mail
Issues in application portfolio
40
1. Security in customer portal is not in line with security policy
2. Prolonging of policies does not fit into batch window
3. Integrated customer view does not include life information
4. Maintenance costs of personnel administration are too high
1. Security in customer portal is not in line with security policy
2. Prolonging of policies does not fit into batch window
3. Integrated customer view does not include life information
4. Maintenance costs of personnel administration are too high
11
33
22
44
Tip: plot issues on high-level business, application and technology viewsTip: plot issues on high-level business, application and technology views
Application communication diagram
41
Party InformationManagement
P & C PolicyAdministration
CustomerPortal
ContactAdministration
OutputManagement
P & C ClaimsHandling
claim
contact
policy
claim
FinancialAdministration
financial transaction
Customer/Intermediary
Bank
financial transaction
indemnification
ElectronicArchive
document
Customer/Intermediary
indemnification
customer
CentralBankregulatory
report
Data Warehouse
BusinessIntelligence &
Reporting
financial transaction
financial transactions
contact
Tip: draw application communication diagrams for specific change areasTip: draw application communication diagrams for specific change areas
Communication
Operating System
CollaborationOffice Productivity
Business Process Management Content Management
Data Interchange
User Interface
Transaction Processing Data Management
System and Network Management Security Software Engineering
Technology standards catalog (system software)
Microsoft Windows Server
Microsoft Office Sharepoint Server
Microsoft Office Microsoft Exchange
K2.NET
Microsoft BizTalk Server
Microsoft Office Sharepoint Server
Kofax Ascent Capture
Microsoft .NET Microsoft BizTalk Server
Microsoft MSMQ
Microsoft SQL Server
Microsoft Search Server
Microsoft System Center
Microsoft Office Sharepoint Server
Microsoft Office Communications Server
Microsoft Windows Live Messenger
Microsoft Commerce Server
Microsoft Active Directory
Adobe Reader
Microsoft ISA Server
Microsoft Visual Studio
Microsoft Windows Vista
Oracle Workflow
Oracle DB
Oracle Developer
Oracle Application Server Oracle Advanced Queueing
Oracle Portal
Oracle Grid Control
Oracle Internet Directory
Questions
top related