This week's book giveaway is in the Cloud forum.
We're giving away four copies of The Business Blockchain and have William Mougayar on-line!
See this thread for details.
Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part 2 : Question about FF system spec

 
E. Messing
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The FF secs are very vogue. I couldn't seem to understand whether it is
* only a "checking-account" like application - that gets the customer , and the mileage to add/deduct from its account.
OR
* has deep "Business Logic" (B.L.) and the system gets the customer, the flights he ordered, and knows how to calculate the mileage to add/deduct.
There are certain issues that arise from choosing either choice like :
If option 2 - then does the Itinerary application shows (in the "show itinerary price to customer) the number of mileage needed for the trip (because this knowledge is part of the FF system - not the itinerary system). This means that the interaction between the new J2EE application will be to fully interact with the FF system - not just "retrieve the customers mileage account status".
Also - if option 2 - what happened before the FF system was built ? The FF program (not "computer-program" , but "customer-program") was there for a long time ago, and surly the 3270 application knows that paying in mileage is an option, so where was all this B.L before ?
If option 1 - then why did they spent .5M dollars on a simple calculator.. doesn't seem logic to build such a program just for that...

What do you think ?
 
E. Messing
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anyone ?
 
Jogi Poonawala
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO FF system is "Read-Only" type of system as far as Customers /Travel agents are concerned. The Itenary system only needs to make sure that the customer has required award miles in his account. Updating FF miles(B.L.) is out of scope of this Itenary sysytem. May be there are cron jobs/ batch scripts running some SQL which updates FF database directly from
Itenary database. OR som asynch. service between Itenary and FF system etc.
As far as spending .5M is concerned.. may be they built this system in 2000 when contracting rates for web programmers were $100+/ hour
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using mileage is just another means of payment. Your solution put the mileage payment (in contrast to Credit Card Payment) out the scope of a transaction, which loses all ACID transaction properties. for example, what if the customer uses his available mileage twice before the FF system get updated by the cron job, which runs 12:00 AM that day?
The gain is that, it is asychronous. Then we come to the fundamental question, when do we need the pain to develop a interactive website based on request/response synchronous model? Interactive implies, users expect response less than 30 seconds in general.
 
Jogi Poonawala
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you. Making updates to FF system a batch job does leave some loopholes as you suggested.(May be increase the frequency of updates or put some dirty trigger logic ? ) But thinking from assignment's point of view, the only requirement is to check for the availability of the required miles. Nowhere it is mentioned that the miles should be updated by the Itenary system. May be in future when they re-write the FF system using J2EE this issue can be addressed. Till then FBN will have some kind of corrective process in place (e.g. If one has to book a flight using FF miles then he/she has to book at least 2 days in advance which gives FBN officials sufficient time to resolve fraudulent miles usage) OR in worst case FBN will take the hit in case of dispute.
To address your question
"when do we need the pain to develop a interactive website based on request/response synchronous model? Interactive implies, users expect response less than 30 seconds in general."
IMHO, its primarily a business decision. If number of Frequent Fliers increase to such a number that FBN can not afford to take the hit and/or they make sufficient profit to invest into rewriting the FF system, we should develop a synchronous model.
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As an architect, you are supposed to answer the following questions:
when, how and who will update the FF system.
It is totally OK if you delegate the responsibility to some subystems or external/internal components. However, you still need to answer those above questions even thought the requirement doesn't explicitly require so.
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As an architect, you are supposed to answer the following questions:
when, how and who will update the FF system.
It is totally OK if you delegate the responsibility to some subystems or external/internal components. However, you still need to answer those above questions even thought the requirement doesn't explicitly require so.
 
Denis Wang
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As an architect, you are supposed to answer the following questions:
when, how and who will update the FF system.
It is totally OK if you delegate the responsibility to some subystems or external/internal components. However, you still need to answer those above questions even thought the requirement doesn't explicitly require so.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic