Algorithm Packages
What is an algortihm package?
It is a set of code that solves a specific problem with a framework of documentation, testing, user interface & output and design.
​
Why this framework?
​
To become data driven you will need analytics to decipher your data and make it into something you can take manageable business decisions upon.
​
Analytics is derived from data being extracted, cleaned, aggregated, transformed and outputted. This requires algorithms being run to do so.​
​
Ivin's take on how to achieve excellence through analytics is to create algorithm packages.
​
The R programming language community has a concept called packages. This describes how to document and test a package to make it production ready. The algorithm package is based upon this framework with some additional procedures to make it even more business oriented. The R community is a mixture of science and business.
​
Ivin's core belief is that by focusing on solving a problem statement with algorithms directly coded in a versatile open source coding language instead of a specific BI tool, the solution can be cleaner, faster and more resilient. By focusing on the algorithms that run the analytics, the problem can be solved in a way that is scalable, reproducible, can be automized and scheduled.
​
​
In order to standardize this idea, the Ivin algorithm package concept is used. It has 5 elements
​​
Documentation Testing Algorithms UI / Output Design
​
Thus acquiring an algorithm package will solve a specific problem in a professional way, that you can build on in the future or use it as is. Every component in the algorithm package will be open to your organization and this "white box" approach is important to Ivin. Your company is not bound to Ivin, as every aspect is documented and is in your possession.
Ivin encourages organizations to continue to solve problems with the algorithm package method on their own, to build a strong code infrastructure internally as Ivin seeks to promote codifying business tasks.
​
What algorithms does ivin do?
Ivin is established to do analytics. Algorithms are needed in order to create advanced analytics.
Algorithms are a sequence of well-defined, computer-implementable instructions created to solve a problem. Ivin works with algorithms that helps do three types of analytics.
The three types of analytics that Ivin specialises in are:
Descriptive
Predictive
Prescriptive
Documentation File
The documentation file is an integral part of the algorithm package. It is a file that contains all the functions that goes into the algorithm package.
It describes what each function does and how to use it. It ensures that everybody can understand the purpose of each function, how to use them and what inputs are needed for it to run.
Documentation Vignette
The documentation vignette is a book that describes the algorithms that creates the analytics in more detail.
The vignette has thoughts on design and examples of use cases that are printed directly in the book. This makes it a strong tool for onboarding or high level executive briefings.
.png)
Documentation file Example
Code Documentation
The most granular level of documentation is the code documentation. This is done to make code easier to read, share and verify.
​
Code documentation is the documentation embedded directly in the code. It is the comment-out text before a section of code or entire function.
Ivin builds with Google´s R style guide that is a variation of the Tidyverse Style Guide.
​
Each coder will have different preferences as to how much in-code documentation they prefer before a section of code. Ivin's default is to use some documentation before a segment but mostly have good, self-explanatory names of both functions and variables.
.png)
Documentation Vignette Example
unit tests
Unit tests are used to make sure a section of code is working as planned.
This means that all significant functions will be able to be tested. A test will make sure the function is behaving as expected.
A good unit test does not involve manual interaction and can be set up in a testing framework that runs multiple tests. A good unit test is also independent with regards to other unit tests, so if a sequence of tests is running, a single failure will not terminate the process.
Input tests
Input tests are created in order to make sure that an algorithm doesn’t break when getting a specific input.
These tests are also supposed to give the end user guidance into what is expected and in some cases why the given input type was wrong.
Input tests are also designed to give the back-end team a notification of why and when an algorithm was not run, while simultaneously giving the user a reason for it not being run.
integration tests
Integration tests are introduced in order to check that larger parts of the code is working.
In order to arrive at a state where you can solve a specific analytical need, you often need a multi-functional set of algorithms, and integration tests are designed to test the inter-connectivity.
codify your Problem Solving
Business and finance problems often require the ability to use a combination of educational gained skills, creativity and speed.
A lot of companies and organizations can acknowledge that the need for speed in solving an ad-hoc problem can sometimes outdo the quality of the solution. Quality is in this case a blend of data quality, reproducibility, “moving parts” and options for scale.
This is not troubling for small problems, but if an ad-hoc solution becomes a reoccurring solution that are to be run continuously, trouble starts.
It could be that your team starts out by doing an analysis in a spreadsheet and that analysis is popular. Suddenly it is a part of a larger reporting scheme and is combined with other spreadsheets and some of them have macros being run on data from your original spreadsheet.
In that case, a good solution has become an integral part of a larger reporting scheme. This situation has a lot of different red flags. Using a spreadsheet has limited security and traceback. It makes reproducibility really hard and you are never more than a single hard typed number away from a flawed analysis.
If you codify your team, it can help with a lot of these issues. It can use all the brilliant IT techniques used in science to ensure that your work is solid and that it can be used by others in the team and they can easily see the steps you have created.
By codifying your workflow all the way down to ad-hoc tasks, your company will always be able to scale an analysis that has proven to be great.
You can read more about the workflows in the segment “Using tech workflow in finance and business”
Automation and scheduling
All teams do occasionally have tasks that are repetitive. Some of these tasks have to be done at scheduled time frames.
​
If some of these tasks can be lifted from a manual workflow, into an automated workflow it can allow resources to do other tasks.
​
This is nothing new or ground breaking, but by having templates and forcing the team to setup repetitive tasks in an automated workflow, you help out the entire organization.
When you have tasks that are automated by having turned them into a code script, you can schedule the set of code to be run, when you want it to.
​
It is like any skill, the more you train setting up an automated task, the faster it gets.
using tech workflow in finance and business
Introducing a code based workflow to your team can seem daunting at first. It will require some changes to the core thought process in the team, but it does not have to be an all-at-once movement. It should be a progression.
The most important notion is the fact that a code based workflow is supposed to enhance the core capabilities of the team. It is not the goal to create computer scientists out of financial analysts, but give the finance team tools to utilize their own skills optimally.
Investigating what your team does, and will have to do in the future, will help determine if any coding languages are especially suited to start this transition.
The first step where a workflow from the tech scene will optimize the finance workflow is the segregation of tasks. Being able to separate the extract, transform and load process from the computational aspect of a task and the output/visualization, can significantly change the way you do business.
Creating frameworks, syntax and naming conventions that can align the way everyone starts out solving a problem, can make the company less vulnerable to individuals being unavailable at certain times and speeds up onboarding. This also allows for cross-functional team collaboration, as it is faster to look through a set of code that is written within a framework you know, than browsing through a specific persons notes, directories and spreadsheets and tracing cell dependencies.
​
An additional feature of the tech workflow is the agile project management tools that works perfectly in this setting. Getting a classic finance and business workflow into the realm of these settings can sometimes be a bit cumbersome and require some creativity.
Ivin uses the programming language R to create finance and business algorithms to solve analytical needs. This is not necessarily the perfect tool for all teams, but it works extremely well for most teams, especially if you plan on doing advanced analytics.
reproducibility
Reproducibility and transparency is an important part of the algorithm packages. Securing that the code is accessible for all in the company to check and if you update your analysis (code) you still have a version of the old code.
This is done to ensure that if you run the same algorithm on the same data, it will give you the same answer at all times. Being able to account for your analysis is something that is an integral part of becoming a data driven organization.
API Style code
You can use an IDE (integrated development environment) as your interface. Any analytics from Ivin will be available directly through code.
The algorithms and functions that create the analytics are available as API´s. If you use RStudio, there will even be mouseover explanation of what is expected as inputs.
.png)
Function API Example
PowerBI
PowerBI have recently opened up to running R scripts/functions inside their visualization tools.
This means that any Ivin Algorithm Package can deliver the data output directly inside this tool.
excel or Google sheets
If your organization prefers using Excel or Google Sheets as your visualization tool, this is not a problem.
Excel has a lot of visualization possibilities and Ivin can easily deliver the output of the algorithms inside a spreadsheet or as a csv file.
HTML UI (R Shiny)
One of the biggest advantages derived from using the coding language R as a base language for the algorithms are the option to visualize data in a HTML file which everyone with a browser can open.
This is done through an R package called Shiny.
​
This enables an R developer to deploy R algorithms into HTML code. This means that you can visualize your data in HTML files.
​
.png)
R Shiny HTML File Example
Sticker
Any algorithm package from Ivin will contain a sticker, which is the graphical representation of your package. This makes the package tangible and creates a buzz around the organization when they see a new sticker.
​
This is derived from the R community. It is a tradition in the R community that whenever you upload a package to CRAN (a global open source package repository) you have a sticker.
So even though it is not the plan to upload your package to CRAN, it is still a fun tradition to help create awareness internally.
​
If you want to create algorithm packages that can be used by the open source community, CRAN is a great repository where a team has to clear your package.
​
ownership
It is paramount that it is documented who created the package, what version it is, who updated which version and who is the package owner inside your company.
​
Transparency and ownership is the core of the white box problem solving concept.