Business diagnostics for line of business applications
After my podcast about RavenDB’s dev ops story, I was asked an interesting question by Remi:
…do you think it can work with non technical product (let's say banking app) where your user and your engineer are not in the same industry.
This is quite an interesting scenario. A line of business application is going to be composed of two separate planes. You have the technical plane, which is fairly standard and you can get quite a lot of mileage from standard dev ops monitoring tools. For example, you probably don’t need the same level of diagnostics in a web apps or a service backend as you need for a database engine. However, the business plane is just an interesting an area and often can benefit quite a bit by building business level diagnostics into the application.
If we’ll take the example of banking app, you might want to track things such as payment flow across various accounts. You may want to be able to get a view of a single user’s activities over time or simply have a good visibility to various financial instruments.
I have run into several cases were I had to break down how loans work (interest, compounding, collateral, etc) for college educate people who were really quite smart, but didn’t pay attention to that part of life. Given that I consider loans to be one of the simplest financial instruments, building visibility into these can be of great help.
Still in the banking field, just the notion of taxation is freakishly complex. I have had a case where a customer in India was suppose to pay us a 1,000 USD. They sent 857 USD (a bit of that was eaten by bank fees) and the rest we had to claim as a refund from my tax authorities, because the rest of the money was paid as taxes in India and the two countries are doing reconciliation. Given the inherent complexity that is involved, just being able to visual, inspect and explain things is of enormous value.
Things like Know Your Customer and Anti Money Laundering are also quite complex and can put the system into a tail spin. I had a customer send us a payment, but the payment was stopped because the same customer also paid (in a completely different transaction and to a different destination entirely) with funds that came from crypto currencies. Leaving aside the aggravation of such scenarios, I am actually impressed/scared that they are able to track such things so well.
I can’t really be upset with the bank, even. Laws and regulations are in place that have strict limits on how they can behave, including personal criminal liability and Should Have Known clauses. I can understand why they are cautious.
But at the same time, trying to untangle such a system is a lot like trying to debug a software system. And having the tools in place for the business expert to easily obtain and display the data is an absolute competitive advantage.
I have recently close a bank account specifically because the level of service provided didn’t meat my expectations. Having better systems in place means that you can give better service, and that is worth quite a lot.
Comments
Thanks for the dedicated answer post :) Maybe I'm extrapolating but this is all the same as the devops saying "you build it, you run it ... you support it". In my previous company (I stayed there 11 years) I have never been in touch with a user a single time (I don't think anyone in the company either), maybe some customers for working on specs, but never for support. In my current company, only after a few days I was in, I got a user on call because he couldn't enter its IBAN, the next day we shipped a change to our IBAN input for making it easier to understand and I think it's great for the product, bad for the productivity (context switch). I didn't do it because I wanted to make our product great, I did it because I wanted to stop this kind of phone calls :D
Remi, Oh, yes!Full ownership for a product is a really important feature, yes. Sometimes, there are real concerns about "you run it" (regulatory, privacy, etc). But at a minimum, 2nd stage support for users should be handled by the actual team.Otherwise, you get into funny state where the dev team building the product has no idea how it is actually being used.You get important features that are just meaningless for the users, while log hanging fruits that can make a difference is ignored, because the feedback loop has been severed.
What about DDD / UL / SME ?
Ovi,
These are unrelated. I was talking specifically about building "devops" tools inside the business application.
@Rémi "I didn't do it because I wanted to make our product great, I did it because I wanted to stop this kind of phone calls" Huh, I have found in my position that when I do something, they just come back for more:)
Peter, That is correct, but there is a world of difference in the type of calls you get.If you don't have to guess, and can tell, that change the interaction a _lot_.
This is a test post.
Comment preview