Architecture - Integration Migration API Design

Category:
  • Architecture
  • No categories

4 Reasons Football Teams Should Use Big Data and IoT

17th September 2014 in Architecture
This is a case why football teams (or soccer for my transatlantic friends) should make greater use of the Internet of Things and big data.
Here are some 5 simple reasons: 

1. Player health tracking

In 2012, then only 24 years of age, Fabrice Muamba a footballer from Bolton Wanderers suffered an heart attack on live TV during an FA Cup game. This was not the first such incident on live TV; Marc-Vivien Foe, the Cameroonian player, died on June 26 2003 during a confederation cup game against France. Not to mentioned what happens off-pitch, football club have a duty to look after their players and that’s including their health.Let’s clear, I’m not saying that current health wearable devices could have saved them but they could have played a great role. Read the signs early to avoid the disaster as prevention will always be better than the cure.So how can be big data helps us improve the athletes health? You may ask. I will simplify it for illustration purposes. Teams need to put in a place an IoT and Big Data strategy where athlete will wear various devices during training and games. Think about a heart monitoring bracelets that players can wear during training and games for the physiotherapy team to analyse later or in real time. The devices will record the time, number of foot steps (within a period – in order to differentiate between walking and running) and heart rate. Let’s say that player John Smith health is changing during the game, the physios will get alerted of the change of condition and can take appropriate actions. Maybe we can add devices to shin pads so that players do not have to wear uncomfortable devices.

2. Player positioning and technique

Great players do this naturally but not all players are born equal. I remember when I used to play football in my early teen for USO back in France. In training, we would learn how to shoot, head the ball and basic skills. The trainer would then let us know what we did wrong and how to ameliorate our techniques. Now professional players have a large team working with them daily; strikers will have coaches to help them for attacking positioning, goal keeper will have coaches too and etc… The current tech used by the teams are heavy duty machine which are employed behind close doors. How can IoT make improve on this? Again through wearable technology, we can track players movement. GPS integrated devices will track player movement over a map (football field), chin pad enabled devices will help visualise the player shooting techniques. The list of devices are only limited to your own imagination but the possibilities are endless. Players can then analyse their own data or with the help of their coach, see how they can improve. No more killing pigeons with those bad shots over the bar!

3. Team metrics

Now what is the point of all that data generated if not put to use? We have health data and game metrics (positioning and technique) about the whole team. The players health will give us an indication of who is fit for game. Being a big fan of the beautiful game, we have observed how various conditions can affect a player performance such as weather and pitch condition. The data scientists would analyse who can perform better under the current conditions. Don’t get it wrong; top players, if fit for the game, are indispensable to the team but all advices should be welcomed. You will have what we call “the best team on paper”. Gamblers use this technique in various events to pick their winners/ losers.

4. Opponents analysis

Usually we can find a wealth of information about teams from various sources such as sport sites, videos and blogs. The more you know about your opponents the better you will perform (Sun Tzu – Art of War). Team changes twice a year (transfer window) for those who can afford it. Is a team really as good as their last game? This question can be answered with big data analytics. Taking the conditions into consideration and our own team metrics, we can pick a strategy (team formation, defensive or attacking…). The big data gives (all) the information that we need in order to make decisions.

Conclusion

The Internet of Things (IoT) and Big Data provides an opportunity, even if not new, to gather information and make executive decisions much faster than before. There should not be any reasons not to have the full picture before hand. Football, as any other sports, is very competitive and everyone wants to create advantage. IoT devices are getting cheaper and more data can be collected for analysis. Big Data has the tools but not a silver bullet. We can prevent tragedies by tracking our players health and help them improve by analysing their techniques. Let’s realistic that winning a game is probably beyond Big Data and IoT alone but they will play a big part in shaping the future of the game.

Big Data is not a product – the idiosyncratic hype

18th January 2013 in Architecture
Marketers have been building the hype around “Big Data”. Recruitment agencies have received many positions to fill around “Big Data”.  But who is to blame when you receive a call from a recruiter who believes that “Big Data” is a product?

Recruiters

“Where ignorance is bliss, ’tis folly to be wise.” – Thomas Grays

A recruiter who does not carry out any sort of research on the role that he’s try to fill is simply an idiot. The fact is that job specs from companies can be very brief and the recruiter job is to source the best candidate for the role. Engineers hate recruiters but they feel that they need to speak to them if they have to land that next big opportunity. I had a call from a recruiter asking to send him one of our developers. He was adamant that “Big Data” was a product. He kept on asking if our developers had experience with the product called “Big Data”. I tried to make him understand that there’s no such product that I know
of. After a while, he became aggressive and I had to end the call. I blame the recruiter for lack of research and its neglect about “Big Data” and its relevant technologies. If he did carry out some research about the topic, I believe that he could have appeared more professional.

Engineers

IT Departments looking for “Big Data” practitioners have to share some of the blame. They write the job specs to be sent out to a recruitment company. You can’t send a job description for a data analyst and only have Hadoop and “Big Data” in it. You need to provide more information such as: job description and project background and then what sort of person you sought after.  Engineers are not marketers thus they have better understanding of the technologies. We know what we want and who can do the job, therefore why not facilitate the recruiter job by providing more information beforehand?
In conclusion, Big Data is not a product and next someone calls and tells me, I will put the phone down on him. Research your topic before contacting anybody about a job opportunity.

A software architect is not a senior developer

6th January 2013 in Architecture
There are some IT departments till this day who believes
that by hiring a senior developer they can fulfil the role of a software
architect.
Senior developers have much knowledge about the full
software lifecycle and can be trained to be architects but are they are not. A software
architect first and foremost is a visionary. It helps that an architect has some
software development experience but most of the time, he will be exposed to a
polyglot environment. Before a single line of code is written, the architect
will have to map out how the business requirements can be translated into a
solution. This not only requires knowledge of the business environment, from
operations to infrastructure, but to present a convincing system to the
stakeholders. Requirements such as scalability, latency and security will be
missed from initial development stage if not tackled early on. Senior
development understands their team and their abilities. Senior developers can
manage workloads amongst team members and make sure that the under-development project
meets its architectural goal.
The architect will decide how a requirement should be
developed in order to meet the business requirement as an example:
The business has
offices around the globe, the business requirements require the website to be
fully loaded within 3s regardless of the location of the user and handle a
minimum load of a hundred thousand users. 
The above requirements are dealing with the architecture of
the system not that we can authenticate a user against an Oracle DB.
It is important to note that many Software Architect were
previously working as Senior Developer (such as myself) but nonetheless, many
senior developers have no interest in architecture. Choosing if a system should
use Tomcat or Glassfish and Apache Webserver for load balancing is the domain
of the Architect. Doing code review and making sure software development
pattern are well applied, is the domain of Senior Developer. A senior developer
can also choose a development methodology such as SCRUM with the approval of the
Project Manager. The architect would attend meetings with the various
stakeholders: end users, operation, infrastructure, development and testing
teams. When the business asks why is the system slow, they will turn to the
architect. The architect would then have to sit down with the lead senior
developer and review that the current development meets the architecture goals
or if there are faults in the architecture design.
I am a software architect and I can easily communicate my
vision to the development team but I am also a senior developer who still loves
hacking the machines. I worked in an architecture committee and came across
architects who have no development experience which I think it is wrong. An
architect should appreciate other development languages not to be biased toward
a single one without any merit.
I hope that more companies will appreciate the role of
software architects in software projects regardless of its size.