Transcript Response to the OMG Electronic Payment Interoperability RFI

A Real-World Example of
MDA without Automation
Ed Seidewitz
26 August 2004
Copyright © 2004 InteliData
Agenda
• Background
• Model-driven architecture
• Case study
• Conclusions
2
Copyright © 2004 InteliData
Background
• Consumer bill payment
• InteliWorks architecture
• InteliWorks development
3
Copyright © 2004 InteliData
Background: Consumer bill payment
Consumer
Consumer
Computer
Computer
Internet
Bank-owned systems
Web
Web Banking/
Banking/
Bill
Bill Pay
Pay UI
UI
Bill
Bill Payment
Payment
Warehouse
Warehouse
Batch files
Funding
Funding
System
System
Remittance
Remittance
Provider
Provider
Merchants
Merchants
(Bank system /ACH / …)
4
Copyright © 2004 InteliData
Background: InteliWorks architecture
5
Copyright © 2004 InteliData
Background: InteliWorks development
• InteliWorks project initiated late in 2000.
• Iterative development approach with each
(overlapping) increment taking 3-4 months
(currently working on Increment 18).
• Significant modeling introduced in stages
starting early in 2001.
– Architectural modeling
– Logical data modeling
– Physical Java class modeling (no longer done)
– Use case modeling
• Complete model-driven approach established
by mid 2003.
6
Copyright © 2004 InteliData
Model-driven architecture
• What is it?
• What is a platform?
• CIM, PIM, PSM and all that…
• Transformations
• Why “manual transformation”?
7
Copyright © 2004 InteliData
MDA: What is it?
•From the MDA Guide Version 1.0.1 (omg/2003-06-01)
•“The Model-Driven Architecture starts with the
well-known and long established idea of separating
the specification of the operation of a system from
the details of the way that system uses the
capabilities of its platform.”
8
Copyright © 2004 InteliData
MDA: What is a platform?
•From the MDA Guide Version 1.0.1 (omg/2003-06-01)
•“A platform is a set of subsystems and
technologies that provide a coherent set of
functionality through interfaces and specified
usage patterns, which any application supported
by that platform can use without concern for the
details of how the functionality provided by the
platform is implemented.”
9
Copyright © 2004 InteliData
MDA: CIM, PIM, PSM and all that…
• From the MDA Guide Version 1.0.1 (omg/2003-06-01)
• “A computation independent model is a view of
a system” that “focuses on the on the
environment of the system, and the
requirements for the system.”
• “A platform independent model is a view of a
system” that “focuses on the operation of a
system while hiding the details necessary for a
particular platform.”
• “A platform specific model is a view of a
system” that “combines the platform
independent viewpoint with an additional focus
on the detail of the use of a specific platform
by a system.”
10
Copyright © 2004 InteliData
MDA: Transformations
• “The platform independent model is
transformed to be a model specific to a
particular platform.”
• “Four different transformation
approaches…illustrate the range of
possibilities:”
– manual transformation
– transforming a PIM that is prepared using a profile
– transformation using patterns and markings
– automatic transformation
11
Copyright © 2004 InteliData
Case study
• Overview
• Architecture
• Data
12
Copyright © 2004 InteliData
Case study: Overview
<<extend>>
<<extend>>
Consumer: Payment - Cancel
<<extend>>
<<extend>>
<<include>>
<<include>>
Consumer: Payment - Create
(without Bill)
Implementation platform
• J2EE (WebLogic app server)
• Relational DB (Oracle DBMS)
• Web services (Apache Axis)
Consumer: Payment - View
Activity
Consumer: Payment - View
Payments
Consumer
Consumer: Payment - Validate Consumer: Payment - Modify
<<include>>
<<include>>
Consumer: Payment - Route
Requirements Model
(use case and activity diagrams)
hand modeled
<<Interface>>
PaymentFeExtended
addPaymentNoteExtended()
completePaymentExtended()
failPaymentExtended()
getPaymentsExtended()
pendPaymentExtended()
resubmitPaymentExtended()
reversePaymentExtended()
<<Interface>>
PaymentFe
addPayment()
cancelPayment()
getPayments()
getPaymentActivity()
updatePayment()
<<Interface>>
PaymentUtility
prepare()
getRouting()
checkForDuplicate()
hand modeled
PIM
<<Interface>>
PaymentEvent
processPayments()
<<Interface>>
Payment
handlePayeeChange()
Notification
FinancialTransactionCommon
PaymentService
(from eMessenger)
(from Financial Transaction Service)
FinancialTransactionUtility
SchedulingEvent
(from Financial Transaction Service)
(from Scheduler)
FinancialTransaction
(from Financial Transaction Service)
PayeeUtility
AccountUtility
OperationalDirectory
(from Operational Directory Service)
PaymentRead
FinancialTransactionRead
FinancialTransactionWrite
Dependency Model
(class diagrams)
hand modeled
: Consumer
: ConsumerFrontEnd
: XmlConnector
1. Create payment
1.1. Enter payment
: PaymentService
traces
hand modeled
: FinancialTransactionService
Sequence Diagram: InteliWorks
Consumer: Payment Realizations /
Consumer: Payment - Enter
1.2. Display confirmation
CreationData
FinancialTransactionBase
+creationData
1
Sequence Diagram: InteliWorks
Consumer: Financial Transaction
Realizations / Consumer: Financial
Transaction - Add
2. Ok
2.1. addPaymentRq
+displayStatus
FinancialTransactionConsumerData
DisplayStatus
1
1
2.1.1. addPayment( )
2.1.1.1. addFinancialTransaction( )
+processingData
FinancialTransactionData
2.1.1.1.1. financialTransaction
ProcessingData
1
1
0..1
2.1.1.2. payment
+status
<<enumeration>>
FinancialTransactionTypeCode
FinancialTransaction
FinancialTransactionExtended
1
0..1
1
3. Close view
3.1. View payments
Sequence Diagram: InteliWorks
Consumer: Payment Realizations /
Consumer: Payment - View Payments
+amount
1
Architectural Realizations
(sequence diagrams)
hand coded
1
+previousStep
+transactionType
CurrencyAmount
+status
0..1
0..1
1
ProcessingStatus
PAYMENT
FUNDS_TRANSFER
2.1.2. addPaymentRs
+specification
FinancialTransactionSpecification
*
+note
0..1
*
{ordered}
Note
PIM/PSM
hand coded
CIM
ProcessingStep
0..1
Logical Data Model
(class diagrams)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Schema Definition
(Torque XML)
hand coded
generated
PSM
Web Services Code
(WSDL/SOAP)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Value Object Code
(Java)
AUDIT_ID : NUMBER(9, 0)
ACTION_CODE : NUMBER(9, 0)
FI_TRANSACTION_SEQ_ID : NUMBER(9, 0)
LAST_MODIFIED_BY : NUMBER(9, 0)
CONSUMER_SEQ_ID : NUMBER(9, 0)
TRANSACT ION_TYPE : NUMBER(9, 0)
MODEL_INST ANCE_NUMBER : NUMBER(9, 0)
RECURRING_MODEL_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT _SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT _T YPE_CODE : NUMBER(9, 0)
SOURCE_ACCOUNT _NUMBER : VARCHAR2(32)
SOURCE_ROUT ING_NUMBER : VARCHAR2(9)
SOURCE_ACCOUNT _HOLDER : VARCHAR2(255)
REQUESTED_DAT E : DATE
REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)
CREDIT_DATE : DATE
PROCESS_DAT E : DATE
DISPLAY_STAT US_CODE : NUMBER(9, 0)
CURRENCY_CODE : CHAR(3)
AMOUNT : NUMBER(17, 2)
CONSUMER_MEMO : VARCHAR2(255)
DISPLAY_STAT US_MODIFIED_DAT E : DATE
DISPLAY_STAT US_MODIFIED_BY : NUMBER(9, 0)
DISPLAY_STAT US_NOT E : VARCHAR2(255)
PROCESSING_FLOW_TYPE : NUMBER(9, 0)
PROCESSING_TIME : DATE
RETRY_COUNT : NUMBER(9, 0)
DESTINATION_PROVIDER_SEQ_ID : NUMBER(9, 0)
PROCESS_STATUS_CODE : NUMBER(9, 0)
AUTHORIZAT ION_PROVIDER_SEQ_ID : NUMBER(9, 0)
DAYS_TO_CREDIT : NUMBER(9, 0)
SOURCE_PROVIDER_SEQ_ID : NUMBER(9, 0)
VALIDATE_STATUS_CODE : NUMBER(9, 0)
PROCESS_STATUS_PROVIDER_SEQ_ID : NUMBER(9, 0)
PROCESS_STATUS_MODIFIED_BY : NUMBER(9, 0)
PROCESS_STATUS_MODIFIED_DATE : DAT E
PROCESS_STATUS_NOTE : VARCHAR2(255)
VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)
VALIDATE_STATUS_MODIFIED_DATE : DAT E
AUDIT_DAT E : DATE
AUDIT_VERSION : NUMBER(9, 0)
VALIDATE_STATUS_NOTE : VARCHAR2(255)
AUDIT_GENERATION : NUMBER(9, 0)
PAYMENTS
AUDIT_ID : NUMBER(9, 0)
ACTION_CODE : NUMBER(9, 0)
FI_TRANSACTION_SEQ_ID : NUMBER(9, 0)
PAYEE_SEQ_ID : NUMBER(9, 0)
BILL_SEQ_ID : NUMBER(9, 0)
PROVIDER_SEQ_ID : NUMBER(9, 0)
PAYEE_NAME : VARCHAR2(255)
PAYEE_PHONE_NUMBER : VARCHAR2(32)
NAME_ON_ACCOUNT : VARCHAR2(255)
BILLING_ACCOUNT : VARCHAR2(255)
PAYMENT_DESTINAT ION_TYPE : NUMBER(9, 0)
ADDRESS1 : VARCHAR2(64)
ADDRESS2 : VARCHAR2(64)
ADDRESS3 : VARCHAR2(64)
ADDRESS4 : VARCHAR2(64)
CITY : VARCHAR2(32)
ST ATE_PROV : VARCHAR2(32)
POSTAL_CODE : VARCHAR2(11)
COUNT RY_CODE : CHAR(3)
ACT_PAYEE_NAME : VARCHAR2(255)
REMITTANCE_METHOD : NUMBER(9, 0)
ACT_PAYEE_PHONE_NUMBER : VARCHAR2(32)
ACT_NAME_ON_ACCOUNT : VARCHAR2(255)
ACT_BILLING_ACCOUNT : VARCHAR2(255)
ACT_PAYMENT _DEST INATION_TYPE : NUMBER(9, 0)
ACT_ADDRESS1 : VARCHAR2(64)
ACT_ADDRESS2 : VARCHAR2(64)
ACT_ADDRESS3 : VARCHAR2(64)
ACT_ADDRESS4 : VARCHAR2(64)
ACT_CITY : VARCHAR2(32)
ACT_STATE_PROV : VARCHAR2(32)
ACT_POST AL_CODE : VARCHAR2(11)
ACT_COUNTRY_CODE : CHAR(3)
CHECK_NUMBER : VARCHAR2(40)
ACT_REMITT ANCE_METHOD : NUMBER(9, 0)
SERVICE_CENT ER_SEQ_ID : NUMBER(9, 0)
MERCHANT _SEQ_ID : NUMBER(9, 0)
DEFAULT _ROUTING_REASON : NUMBER(9, 0)
DAYS_TO_PROCESS : NUMBER(9, 0)
AUDIT_VERSION : NUMBER(9, 0)
AUDIT_GENERATION : NUMBER(9, 0)
AUDIT_DAT E : DATE
reverse
engineered
13
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
generated
Interface Code
(EJB)
generated
FINANCIAL_T RANSACTIONS
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Database Design Model
(class diagram)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Schema Code
(SQL)
Copyright © 2004 InteliData
Why “manual transformation”?
• Manual transformation “is not greatly different from how
much good software design work has been done for
years. The MDA approach adds value in two ways:”
– “the explicit distinction between a platform independent model
and the transformed platform specific model,
– “the record of the transformation.”
• For InteliWorks…
– Needed to establish effective modeling before introducing
automation.
– Lacked a business case for an effective team late in the product
development cycle. The long-term benefits were not convincingly
worth the short-term loss of productivity to introduce new tools.
• The business case would likely be different for a new
product development cycle.
14
Copyright © 2004 InteliData
Case study: Architecture
• Dependency models
– Payment Service dependencies
• Architectural models to code
– PaymentFe helper class
– Add payment request value object class
• Architectural models to Web services
– WSDL for the Payment Service
15
Copyright © 2004 InteliData
Payment Service dependencies
<<Interface>>
PaymentFeExtended
addPaymentNoteExtended()
completePaymentExtended()
failPaymentExtended()
getPaymentsExtended()
pendPaymentExtended()
resubmitPaymentExtended()
reversePaymentExtended()
<<Interface>>
PaymentFe
addPayment()
cancelPayment()
getPayments()
getPaymentActivity()
updatePayment()
<<Interface>>
PaymentUtility
prepare()
getRouting()
checkForDuplicate()
<<Interface>>
PaymentEvent
processPayments()
<<Interface>>
Payment
handlePayeeChange()
Notification
FinancialTransactionCommon
PaymentService
(from eMessenger)
(from Financial Transaction Service)
FinancialTransactionUtility
SchedulingEvent
(from Financial Transaction Service)
(from Scheduler)
FinancialTransaction
(from Financial Transaction Service)
PayeeUtility
AccountUtility
OperationalDirectory
(from Operational Directory Service)
PaymentRead
16
FinancialTransactionRead
FinancialTransactionWrite
Copyright © 2004 InteliData
PaymentFe helper class
public class PaymentFeHelper
{
public static AddPaymentRsVO addPayment
( SessionVO session, AddPaymentRqVO request )
throws CheckedException, UncheckedException { … }
public static CancelPaymentRsVO cancelPayment
( SessionVO session, CancelPaymentRqVO request )
throws CheckedException, UncheckedException { … }
public static GetPaymentActivityRsVO getPaymentActivity
( SessionVO session, GetPaymentActivityRqVO request )
throws CheckedException, UncheckedException { … }
public static GetPaymentsRsVO getPayments
( SessionVO session, GetPaymentsRqVO request )
throws CheckedException, UncheckedException { … }
public static UpdatePaymentRsVO updatePayment
( SessionVO session, UpdatePaymentRqVO request )
throws CheckedException, UncheckedException { … }
private static PaymentRequestMgr getPaymentRequestMgr ()
throws CheckedException, RemoteException { … }
}
17
Copyright © 2004 InteliData
Add payment request value object class
public class AddPaymentRqVO implements ValueObject
{
private PaymentSpecificationVO
specification;
public AddPaymentRqVO( ) { }
public AddPaymentRqVO( PaymentSpecificationVO
specification)
{ this.specification = specification; }
public PaymentSpecificationVO getSpecification()
{ return this.specification; }
public void setSpecification(PaymentSpecificationVO
specification)
{ this.specification = specification; }
}
18
Copyright © 2004 InteliData
WSDL for the Payment Service
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions …>
…
<wsdl:message name="addPaymentRequest">
<wsdl:part name="session" type="tns1:SessionVO"/>
<wsdl:part name="request" type="tns1:AddPaymentRqVO"/>
</wsdl:message>
…
<wsdl:portType name="PaymentService">
<wsdl:operation name="addPayment" parameterOrder="session
request">
<wsdl:input message="impl:addPaymentRequest"
name="addPaymentRequest"/>
<wsdl:output message="impl:addPaymentResponse"
name="addPaymentResponse"/>
<wsdl:fault message="impl:ServiceException"
name="ServiceException"/>
</wsdl:operation>
…
</wsdl:portType>
…
</wsdl:definitions>
19
Copyright © 2004 InteliData
Case study: Data
• Logical data model
– Financial transaction entity model
– Payment entity model
• Logical model to code
– Payment value object classes
• Logical model to XML
– Payment XML aggregate
• Logical model to database schema
– Payment tables
20
Copyright © 2004 InteliData
Financial transaction entity model
CreationData
FinancialTransactionBase
+creationData
1
+displayStatus
FinancialTransactionConsumerData
1
1
+processingData
FinancialTransactionData
DisplayStatus
ProcessingData
1
1
0..1
+status
<<enumeration>>
FinancialTransactionTypeCode
FinancialTransaction
FinancialTransactionExtended
ProcessingStatus
PAYMENT
FUNDS_TRANSFER
1
0..1
1
+amount
1
21
1
+previousStep
+transactionType
CurrencyAmount
+status
0..1
0..1
1
+specification
FinancialTransactionSpecification
*
+note
Note
*
{ordered}
0..1
ProcessingStep
0..1
Copyright © 2004 InteliData
Payment entity model
FinancialTransactionConsumerData
FinancialTransactionSpecification
FinancialTransactionExtended
PaymentSpecification
PaymentExtended
Payment
0..1
0..1
+paymentSpecification
FiAccountSpecification
+source
0..1
1
1
+destination
RoutedPaymentSpecification
0..1
0..1
0..1
0..1
0..1
0..1
+remittanceDetail
PaymentRemittanceDetail
22
+paymentSpecification
0..1
PaymentDestination
0..1
0..1
+actualDestination
+destinationRoutingData
DestinationRoutingData
Copyright © 2004 InteliData
Payment value object classes
public abstract class FinancialTransactionBaseVO implements
ValueObject
{
private Long financialTransactionId;
private Date processDate;
private Date creditDate;
// Getter and setter methods
…
}
public abstract class FinancialTransactionConsumerDataVO
extends FinancialTransactionBaseVO
{
private CreationDataVO creationData;
private DisplayStatusVO displayStatus;
// Getter and setter methods
…
}
public class PaymentVO extends
FinancialTransactionConsumerDataVO
{
private RoutedPaymentSpecificationVO paymentSpecification;
// Getter and setter methods
…
}
23
Copyright © 2004 InteliData
Payment XML aggregate
<payment xsi:type="ns2:PaymentVO"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<financialTransactionId xsi:type="xsd:long">10006</financialTransactionId>
<processDate xsi:type="xsd:dateTime">2004-06-01T04:00:00.000Z</processDate>
<creditDate xsi:type="xsd:dateTime">2004-06-03T04:00:00.000Z</processDate>
<creationData xsi:type="ns2:CreationDataVO"> … </creationData>
<displayStatus xsi:type="ns2:DisplayStatusVO"> … </displayStatus>
<paymentSpecification xsi:type="ns2:RoutedPaymentSpecificationVO">
<source xsi:type="ns2:FiAccountSpecificationVO"> … </source>
<amount xsi:type="ns2:CurrencyAmountVO"> … </amount>
<destination xsi:type="ns2:PaymentDestinationVO"> … </destination>
<actualDestination xsi:type="ns2:PaymentDestinationVO">
…
</actualDestination>
<destinationRoutingData xsi:type="ns2:DestinationRoutingDataVO">
…
</destinationRoutingData>
…
</paymentSpecification>
</payment>
24
Copyright © 2004 InteliData
Payment tables
FINANCIAL_T RANSACTIONS
25
AUDIT_ID : NUMBER(9, 0)
ACTION_CODE : NUMBER(9, 0)
FI_TRANSACTION_SEQ_ID : NUMBER(9, 0)
LAST_MODIFIED_BY : NUMBER(9, 0)
CONSUMER_SEQ_ID : NUMBER(9, 0)
TRANSACT ION_TYPE : NUMBER(9, 0)
MODEL_INST ANCE_NUMBER : NUMBER(9, 0)
RECURRING_MODEL_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT _SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT _T YPE_CODE : NUMBER(9, 0)
SOURCE_ACCOUNT _NUMBER : VARCHAR2(32)
SOURCE_ROUT ING_NUMBER : VARCHAR2(9)
SOURCE_ACCOUNT _HOLDER : VARCHAR2(255)
REQUESTED_DAT E : DATE
REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)
CREDIT_DATE : DATE
PROCESS_DAT E : DATE
DISPLAY_STAT US_CODE : NUMBER(9, 0)
CURRENCY_CODE : CHAR(3)
AMOUNT : NUMBER(17, 2)
CONSUMER_MEMO : VARCHAR2(255)
DISPLAY_STAT US_MODIFIED_DAT E : DATE
DISPLAY_STAT US_MODIFIED_BY : NUMBER(9, 0)
DISPLAY_STAT US_NOT E : VARCHAR2(255)
PROCESSING_FLOW_TYPE : NUMBER(9, 0)
PROCESSING_TIME : DATE
RETRY_COUNT : NUMBER(9, 0)
DESTINATION_PROVIDER_SEQ_ID : NUMBER(9, 0)
PROCESS_STATUS_CODE : NUMBER(9, 0)
AUTHORIZAT ION_PROVIDER_SEQ_ID : NUMBER(9, 0)
DAYS_TO_CREDIT : NUMBER(9, 0)
SOURCE_PROVIDER_SEQ_ID : NUMBER(9, 0)
VALIDATE_STATUS_CODE : NUMBER(9, 0)
PROCESS_STATUS_PROVIDER_SEQ_ID : NUMBER(9, 0)
PROCESS_STATUS_MODIFIED_BY : NUMBER(9, 0)
PROCESS_STATUS_MODIFIED_DATE : DAT E
PROCESS_STATUS_NOTE : VARCHAR2(255)
VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)
VALIDATE_STATUS_MODIFIED_DATE : DAT E
AUDIT_DAT E : DATE
AUDIT_VERSION : NUMBER(9, 0)
VALIDATE_STATUS_NOTE : VARCHAR2(255)
AUDIT_GENERATION : NUMBER(9, 0)
PAYMENTS
AUDIT_ID : NUMBER(9, 0)
ACTION_CODE : NUMBER(9, 0)
FI_TRANSACTION_SEQ_ID : NUMBER(9, 0)
PAYEE_SEQ_ID : NUMBER(9, 0)
BILL_SEQ_ID : NUMBER(9, 0)
PROVIDER_SEQ_ID : NUMBER(9, 0)
PAYEE_NAME : VARCHAR2(255)
PAYEE_PHONE_NUMBER : VARCHAR2(32)
NAME_ON_ACCOUNT : VARCHAR2(255)
BILLING_ACCOUNT : VARCHAR2(255)
PAYMENT_DESTINAT ION_TYPE : NUMBER(9, 0)
ADDRESS1 : VARCHAR2(64)
ADDRESS2 : VARCHAR2(64)
ADDRESS3 : VARCHAR2(64)
ADDRESS4 : VARCHAR2(64)
CITY : VARCHAR2(32)
ST ATE_PROV : VARCHAR2(32)
POSTAL_CODE : VARCHAR2(11)
COUNT RY_CODE : CHAR(3)
ACT_PAYEE_NAME : VARCHAR2(255)
REMITTANCE_METHOD : NUMBER(9, 0)
ACT_PAYEE_PHONE_NUMBER : VARCHAR2(32)
ACT_NAME_ON_ACCOUNT : VARCHAR2(255)
ACT_BILLING_ACCOUNT : VARCHAR2(255)
ACT_PAYMENT _DEST INATION_TYPE : NUMBER(9, 0)
ACT_ADDRESS1 : VARCHAR2(64)
ACT_ADDRESS2 : VARCHAR2(64)
ACT_ADDRESS3 : VARCHAR2(64)
ACT_ADDRESS4 : VARCHAR2(64)
ACT_CITY : VARCHAR2(32)
ACT_STATE_PROV : VARCHAR2(32)
ACT_POST AL_CODE : VARCHAR2(11)
ACT_COUNTRY_CODE : CHAR(3)
CHECK_NUMBER : VARCHAR2(40)
ACT_REMITT ANCE_METHOD : NUMBER(9, 0)
SERVICE_CENT ER_SEQ_ID : NUMBER(9, 0)
MERCHANT _SEQ_ID : NUMBER(9, 0)
DEFAULT _ROUTING_REASON : NUMBER(9, 0)
DAYS_TO_PROCESS : NUMBER(9, 0)
AUDIT_VERSION : NUMBER(9, 0)
AUDIT_GENERATION : NUMBER(9, 0)
AUDIT_DAT E : DATE
Copyright © 2004 InteliData
Conclusions
• MDA has value, even without automated transformation.
• Advantages of manual transformation
– No need to purchase and learn transformation tools.
– No need to develop and maintain formal, executable
transformation definitions.
– Ability to quickly adapt as circumstances dictate.
• Disadvantages of manual transformation
– Requires continuing effort and process discipline.
– Unintentional inconsistencies are inevitable.
– Compromises most be made to keep transformations simple
enough to be manually tractable.
– Care must be given to maintaining clear traceability.
26
Copyright © 2004 InteliData