previous article
A particularly productive current discussion (also see the blog post of my colleague Simon Nehls) revolves around the question what a data science team should actually sensibly produce. The two possibilities are quickly named: on the one hand, there is the "analysis", thus, a one-off, rather static final result; in this context, most people immediately think of a PowerPoint presentation. On the other hand, there is the "app", i.e. an interactive end product continuously supplied with fresh data, frequently in the form of a website or a mobile app.
Apps on the Rise
In the course of this discussion, app supporters are currently on the offensive. They are aided by the fact that the internet, characterized by static websites only ten years ago, is becoming increasingly interactive and dynamic and thus moves our expectations towards the app. If my information medium number one is interactive and constantly up-to-date, I do not understand why that should be different regarding the output of my data science team. Everything else is no longer up-to-date. This argument is popular, but superficial and general. If you indulge yourself in a little more differentiation, the discussion becomes noticeably more exciting, because the app as end product changes the functioning of a data science team radically. This blog post wants to show that for each data science team it is worth to engage in this change. However, it is not about settling on the app as work product but about skillfully playing on the keyboard of the possible end products.
Apps are a Team Sport...
When the media reports on the data scientist, singular is frequently used - possibly because data scientists still are so rare that the picture of the lonesome data hero automatically arises in people´s imagination. However, it is clear: the single data scientist normally does not produce apps. The app usually is a team effort because - compared to the analysis - an interactive and dynamic end product requires additional competencies in web technologies, software development and the design of user interfaces. Those additional requirements ensure that the wide range of skills a data scientist needs anyway is broadened to the extent that it finally becomes unrealistic. Thus, at least two colleagues with different focuses who collaboratively cooperate are required. In this process, the simplest model is a linear sequence (with loops) where along a chain of specifications, data acquisition, data preparation, modeling, visualization, deployment (see below for more on this keyword), it is not one person who does everything alone but different people are responsible for different parts of the chain.
...and Team Sport Forms a Team
For the development of a data science team, apps therefore have two very interesting effects. The one (more obvious) effect is a change of the team culture and cooperation. One depends on one another much more and that helps to accelerate the passing of the classical team processes of forming, storming, norming, performing. As data science teams are almost always relatively new and still developing, this is an important aspect.
The other effect is important for the rapid development of a powerful team. One of the main problems in searching for new employees in the data science area is the fact that a data scientist needs to bring along a wide range of skills. If I have a collaborative process anyway (at least in cases where the end product is an app), I can push the division of labor a little further than absolutely necessary (thus, three or four specialists for an app instead of two or three) which results in leaner requirements profiles for each of the participants. The chances to find someone suitable are thereby increased significantly. A web developer (thus, a significantly less rare profile) for example, may very well grow into a data science team if this team frequently produces apps. Generally, he will not become a data scientist in the process, but he substantially contributes to the team productivity.
Visibility through Apps...
A well-designed app, which supports regularly recurring, important decisions, has some kind of lighthouse function. It may sustainably promote the data science team and can be very helpful as tangible example for the benefit of the work in budget discussions. It has a reason that there is a trend towards apps in cases where attention is measured and brings money: In the data journalism of online media.
Click here for examples:
Public organizations which need to justify their work to the taxpayer and need to ensure transparency, have also recognized the value of interactive apps. The wonderful app by means of which the Federal Reserve Bank of New York makes the geographic distribution of the public expenditures on schools in New York transparent, should be mentioned as an example. Well-designed apps immediately appeal, it is fun working with them and they are a good choice especially for recurring decision situations in businesses or in the interaction with end customers.
...and by Analyses
Despite all benefits, the app as end product also has disadvantages for the data science team. There is the risk that the team disappears behind the product. That the surface is recognized but not the conceptual work behind it, that the deep expertise which is crucial to develop a good app keeps hidden. The technology is visible, not the competence behind it. And a classic part of data science gets stuck in its track (at least if anything has already become classic in our young discipline): the storytelling. An interactive app may "lead" the user, but ultimately it always is an individual expedition. However, a story is a linear process, which requires a linear medium - thus, the static analysis. I know that many will roar now, rightly pointing out that there are very smart attempts to also investigate and teach the "storytelling in interactive media", especially in the environment of video games. However, the fact remains that it is a very ambitious goal, which is even more difficult to realize than the linear data science storytelling - a goal feasible only in exceptional cases under day-to-day time constraints.
The classic analysis is a great chance for the visibility of the team if not only a PowerPoint file is sent in the end, but the data scientist presents it in a manner fit for the executive board. This is no task for "pure technicians", but for the rhetorically experienced data scientist with storytelling talent and analytical depth equipped with deep business knowledge. If he fulfills this task well, he may contribute to the visibility of the team which no app is able to replace: answering questions with deep knowledge. Showing his/her true colors. Personally make the competences of the team visible. An executive board member will never only rely on "the data" alone for important trend-setting decisions in complex situations. He/she will not want to miss the competence of those who know how to correctly analyze and interpret this data once he/she met them personally. A data science team should also strategically position itself in the business with regard to that.
Speed!
The choice of the end product also influences the speed with which it may be delivered. Usually, the analysis is created faster than the app (however, this depends on the processes and the tool support - but this is a topic for a separate blog post). Thus, it can work wonders in cases in which an answer is needed very quickly. At the same time, the app may relieve the team in cases where it is foreseeable that urgent requests return in a similar way. In addition, it is worth to interconnect the two end products in the development process. The analysis may serve as prototype for the app, and if you go through the last months` analyses, you might find an accumulation of similar tasks which can be provided as app.
Conclusion
For each data science team, it is worth developing the own "app ability" and learn to skillfully and flexibly use both the analysis and the app. Anyone who excludes one of the two end products gives away opportunities.
Callback Service