The document discusses a case study on Model-Driven Architecture (MDA) applied in the context of consumer bill payment systems, detailing the architecture, development process, and transformations involved. It outlines the iterative development approach, the introduction of significant modeling, and the establishment of a complete MDA approach by mid-2003. Additionally, the document includes specific technical elements such as logical data models, sequence diagrams, and code examples relevant to the implementation of the Inteliworks architecture.

1. Copyright © 2004 InteliData
A Real-World Example of
MDA without Automation
Ed Seidewitz
26 August 2004

2. Copyright © 2004 InteliData2
Agenda
• Background
• Model-driven architecture
• Case study
• Conclusions

3. Copyright © 2004 InteliData3
Background
• Consumer bill payment
• InteliWorks architecture
• InteliWorks development

4. Copyright © 2004 InteliData4
Background: Consumer bill payment
Consumer
Computer
ConsumerConsumer
ComputerComputer
Web Banking/
Bill Pay UI
Web Banking/Web Banking/
Bill Pay UIBill Pay UI
Bill Payment
Warehouse
Bill PaymentBill Payment
WarehouseWarehouse
Funding
System
FundingFunding
SystemSystem
Remittance
Provider
RemittanceRemittance
ProviderProvider
Internet
Bank-owned systems
Batch files
(Bank system /ACH / …)
MerchantsMerchantsMerchants

5. Copyright © 2004 InteliData5
Background: InteliWorks architecture

6. Copyright © 2004 InteliData6
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.

7. Copyright © 2004 InteliData7
Model-driven architecture
• What is it?
• What is a platform?
• CIM, PIM, PSM and all that…
• Transformations
• Why “manual transformation”?

8. Copyright © 2004 InteliData8
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.”

9. Copyright © 2004 InteliData9
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.”

10. Copyright © 2004 InteliData10
MDA: CIM, PIM, PSM and all that…
• “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.”
From the MDA Guide Version 1.0.1 (omg/2003-06-01)

11. Copyright © 2004 InteliData11
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

12. Copyright © 2004 InteliData12
Case study
• Overview
• Architecture
• Data

13. Copyright © 2004 InteliData13
Case study: Overview
Consumer: Payment - View
Payments
Consumer
Consumer: Payment - Cancel
Consumer: Payment - Create
(without Bill)
Consumer: Payment - Modify
Consumer: Payment - View
Activity
<<extend>>
Consumer: Payment - Validate
<<extend>>
<<include>>
<<extend>>
<<include>>
Consumer: Payment - Route
<<include>> <<include>>
<<extend>>
Requirements Model
(use case and activity diagrams)
PaymentService
PaymentFe
<<Interface>>
addPayment()
cancelPayment()
getPayments()
getPaymentActivity()
updatePayment()
PaymentRead
PaymentEvent
<<Interface>>
processPayments()
PaymentFeExtended
<<Interface>>
addPaymentNoteExtended()
completePaymentExtended()
failPaymentExtended()
getPaymentsExtended()
pendPaymentExtended()
resubmitPaymentExtended()
reversePaymentExtended()
Notification
(from eMessenger)
FinancialTransactionCommon
(from Financial Transaction Service)
PayeeUtility
AccountUtility
FinancialTransactionWrite
OperationalDirectory
(from Operational Directory Service)
FinancialTransactionUtility
(from Financial Transaction Service)
FinancialTransaction
(from Financial Transaction Service)
SchedulingEvent
(from Scheduler)
Payment
<<Interface>>
handlePayeeChange()
FinancialTransactionRead
PaymentUtility
<<Interface>>
prepare()
getRouting()
checkForDuplicate()
Dependency Model
(class diagrams)
: Consumer : ConsumerFrontEnd : XmlConnector : PaymentService : FinancialTransactionService
Sequence Diagram: InteliWorks
Consumer: Payment Realizations /
Consumer: Payment - View Payments
1. Create payment
2.1. addPaymentRq
2.1.2. addPaymentRs
1.2. Display confirmation
2. Ok
3. Close view
3.1. View payments
2.1.1. addPayment( )
2.1.1.2. payment
1.1. Enter payment
Sequence Diagram: InteliWorks
Consumer: Payment Realizations /
Consumer: Payment - Enter
2.1.1.1. addFinancialTransaction( )
2.1.1.1.1. financialTransaction
Sequence Diagram: InteliWorks
Consumer: Financial Transaction
Realizations / Consumer: Financial
Transaction - Add
Architectural Realizations
(sequence diagrams)
FinancialTransactionBase
DisplayStatus
CreationData
FinancialTransactionConsumerData
1 11
+displayStatus
1
+creationData
11
FinancialTransactionData
FinancialTransaction
Note
FinancialTransactionExtended
0..1
*
0..1
+note*
CurrencyAmount
FinancialTransactionTypeCode
<<enumeration>>
PAYMENT
FUNDS_TRANSFER
FinancialTransactionSpecification
0..1
1
0..1
+specification1
0..11 0..1
+amount
1
+transactionType
11
ProcessingData
1 11
+processingData
1
ProcessingStatus
0..1
1
0..1
+status 1
ProcessingStep
0..1
*
0..1
+previousStep
{ordered}
*
+status
0..1
1
0..1
1
Logical Data Model
(class diagrams)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Interface Code
(EJB)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Web Services Code
(WSDL/SOAP)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Value Object Code
(Java)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Schema Code
(SQL)
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_DESTINATION_TYPE : NUMBER(9, 0)
ADDRESS1 : VARCHAR2(64)
ADDRESS2 : VARCHAR2(64)
ADDRESS3 : VARCHAR2(64)
ADDRESS4 : VARCHAR2(64)
CITY : VARCHAR2(32)
STATE_PROV : VARCHAR2(32)
POSTAL_CODE : VARCHAR2(11)
COUNTRY_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_DESTINATION_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_POSTAL_CODE : VARCHAR2(11)
ACT_COUNTRY_CODE : CHAR(3)
CHECK_NUMBER : VARCHAR2(40)
ACT_REMITTANCE_METHOD : NUMBER(9, 0)
SERVICE_CENTER_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_DATE : DATE
FINANCIAL_TRANSACTIONS
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)
TRANSACTION_TYPE : NUMBER(9, 0)
MODEL_INSTANCE_NUMBER : NUMBER(9, 0)
RECURRING_MODEL_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT_TYPE_CODE : NUMBER(9, 0)
SOURCE_ACCOUNT_NUMBER : VARCHAR2(32)
SOURCE_ROUTING_NUMBER : VARCHAR2(9)
SOURCE_ACCOUNT_HOLDER : VARCHAR2(255)
REQUESTED_DATE : DATE
REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)
CREDIT_DATE : DATE
PROCESS_DATE : DATE
DISPLAY_STATUS_CODE : NUMBER(9, 0)
CURRENCY_CODE : CHAR(3)
AMOUNT : NUMBER(17, 2)
CONSUMER_MEMO : VARCHAR2(255)
DISPLAY_STATUS_MODIFIED_DATE : DATE
DISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0)
DISPLAY_STATUS_NOTE : 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)
AUTHORIZATION_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 : DATE
PROCESS_STATUS_NOTE : VARCHAR2(255)
VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)
VALIDATE_STATUS_MODIFIED_DATE : DATE
AUDIT_DATE : DATE
AUDIT_VERSION : NUMBER(9, 0)
VALIDATE_STATUS_NOTE : VARCHAR2(255)
AUDIT_GENERATION : NUMBER(9, 0)
Database Design Model
(class diagram)
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxx
xxxxxxxxx
xxxxxxxxx
xxxxxxx
xxxxxxxxxx
xxxxxxx
]xxxx
Schema Definition
(Torque XML)
CIM
PIM
PSM
PIM/PSM
hand coded hand coded
handcoded
generated
generated
generated
reverse
engineered
hand modeled hand modeled
handmodeled
traceshand modeled
Implementation platform
• J2EE (WebLogic app server)
• Relational DB (Oracle DBMS)
• Web services (Apache Axis)

14. Copyright © 2004 InteliData14
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.

15. Copyright © 2004 InteliData15
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

16. Copyright © 2004 InteliData16
Payment Service dependencies
PaymentService
PaymentFe
<<Interface>>
addPayment()
cancelPayment()
getPayments()
getPaymentActivity()
updatePayment()
PaymentRead
PaymentEvent
<<Interface>>
processPayments()
PaymentFeExtended
<<Interface>>
addPaymentNoteExtended()
completePaymentExtended()
failPaymentExtended()
getPaymentsExtended()
pendPaymentExtended()
resubmitPaymentExtended()
reversePaymentExtended()
Notification
(from eMessenger)
FinancialTransactionCommon
(from Financial Transaction Service)
PayeeUtility
AccountUtility
FinancialTransactionWrite
OperationalDirectory
(from Operational Directory Service)
FinancialTransactionUtility
(from Financial Transaction Service)
FinancialTransaction
(from Financial Transaction Service)
SchedulingEvent
(from Scheduler)
Payment
<<Interface>>
handlePayeeChange()
FinancialTransactionRead
PaymentUtility
<<Interface>>
prepare()
getRouting()
checkForDuplicate()

17. Copyright © 2004 InteliData17
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 { … }
}

18. Copyright © 2004 InteliData18
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; }
}

19. Copyright © 2004 InteliData19
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>

20. Copyright © 2004 InteliData20
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

21. Copyright © 2004 InteliData21
Financial transaction entity model
FinancialTransactionBase
DisplayStatus
CreationData
FinancialTransactionConsumerData
1 11
+displayStatus
1
+creationData
11
FinancialTransactionData
FinancialTransaction
Note
FinancialTransactionExtended
0..1
*
0..1
+note*
CurrencyAmount
FinancialTransactionTypeCode
<<enumeration>>
PAYMENT
FUNDS_TRANSFER
FinancialTransactionSpecification
0..1
1
0..1
+specification1
0..11 0..1
+amount
1
+transactionType
11
ProcessingData
1 11
+processingData
1
ProcessingStatus
0..1
1
0..1
+status 1
ProcessingStep
0..1
*
0..1
+previousStep
{ordered}
*
+status
0..1
1
0..1
1

22. Copyright © 2004 InteliData22
Payment entity model
PaymentExtended
PaymentRemittanceDetail DestinationRoutingData
FiAccountSpecification
Payment
FinancialTransactionConsumerData FinancialTransactionSpecification FinancialTransactionExtended
PaymentSpecification
PaymentDestinationRoutedPaymentSpecification
0..1
1
0..1
+paymentSpecification
1
0..1
0..1
0..1
+remittanceDetail
0..1
0..1
0..1
0..1
+destinationRoutingData0..1
0..10..1 0..1
+source
0..1
0..1
1
0..1
1
+paymentSpecification
0..1
0..1
0..1
+actualDestination0..1
+destination
0..1 0..10..1 0..1

23. Copyright © 2004 InteliData23
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
…
}

24. Copyright © 2004 InteliData24
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>

25. Copyright © 2004 InteliData25
Payment tables
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_DESTINATION_TYPE : NUMBER(9, 0)
ADDRESS1 : VARCHAR2(64)
ADDRESS2 : VARCHAR2(64)
ADDRESS3 : VARCHAR2(64)
ADDRESS4 : VARCHAR2(64)
CITY : VARCHAR2(32)
STATE_PROV : VARCHAR2(32)
POSTAL_CODE : VARCHAR2(11)
COUNTRY_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_DESTINATION_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_POSTAL_CODE : VARCHAR2(11)
ACT_COUNTRY_CODE : CHAR(3)
CHECK_NUMBER : VARCHAR2(40)
ACT_REMITTANCE_METHOD : NUMBER(9, 0)
SERVICE_CENTER_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_DATE : DATE
FINANCIAL_TRANSACTIONS
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)
TRANSACTION_TYPE : NUMBER(9, 0)
MODEL_INSTANCE_NUMBER : NUMBER(9, 0)
RECURRING_MODEL_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT_SEQ_ID : NUMBER(9, 0)
SOURCE_ACCOUNT_TYPE_CODE : NUMBER(9, 0)
SOURCE_ACCOUNT_NUMBER : VARCHAR2(32)
SOURCE_ROUTING_NUMBER : VARCHAR2(9)
SOURCE_ACCOUNT_HOLDER : VARCHAR2(255)
REQUESTED_DATE : DATE
REQUESTED_SCHEDULE_TYPE : NUMBER(9, 0)
CREDIT_DATE : DATE
PROCESS_DATE : DATE
DISPLAY_STATUS_CODE : NUMBER(9, 0)
CURRENCY_CODE : CHAR(3)
AMOUNT : NUMBER(17, 2)
CONSUMER_MEMO : VARCHAR2(255)
DISPLAY_STATUS_MODIFIED_DATE : DATE
DISPLAY_STATUS_MODIFIED_BY : NUMBER(9, 0)
DISPLAY_STATUS_NOTE : 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)
AUTHORIZATION_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 : DATE
PROCESS_STATUS_NOTE : VARCHAR2(255)
VALIDATE_STATUS_MODIFIED_BY : NUMBER(9, 0)
VALIDATE_STATUS_MODIFIED_DATE : DATE
AUDIT_DATE : DATE
AUDIT_VERSION : NUMBER(9, 0)
VALIDATE_STATUS_NOTE : VARCHAR2(255)
AUDIT_GENERATION : NUMBER(9, 0)

26. Copyright © 2004 InteliData26
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.