As a software engineer, we want to be recognized as exceptional in delivering code that functionally delivers against the user needs and doesn’t introduce performance issues or defects into the production environment. We want our code to elegantly solve the problem that has been described and delights the user. If the code that we develop is a smaller slice of an overall application or platform, we want to ensure that our integration points are rock solid, that we are doing nothing to impact the ability of the larger application or platform to successfully process and perform the function as it was designed.
It is critical that as a software development professional, we teach ourselves how data flows thru the system. How does the data flow into the application function that we are developing, how does the data get manipulated by the function we are creating and what happens to the data when it leaves our function. This means breaking the data down into its discreet elements and understanding how they are manipulated ahead of us, what we are going to do with them as we execute the new or changed functionality and what happens after it leaves us.
Let’s take a small scenarios (and I’m oversimplifying the scenario to make the point) … a Cardholder walks up to an ATM and inserts their card into the machine to request a $100 withdrawl. Behind the scenes the machine captures information off of the card to send to the financial institutions Processor. The Processor receives the information off the card and checks the balance in the bank account and spits out the $100 to the Cardholder. Mission accomplished – right? Nope!
The ATM in the above scenario is not owned by the financial institution where the Cardholder has their money deposited. So, somehow we have to settle the money between the two financial institutions. The withdrawl is one distinct component of the overall transaction. We need to follow the data from the original transaction to the end of the day when the money actually moves between the financial institution that dispensed the $100 from the ATM they owned and the financial institution that holds the Cardholders funds. Whew, done! Not exactly.
At the end of the month, the Processor must bill for the services provided to the financial institution that holds the Cardholders funds. There are specific transaction fees that get charged based on volume.
Now, let’s think about the software engineer that works for the Processor. Not only do they have to see the data in real-time and make authorization decisions, but they need to move the money at the end of the day and ensure that the financial institution is billed properly at the end of the month.
To follow the data, the software engineer needs to understand what data is read by the card reader at the ATM and is transmitted into the data center for authorization. They must understand how to match the card data up to the financial institution cardholders account to check balances, they must understand the authorization cycle and how the individual data elements in the card data are used to detect fraud and either accept or decline the transaction, they must understand how that data moves thru the system and is stored to ensure that the money moves between financial institutions at the end of the day, and they must understand how the data is used at the end of the month to properly bill the financial institution based on the type of transaction and other factors.
The software engineer cannot be sure that the functionality that they changed is working properly until they’ve tested the data all the way thru the transactions lifecycle to ensure that it settled at the end of the day and that the financial institution was billed properly at the end of the month. Testing should be designed with the full data flow in mind, not just the partial discreet transaction where the money was dispersed to the Cardholder. Again, I’ve oversimplified, but this scenario does describe the breadth of understanding that a developer must have before they can claim success.
Now add in some side scenarios – let’s say the data is used in web and mobile applications where the Cardholder can view transaction history data and initiate fraud claims. Those data usage scenarios introduce additional data flows that the software engineer must understand and validate before they can claim success.
Understanding how the data flows, where it is stored, how it gets manipulated prior to, during and after the function you are working on, is critical to understanding whether you actually can design, develop, test and deliver the functionality correctly. Knowing how to code is the simple part, understanding how the data moves and is manipulated is the hard part.
If you'd like more information on my background: LinkedIn Profile
No comments:
Post a Comment