this is a sweet test run.

1. CompuwareCorporation Page 1
What happened to application
longevity?
Pasi Karjanmaa
Application Delivery
Management
Compuware Asia-Pacific

2. CompuwareCorporation Page 2
Application lifecycle
• Applications built today will run and serve the
Business for.....
• 50 years?
• 30 years?
• 20 years?
• 10 years?
• 5 years?
• 3 years?

3. CompuwareCorporation Page 3
What makes a good application!
• Good development team
• Methodology
• Platform
• Architecture
• Technology choice
• Requirements management
• Met business requirements
• Understood and well Managed budget
• Timely delivery
• Traceability
• Etc.....

4. CompuwareCorporation Page 4
About myself
• App. Dev. since 1986
• KOP Bank
• WM-data
• EMC
• Compuware Finland
• Sales support
• Compuware Europe
• Product Management
• Compuware Asia-
Pacific
• Software Architecture
• Model-Driven Architecture
• Requirements
• Subject Matter Expert

5. CompuwareCorporation Page 5
Applications from the past
• Applications built and serving the business for
tens of years
• Seen major technology changes
• Technology downwards compatible
• Seen major architecture changes
• C/S, Web, Mobile
• Seen major business changes
• KOP -> SYP merger -> Merita -> Nordea
• 6 applications built 1986-1989 still running

6. CompuwareCorporation Page 6

7. CompuwareCorporation Page 7
CompuwareCorporation Page 7
Source: Gartner
The Challenges of Driving Value

8. CompuwareCorporation Page 8
Is IT Spending Its Time Creating or
Maintaining Business Value?
Activity survey of 1,500 IT professionals
• Improving business processes
• Optimizing existing IT infrastructure
• Evaluating emerging technologies
• Building a business case for technology budget
• Identifying new revenue streams
(creating new business value)
Source: InformationWeek, 2004

9. CompuwareCorporation Page 9
CompuwareCorporation Page 9
Source: Gartner
NEW BUSINESS VALUE
The Opportunity to Drive Value

10. CompuwareCorporation Page 10
IT Project Success Rates
0
10
20
30
40
50
60
2002 2004
Succeeded Challenged Failed
IT Project Failure is Business Problem
#1 Reason for Failed Projects is Poor, Missed or Changing Requirements
Source: 2004 CHAOS Report, Standish Group

11. CompuwareCorporation Page 11
A Visible Approach to
Requirements Capture
1. A pragmatic, structured
approach to the capture,
definition and management
of requirements across the
life cycle
2. Concurrent visibility to all
stakeholders of requirements
in output relevant to them

12. CompuwareCorporation Page 12
Best Practices for Application
Development
• Take a proactive approach to development
– build with confidence
• Leverage unique competitive advantages in
each application
• Build application performance by design, not
chance
• Automate best practices to yield repeatable
successes
• Reduce risk throughout the life cycle

13. CompuwareCorporation Page 13
The IT Business Value Curve
Typical application life cycle today
Goals:
• Deliver high-quality,
lasting IT solutions
• Develop cost-
effectively
• Deploy quickly—
only applications in
production generate
business value
• Minimize risk
Time
Risk
Business
Benefit
Business
Benefit
Less Cost
More Cost

14. CompuwareCorporation Page 14
Cost
Time
Risk
Business
Benefit
Business
Benefit
The IT Business Value Curve
Speed development to
capture business value
Lower costs and reduce
development and
maintenance
Build flexibility into
applications
Improve application
quality in development

15. CompuwareCorporation Page 15
Best Practices in Action
EDS evaluates MDA development approach
• EDS
• Independent MDA analysis
by Sun-certified J2EE
architect
and developer
• Results
• Typical technology upgrade
reduced from “several
months to 30 minutes” Cost
Time
Risk
Business
Benefit
Business
Benefit
– Reduced development
time and cost
– Improved application quality
– Increased IT ROI
– New technology quickly
integrated into existing
systems
Conclusions

16. CompuwareCorporation Page 16
Visualization i.e. Modeling improves
communication within a project team
69%

17. CompuwareCorporation Page 17
OMG’s Model Driven Architecture
Qualities
• Portability
• Cross-platform
Interoperability
• Platform Independence
• Domain Specificity
• Productivity
Finance
E-Commerce
Telecommunication
More...
Transportation
Space
Manufacturing
Health Care

18. CompuwareCorporation Page 18
OMG’s Model Driven Architecture
Benefits
• Reduced cost
• Reduced development
time
• Improved application
quality
• Increased return on IT
investments
• Rapid inclusion of
emerging technologies
Finance
E-Commerce
Telecommunication
More...
Transportation
Space
Manufacturing
Health Care

19. CompuwareCorporation Page 19
Code
CIM > > PIM
Mapping
PIM > > PSM
Mapping
PSM > > Code
Mapping
Computation-
Independent Model
(CIM)
Created by Business
Analysts to Describe
Business
Platform-
Specific
Model (PSM)
Created by Developer or Tester to Implement
Solution
Platform-
Independent
Model (PIM)
Created by Architect/
Designer to describe
Architecture
Levels of MDA Models

20. CompuwareCorporation Page 20
Model Driven Architecture
Code Model
Platform Specific Model
Platform Independent Model

21. CompuwareCorporation Page 21
OMG Metamodel Architecture
XML/Java TermsSample ObjectsOMG Terms
MOF DTD/Schema
Schema of Schema!!
CWM, EAI, IDL, UML,
DTD/Schema
Middleware Schema
Business Models,
DTDs, Java Classes
App Schemas
User Objects
XML Docs/Java
Objects
Business data
User Objects
Layer (M0)
Model
Layer(M1)
Metamodel
Layer(M2)
Meta-
Metamodel
Layer (M3)
<Acme_Software_Share_9
8789>, 654.56,sell_limit_
order, <Stock_Quote_Svr
32123>
<Acme_Software_Share_9
8789>, 654.56,sell_limit_
order, <Stock_Quote_Svr
32123>
StockShare, askPrice,
sellLimitOrder, StockQuote
Server [Models, Interfaces,
BODs]
StockShare, askPrice,
sellLimitOrder, StockQuote
Server [Models, Interfaces,
BODs]
UML::Class, Attribute,
CWM::Table,
CWM::Cube
[UML, CWM, EAI, IDL…]
UML::Class, Attribute,
CWM::Table,
CWM::Cube
[UML, CWM, EAI, IDL…]
MOF::Class,
MOF::Attribute,
MOF::Operation
[MOF]
MOF::Class,
MOF::Attribute,
MOF::Operation
[MOF]
Applic-
ation
Applic-
ation
Middle-
ware
Middle-
ware

22. CompuwareCorporation Page 22
Relationship between MDA core and
PIM/PSM
PIM Mapping
Techniques
UML
MOF
Other
languages
Metamodel
PIM
PSM Infrastructure
PSM Mapping
Techniques
<<are described
with>>
<<expressed with>>
<<expressed with>>
<<based
on>>
1..n
1..n
1..n
1..n
<<based
on>>
<<are described
with>> <<depend
on>>
<<independent
of>>
1..n
Mapping from PSM to
PSM
Mapping from PIM to PIM
Mapping from PSM to
PIM
Mapping from PIM to
PSM
<<expressed with>>
1..n
1..n

23. CompuwareCorporation Page 23
Complex technology platform
Complex business process
Business–ITgap
Business
Model (PIM)
Architectural
Design (PSM)
Source
Code
Executable
Code
Requirements
(CIM)
User
Interviews
From requirements to code
Automating translation steps
Tasks
Compiler
IDE
Modeling
tool
Requirement
Management
tool
MS-Word
Modeling
tool
Tools
2. Translate requirements
into business model
2. Translate requirements
into business model
3. Translate business model
into architectural design
3. Translate business model
into architectural design
4. Translate architectural
design into source code
4. Translate architectural
design into source code
5. Translate source code
into executable code
5. Translate source code
into executable code
1. Translate user interviews
into requirements
1. Translate user interviews
into requirements
Transformations
Manual
Manual
Automated
Manual
Manual
Type
Automated
Automated
Automated
Increase
level of
automation

24. CompuwareCorporation Page 24
Func
Requirements
PSM -> Realisation
Architectural Decisions
PIM
PIM
Design
Architectural Decisions
PSM
CIM

25. CompuwareCorporation Page 25
Software factories
A software factory is an environment that offers all the tooling
that is required to build software.
The factory supports all the phases of the software production process:
requirements definition, analysis, design, construction, testing and
production. The activities in the factory are executed according to
a defined process.
Together this offers an environment to effectively build applications.
That’s a lot........

26. CompuwareCorporation Page 26
Software Factories and MDA
Software factories automate the development of software
by coordinating a set of models and transformations to
build applications which conform to a particular
software architecture.

27. CompuwareCorporation Page 27
• A software factory defines one or more application architectures
• An application architecture is a coordinated set of models and
transformations that conforms to a particular software
architecture
• Software factories control the following aspects of software
development:
• They define a set of application architectures that can be constructed
given the types of models and transformations provided by the software
factory
• They define a set of models to describe the domain (PIM) and application
(PSM)
• They link the models by means of a defined set of Model-to-Model
Transformations
• They generate a particular kind of application using a defined set of
Model-to-Text Transformations
Software factories and application
architectures

28. CompuwareCorporation Page 28
•EA Framework
•Reference Models
•EA Taxonomy
Governance & Metrics
Approach plan for Modernization
Business Strategy
Trends
Business
Drivers
Goals
Critical success factors
Enterprise Architecture
(As it is)
IT Architecture
Business Architecture
Gap
Analysis
Project 1
Project 2
Project 1
Implementation
Plan
Enterprise Architecture
(Target)
Technology Architecture
Data Architecture
Application Architecture
Business Architecture
12
3
4
5 6
7

29. CompuwareCorporation Page 29
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE
(CONTEXTUAL)
MODEL
(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = Field
Reln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the Business
ENTITY = Class of
Business Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. Application Architecture
I/O = User Views
Proc .= Application Function
e.g. System Design
I/O = Data Elements/Sets
Proc.= Computer Function
e.g. Program
I/O = Control Block
Proc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which
the Business Operates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business Location
Link = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. Technology Architecture
Node = Hardware/System
Software
Link = Line Specifications
e.g. Network Architecture
Node = Addresses
Link = Protocols
e.g. NETWORK
Architecture
Planner
Owner
Builder
ENTERPRISE
MODEL
(CONCEPTUAL)
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural Assertion
Means =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/
Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing Cycle
Time = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = Identity
Work = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
John A. Zachman, Zachman International (810) 231-0531
SCOPE
(CONTEXTUAL)
Architecture
e.g. STRATEGY
ENTERPRISE
e.g. Business Plan
TM
CODE
Platform Specific Model - PSM
Platform Independent Model - PIM
Computation Independent Model - CIM
Model Driven Architecture versus Zachman
Zachman is the universal frameworks, useful for comparison purposes
Tom Mowbray, PhD
Courtesy of iCMG, Copyright 2006 iCMG Private Limited

30. CompuwareCorporation Page 30
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE
(CONTEXTUAL)
MODEL
(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = Field
Reln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the Business
ENTITY = Class of
Business Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. Application Architecture
I/O = User Views
Proc .= Application Function
e.g. System Design
I/O = Data Elements/Sets
Proc.= Computer Function
e.g. Program
I/O = Control Block
Proc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which
the Business Operates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business Location
Link = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. Technology Architecture
Node = Hardware/System
Software
Link = Line Specifications
e.g. Network Architecture
Node = Addresses
Link = Protocols
e.g. NETWORK
Architecture
Planner
Owner
Builder
ENTERPRISE
MODEL
(CONCEPTUAL)
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural Assertion
Means =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/
Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing Cycle
Time = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = Identity
Work = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
John A. Zachman, Zachman International (810) 231-0531
SCOPE
(CONTEXTUAL)
Architecture
e.g. STRATEGY
ENTERPRISE
e.g. Business Plan
TM
Solution Architect
Enterprise Architect
Enterprise vs. Solution Architecture
Overlapping disciplines of architecture analysis, planning, and design
Tom Mowbray, PhD
Courtesy of iCMG, Copyright 2006 iCMG Private Limited
Programmer

31. CompuwareCorporation Page 31
e.g. DATA
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE
(CONTEXTUAL)
MODEL
(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = Field
Reln = Address
e.g. Physical Data Model
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the Business
ENTITY = Class of
Business Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. Application Architecture
I/O = User Views
Proc .= Application Function
e.g. System Design
I/O = Data Elements/Sets
Proc.= Computer Function
e.g. Program
I/O = Control Block
Proc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which
the Business Operates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business Location
Link = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. Technology Architecture
Node = Hardware/System
Software
Link = Line Specifications
e.g. Network Architecture
Node = Addresses
Link = Protocols
e.g. NETWORK
Architecture
Planner
Owner
Builder
ENTERPRISE
MODEL
(CONCEPTUAL)
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural Assertion
Means =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/
Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing Cycle
Time = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = Identity
Work = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
John A. Zachman, Zachman International (810) 231-0531
SCOPE
(CONTEXTUAL)
Architecture
e.g. STRATEGY
ENTERPRISE
e.g. Business Plan
TM
Application
Architecture
Data
Architecture
Business
Architecture
Zachman versus Federal Enteprise Architecture Framework
FEAF is a highly flexible framework for government enterprises
Tom Mowbray, PhD
Courtesy of iCMG, Copyright 2006 iCMG Private Limited
Technology
Architecture

32. CompuwareCorporation Page 32
Architecture Framework &
Architecture Styles to be used
Enterprise Architecture
Product Line Architecture
Object Oriented
Architecture
Component Oriented
Architecture
Service Oriented
Architecture
Model Driven Architecture
Architecture
Styles
Architecture
Frameworks

33. CompuwareCorporation Page 33
<<Factory>>
AccountFactory
Get( )
FindForCustomer( )
Open( )
<<BusinessObject>>
Account
number : string
rtn : string
balance : fixed
Debit( )
Credit( )
Refresh( )
Close( )
<<BusinessObject>>
Customer
<<Type>>
AccountAccess
UML Model
A Portion of Wells Fargo’s Frame
MDA Tool
Web
Application
Server
Windows
Application
Interactive Voice
Response Unit
Business Service Interface
CORBA
Proxy
SOAP
Proxy
DCOM
Proxy
RMI
Proxy
Network
CORBA
Bridge
SOAP
Bridge
DCOM
Bridge
RMI
Bridge
Business Service Interface
COBOL HOGAN XML LDAP SQL
Business
Logic
System of Record
Interface
Network
RDBMS
Mainframe
Systems of Record
Mainframe Unix Host
BusinessObjectServices
ServantClient
BSI Generation
(C++ and Java)
BSI Generation
(C++ and Java)
Proxy Generation
(C++ and Java)
Proxy Generation
(C++ and Java)
IDL GenerationIDL Generation
Bridge GenerationBridge Generation
Servant GenerationServant Generation
“Legacy” Object
Generation
“Legacy” Object
Generation
Example – Wells Fargo
Code is generated from the UML framework
+titleHolder 0…n

34. CompuwareCorporation Page 34
Classic Modeling and
Development
Applications
Users
Designers &
Developers
Classic
Tools
Domain Knowledge
Platform Knowledge
Domain X
Technology

35. CompuwareCorporation Page 35
MDA Goal
Applications
Users
Domain Models
Domain Experts
Technology Solutions
Platform Experts
MDA
Tools
Application Developers
Technology Selection
and Tuning

36. CompuwareCorporation Page 36
Summary
• Build application to today's business needs
• Make sure applications run on tomorrows platform and
technology
• Elevate Application Delivery Process to new levels
• Model-Driven Architecture – future of UML
• Model as much as you can
• Enrich with constraints
• Traceability throughout
• Productivity
• Consistency
• Quality
• Application Longevity

37. CompuwareCorporation Page 37
Enterprise Architecture Planning

38. CompuwareCorporation Page 38