Different cases require different solutions. Although blockchain’s main and still leading use case is cryptocurrencies, it gains popularity in other areas. One research points out that besides traditional banking and trading usage, blockchain applications are rarely known even among Computer Science students.
Blockchain characteristics are determined by their type and have particular implications. It is not an appropriate solution to use cases that necessitate a high level of privacy. If a solution is needed for a homogeneous environment where everyone trusts each other and has full control over the flow of data, and the environment itself is not exposed to any external threats – blockchain is going to be a very slow and disturbing database.
The technology becomes relevant if dealing with a lack of trust in the network. But before analysing specific blockchain use-cases, let’s break down the problems.
In 2009 Satoshi Nakamoto released the first decentralised cryptocurrency – Bitcoin. It was the first implementation of blockchain technology.
Blockchain is mainly associated with cryptocurrency. Yet the specific blockchain type utilised for this relatively new financial use case is just a tip of an iceberg. Recent approaches incline towards enterprise usage. Employing blockchain into Supply Chain Management (SCM) enables to track product or service subsequent states in the business flow. Business partners can join the blockchain network to either read or write information to the ledger history.
As a software house’s client, you should be prepared to go through a process of estimating the cost and time needed for developing an app. While this seems straightforward and most of the estimation work is done by the software house’s team, there are many areas which you should approach with mindfulness. To be successful, within budget, and on time, it is best to work closely with the development company.
Here is a 9-step guide that will help you and your provider work better together.
Individual investor diagnosing, profiling and training in banks has been traditionally done through interviews or pen-and-paper questionnaires. Hypothekarbank Lenzburg AG has decided to take a leap into algorithmic gamification to better understand their customers and prepare truly tailored offers for them.
https://flic.kr/p/bER864
Can it get more exciting than that?
This autumn we teamed up with our new client, the London-based Munich Re Digital Partners (MRDP), to work on a sophisticated API that is revolutionizing on-demand insurance.
MRDP is a business venture that aims to change the way insurance is offered on PCs and mobile devices. While there are many InsurTech start-ups offering new ways to bring insurers and customers together, they often focus on the frontend and UX. MRDP offers them the back-end technology and helps them develop their disruptive products more effectively. The project we work on will also be a vehicle for AI-based capabilities.
FINGO was chosen as the nearshoring partner for the project because of our expertise in building large APIs with global exposure and heavy traffic loads. Currently our shared London/Wrocław team consists of 5 developers and 2 DevOps engineers and is set to grow in the beginning of January 2016.
Let’s call it Application X* (the software is real, but I changed the name).
When a few years ago our developers first looked at the existing code of Application X, they were not exactly happy. It wasn’t the cleanest they’ve seen. It was far from the standards they got used to. PHP was polluted with HTML and MySQL queries. The names of variables were not in English, but in the client’s native language. The project tracking solution used by the client’s dev team so far was clunky and the development methodology was in it’s infancy.
These were some of the challenges we faced after we decided to take over the development of Application X. So, what happened?
I remember that day – we all had a big laugh.
About 5 years ago, the corporation I worked for announced the “zero e-mail program”. The global policy was meant to do exactly what it said – make our inboxes obsolete. Back then it seemed like a joke. The rumors said we would be using a hybrid of Facebook and Skype, invented specifically for businesses.
As we kept sorting out the tens of e-mails that were cc’d to us last night without any specific reason, sarcasm filled our rooms. We refused to take the whole idea seriously. It often happens when low-level employees are presented with a bold managerial vision. They are the soldiers on their front-line, and they know that their assault rifles will not be swapped for plasma guns, even when the president says so. Not in their life.
Having software developed by an external vendor usually entails a degree of uncertainty, especially when done by a new partner. It is quite obvious that building trust often requires some time. The fact that the application will be unique and has not been tested by “crash test dummies” in the past is an additional risk factor. While all this is true, custom made solutions are sometimes a necessity – out-of-the box products simply won’t get the job done. The question is how the process of designing and developing the software can be a smooth ride for the client. Enters agile software development – here are five ways in which it takes the load of a client’s back.