29.08.2019 / Ilpo Järvinen

Tämä kirjoitus keskittyy Databricksin käytettävyyteen erityisesti Microsoftin Azure-pilviympäristössä.

Moni Microsoft Azuren pilvipalveluja käyttänyt on saattanut törmätä Azure Databricksiin. Databricks onkin kovassa nosteessa. Yhtenä syynä tähän on juuri Databricksin integroituminen osaksi Azure-pilviympäristöä. Tässä kirjoituksessa selvennän, mikä rooli Databricksillä on AI- ja ETL-työkaluna. Lisäksi käyn läpi, mikä Databricks oikeastaan on ja mitä etuja sen integroituminen Azureen tuo tullessaan. Mainittakoon myös, että Databricksin Azure-laajennus on Microsoftin ”first-party service”, minkä vuoksi Databricksin käyttö Azure-ympäristössä on saumatonta ja vastaa yritysmaailman turvallisuusstandardeja.

Databricks pähkinänkuoressa

Databricks tuo käytännössä data science ja data engineering -työskentelyn samaan paikkaan. Kyseessä on siis toteutus, joka mahdollistaa AI-prosessien toteutuksen alusta loppuun. Datan voi ladata useista eri lähteistä, sille voi tehdä transformaatioita, rakentaa mallinnusputkia ja lopulta mallinnusputket voi julkaista tuotantoon useille eri alustoille. Näiden ominaisuuksien avulla Databricks kattaa kaikki AI/ML-toteutuksiin vaadittavat komponentit. Lisäksi se suoriutuu kaikesta tästä erittäin hyvin. Esimerkiksi, datan voi ladata suoraan Databricksiin, tehdä datatransformaatiot SQL-kielellä, opettaa ja tallentaa koneoppimismalleja Pythonilla, ja lopuksi ladata mallit tuotantoon Java tai Scala -formaatissa.

Databricksin ohjelmointiympäristönä toimivat web-pohjaiset Notebookit, jotka muistuttavat monelle datatieteilijälle tuttuja Jupyter Notebookeja. Databricks Notebookit kuitenkin sisältävät vielä lukuisia hyödyllisiä ominaisuuksia, jotka tekevät muun muassa versionhallinnasta sekä tulostaulujen ja diagrammien piirtämisestä erittäin helppoa. Samassa Notebookissa voi käyttää useaa eri ohjelmointikieltä ilman että käyttäjän tarvitsee tehdä minkäänlaista konfigurointia. Notebookit mahdollistavat myös useamman kehittäjän samanaikaisen työskentelyn.

Olennaista on myös, että Databricks on suunniteltu erityisesti big-datan kanssa työskentelyyn. Databricksin ydin on Apache Sparkissa, joka tiivistetysti on suuren datan prosessointiin tarkoitettu laskentamoottori, joka peittoaa muut nopeudellaan, käytettävyydellään ja sovelluskohteidensa laajuudella. Nopeudesta puhuminen veisi turhiin yksityiskohtaisuuksiin, mutta käytettävyyden puolesta vahvuus on Sparkin datataulujen selkeydessä ja siinä, että Spark tarjoaa rajapinnan useaan eri ohjelmointikieleen. Sovelluskohteista muutaman mainitakseni Spark soveltuu datan prosessoinnissa niin eräajoihin kuin striimaukseen eli virtaavan datan prosessointiin, tekoälytoteutuksien rakentamiseen ja SQL-operaatioihin.

Spark – Databricksin ydin

Spark on rinnakkaislaskennan mahdollistava laskentamoottori, jossa laskenta tapahtuu hajautetusti klusterissa. Tämä mahdollistaa laskentaoperaatiot sellaisissa tilanteissa, joissa yksittäisen koneen muisti ei kapasiteetiltaan riittäisi. Juuri tämä tekee Sparkista erinomaisen big-dataan liittyvässä laskennassa.

Käytännössä tämä tekee Sparkin datatauluista erilaisia kuin esimerkiksi Pythonin tai R:n perinteiset datataulut. Sparkin datataulut eivät lepää yhdessä paikassa, vaan ne ovat hajautettu klusterin ylitse. Ominaisuuksiltaan Sparkin datataulut muistuttavatkin pikemminkin tietokantojen tauluja tai Hadoopin hajautettuja tiedostoja.

Spark-tauluille on luotu rajapinta useaan eri kieleen: Pythoniin, Scalaan, R:ään ja SQL:ään. Näistä jonkin (tai useamman) kielen hallitseminen ei kuitenkaan tarkoita saumatonta liukumaa Sparkin käyttämiseen, vaan Sparkin käyttämän taulurakenteen ymmärtäminen ja tauluilla operoiminen vaatii omaa perehtymistä.

Mikään ei tietenkään estä suorittamasta Sparkin avulla operaatioita vaikkapa Pythonilla käyttäen Pandas-kirjaston datataulukoita, mikä voi joissain tilanteissa olla jopa järkevää. Tällöin data on kuitenkin tuomittu lepäämään vain yhdessä klusterin solmussa, jolloin klusterilaskennan hyödyt jäävät saamatta. Sparkin oma taulutyyppi onkin luotu juuri hajautettu laskenta silmällä pitäen. Perinteisiä (Python/R) datataulukoita ei ole suunniteltu tähän.

Spark on myös erittäin hyvä laskentaoperaatioiden optimoinnissa. Sparkin datataulukot tuovat käyttäjälleen sen mukavuuden, että pääasiallisesti laskennan optimointi tapahtuu automaattisesti ilman, että käyttäjän tarvitsee murehtia operaatioiden järjestyksestä tai laskentaresurssien jakamisesta. Toki pieni viilaus on käyttäjän puolesta välillä paikallaan.

Entä sitten Azure Databricks?

Databricks on Apache Sparkin tekijöiden luoma alusta, joka tekee Sparkin hyödyntämisestä helppoa datatieteilijöille ja -insinööreille. Databricks kokoaa kattavan määrän ominaisuuksia yhteen mahdollistaen tekoäly/koneoppimisratkaisujen tekemisen aina datan lataamisesta mallin tuotantovaiheeseen asti. Myös ETL-työt onnistuvat Databricksin avulla.

Sitten on Azure Databricks.

Azure Databricksiä voi ajatella Databricksin ”Azure-laajennuksena”, joka tarjoaa Databricksin integroituna Azure-ympäristöön. Integraation myötä Azure Databricks voi muun muassa hyödyntää Azuren data connectoreita sekä sen sisältämää dataa voi tarkastella Power BI:ssä.

Erityismaininnan arvoinen integraatio on Azure Databricksin soveltuvuus osana Azure Data Factoryn pipelineja eli ETL-putkia. Azure Databricksin notebookit voidaan saumattomasti yhdistää osaksi Azure Data Factoryn pipelinea. Tämä korostaa Azure Databricksin kykyä toimia ETL-työkaluna. Esimerkiksi datan voi pipelinessa koota useista lähteistä Blobiin, jonka jälkeen Azure Databricks tekee datalle halutut transformaatiot ja palauttaa takaisin Blobiin. Viimeisenä vaiheena voi olla esimerkiksi transformoidun datan siirtäminen Blobista SQL-tietovarastoon. Kaikki tämä tapahtuu näppärästi Azure Data Factoryn putkessa.

Ja mitä AI-toteutuksiin tulee, Azure Databricksissä luodut mallit voi rekisteröidä Azure Machine Learning servicen työtilaan, jonka kautta mallit voi julkaista verkkopalveluina. Azure Databricks on siis loistava komponentti osana Azure-pohjaisia ratkaisuja.


13.06.2019 / Mika Laukkanen

Otsikon kysymys tulee eteen useimmille Data Scientisteille jossakin vaiheessa. Useammankin kerran olen ollut tilanteessa, jossa tekoälystä tai koneoppimisesta innostunut asiakas haluaisi ottaa helpon startin asiaan, ja esittää ko. kysymyksen.

En varsinaisesti ihmettele, että tällaisia keskusteluja syntyy, koska aiheen markkinoinnissa on useammin pää pilvessä kuin jalat maassa. Ei siis moitita kysyjiä.

Mutta eipä noista keskusteluista ole haittaakaan ollut, sillä ne ovat avanneet hyvän tilaisuuden jutella aiheesta tarkemmin.

Data on hyvä renki

Miksi ei sitten kannata edetä data edellä tekoälyprojekteihin? Tässä kolme pointtia.

Ensimmäinen pointti on, että tekoälyratkaisujen ”äly” perustuu (nykyisellään) koneoppimismenetelmiin, jotka eivät ymmärrä asioiden välisiä konteksteja. Siinä mielessä ne eivät ole laskimia älykkäämpiä. Kun meillä runsaasti dataa, niin osa muuttujista voi korreloida keskenään, ilman todellista syy-seurausyhteyttä. Dataa sokeasti louhimalla on hyvä mahdollisuus löytää ”jotakin”, joka ei siis ole oikeasti mitään.

Tässä pari kuvaa aihepiiristä.

 

Toinen pointti on, että vaikka datasta löydettäisiin aitoja yhteyksiä asioiden välillä (ei pelkkää korrelaatiota), niin niillä ei välttämättä ole juurikaan liiketoiminta-arvoa. Esimerkiksi tehdään ennusteita asioista, joita ei kukaan tarvitse tai niitä ei voi käyttää. Kerran keksimme eräässä projektissa ennustaa puuttuvia CRM tietoja asiakkaan ostojen perusteella. Malli toimi hienosti, mutta asiakas ei tarvinnut päivitettyjä tietoja. Samoin kävi myös päivystyskäyntiennusteille ja eräälle tilauskannan realisoitumisennusteelle. Ei tarvetta.

Kolmas pointti on, että datan sokeaa tutkailua voi pitää huonona ajankäyttönä. Paljon dataa, paljon tutkimista. Tutkailun tuloksena sitä lopulta keksii jonkin kysymyksen, esim. ennustettavan kohteen. Tämä jälkeen valmistelee datat, tekee mallit ja tulkitsee tulokset. Jos tulokset olivat huonoja, niin sitten toisen kysymyksen kimppuun. Jos ne taas olivat hyviä, niin silti pointin 2 riski voi realisoitua. Tämä ehkä sopii kesätyöksi opiskelijalle, jolle työnantaja ei keksinyt parempaakaan tekemistä.

Mahdollinen poikkeus

Data edellä eteneminen voi ainakin yhdessä tilanteessa olla perusteltavissa. Nimittäin silloin, kun Data Scientist on sen alueen asiantuntija, jonka dataa hänen tulisi tutkailla.

Esimerkiksi osakemarkkinoihin perehtynyt Data Scientist ymmärtää heti ko. alueen datat ja termit (esim. volatiliteetti, pe-luku, beta tai sharpen luku). Ja millaisia asioita näistä dataseteistä on yleensä järkevää etsiä.

Vastaavasti markkinointiin erikoistunut Data Scientist pystynee porautumaan erilaisiin markkinoinnin datasetteihin, ja tekemään niistä tuloksellistakin louhintaa.

Mutta näissä tapauksissa on hyvä huomioida, että Data Scientistin asiantuntijuus ko. alueella on jo lähtökohtaisesti rajannut tutkittavia vaihtoehtoja eikä se ole vain sokeaa hapuilua.

Kokonaisuutena tällaista louhintaa voi pitää innovatiivisena prosessina, jossa pyritään löytämään uusia lähestymiskulmia ja ideoita. Ei niinkään tiettyyn tulokseen pääsemisenä joissakin budjetti- ja aikatauluraameissa.

Minkä asian haluat ratkaista?

Reaalimaailmassa nuo budjetti- ja aikatauluraamit on kuitenkin huomioitava. Uskoisin että seuraavan muistilistan avulla on helpompaa päästä hyödyllisiin lopputuloksiin kuin vain dataa tutkailemalla ja parasta toivoen.

  • Identifioi minkä ongelman haluat ratkaista tekoälyn avulla. Mitä selvempi ongelma, niin sen parempi. Esimerkiksi, myyntiennuste tuotteille x, y ja z kaksi kuukautta eteenpäin. Tai onko tuotantolinjalla kulkeva tuote kuvan perusteella a) virheellinen, b) virheetön.
  • Mieti jos tekoäly jo toimisi, niin mistä sen taloudellinen hyöty syntyy (ROI)? Vähentävätkö uudet myyntiennusteet esim. hävikkiä? Tai paljonko rahaa säästyy, kun virheellisten tuotteiden palautukset puolittuvat?
  • Ennen projektin aloittamista varmista myös, että teillä on dataa, joka vastaa identifioituun ongelmaan ja sitä on saatavilla alkukokeilujen jälkeen myös tuotantokäytössä.
  • Hanki oikeat ihmiset mukaan eri vaiheisiin (kehittäminen, tuotantokäyttö)

Sinällään tässä postauksessa ei varsinaisesti ollut uusia asioita. Jo 1990-luvulla IBM:n kehittämä CRISP-DM kehikko aloitti Business kysymyksestä. Ja se pitää edelleen pintansa.


11.07.2018 / Pekka Tiusanen

About Hit Rate Forecasting

Challenges in the sales process and management are common to many organizations. Improved data availability and machine learning algorithms provide means to forecast sales opportunity hit rates, which brings forth two interesting ML use cases. On the sales management level, keeping track of the sales funnel is essential and expected profit from the current sales pipeline is definitely of interest. On the contrary, individual salespersons have to be aware of critical price points in order to optimize profitability. Machine learning can answer such questions as “How much money do I currently have in the sales pipeline?” and “What price should I offer in this situation?”.

Data Acquisition & Manipulation

The forecasting results will be only as good as your model and data. Opportunity hit rate is in the least to some extent dependent on price, lead type and margin. Hence, CRM attributes are worthwhile to consider in any hit rate engine. However, relevant information may reside in various data sources, such as ERP, IoT and social media. In large organizations, it is often most convenient to import all the forecasting attributes from an existing data warehousing architecture. Having finished the compilation stage, one may have to spend some time on joining tables and transforming data to form a comprehensive set of relevant features with good data quality.

1. The Process of Adopting a Hit Rate Engine

After the data has been cleaned, some data manipulation might still be required. For example, depending on the method and analysis platform, categorical features may have to be separately converted to dummy variables. In the modelling stage, each categorical feature forms as many binary variables as there are factor levels.

One may also want to combine classes within some of the features to achieve less specific categorizations. For instance, all the lead types that relate to marketing could be combined, leaving the rest of the lead types untouched. This type of considerations are ad hoc and they may improve or deteriorate forecasting performance depending on the chosen methodology and data.

Moreover, there is often a logical order to some of the categorical model features. Such ordinal features are converted into numeric form by applying the associated logical order. For example, a variable with values “satisfactory”, “better than satisfactory”, “good”, “very good” and “excellent” would naturally convert to a scale from 1 to 5.

For some features, it is important to find the optimal level of detail, often referred to as granularity in data warehousing jargon. This applies to, for instance, geographical location and organizational data. A good rule of thumb is that all the classes of each feature should have enough examples to justify inclusion. If only a few sales were recorded at a freshly opened sales office, including this sales office as a class in the training data probably displays an excessive level of detail. This type of a situation would allow two options: (1) either substitute “sales office” with a less specific feature, such as “sales region”, or (2) replace the values of offices having too few recorded sales with NAs.

Finally, it is often sensible or even necessary to derive new variables from the set of ML features extracted, transformed and loaded (ETL). For example, if margin is not provided, it can be calculated based on cost and price. It is also common to use some type of ratios as variables. One should also verify that the chosen statistical model is not sensitive to the number of variables or correlations between them. Truncating the number of features at some point depending on the purpose of your analysis and the chosen machine learning algorithm should be considered. It is sometimes useful to reduce dimensionality of the data by applying principle component analysis, for example.

Proposed Methodology

The gradient boosting algorithm is based on steepest descent and loss function minimization. The method first fits training set mean or some other rudimentary model to the target series which, in this case, consists of “won” or “lost”. A decision tree is fitted to the resulting error terms of this crude approximation. Another tree is fitted to the residuals of the first tree and iterations are continued until the chosen number of trees has been reached. Gradient boosting thus produces a forest which consists of individual trees. It makes sense to use regression tree based gradient boosting instead if your dependent variable is continuous. The process of fitting a gradient boosting model minimizes mean squared error analogous to loss function in mathematical terms.

The resulting statistical model is just an ensemble of trees generated based on your training data. The training series can be formed by taking a 70-80 % random sample of the total observations. Passing an individual opportunity to the forest-like model yields a hit rate forecast. One opportunity is just a row with the corresponding model feature values. The feature values of this particular opportunity determine the forecasting outcome of each tree. All the trees shift the resulting forecast up or down.

The forecasting model is tested against the validation set which typically comprises 20-30 % of total observations. Prediction accuracy can be determined by benchmarking the model with a confusion matrix. The matrix indicates how many lost (0) opportunities were correctly identified lost and, on the contrary, the number won (1) opportunities correctly forecasted.

Receiver operating characteristic (ROC) analysis is another way to benchmark classification models. The ROC curve displays the true positive rate (TPR) on the y-axis, whereas the false positive rate (FPR) is reflected on the x-axis. The true positive rate is the share of won opportunities correctly identified as such in the validation set. Furthermore, the false positive rate is for the proportion of lost opportunities incorrectly predicted won.

Estimated raw probabilities are used for classification scoring. The ROC curve illustrates how the TPR and FPR values behave as the classification threshold is changed. The intuition is that model performance improves in terms of detecting won opportunities along with a decline in the accuracy of catching lost opportunities as a consequence of shifting the threshold.

Possible overfitting of the model can be assessed by reviewing the ROC curves of training and validation sets. Any statistical model is overfitting if there is considerably more area under the curve in the training set compared to validation. Overfitting means that a statistical model is too specific so that it overestimates the associated predictive power. Complex statistical models are prone to overfitting. Hence, one should avoid using an excessive number of trees and tree depth as gradient boosting is employed.

2. Forecast Benchmarking

From Flashcards to Truly Data-Driven Sales Funnel

Now that the hit rate engine is up and running, it is time to feed it some opportunity data! The model predicts the probability of acceptance for each individual opportunity fed to the algorithm, which allows better approximation of the sales funnel. The expected aggregate revenue can be estimated by multiplying predicted hit rates by the corresponding opportunity prices and summing up the results. Assuming that margin for each opportunity is known or derivable, it is possible to produce profitability estimates as well. The forecasting results can be integrated to the current BI reporting solution, which enables enhanced sales management and coordination.

3. Intelligent Sales Funnel

The gradient boosting method also allows extraction of the most relevant features predicting hit rate, which provides sales management with interesting insights. Hit rate drivers can be considered valuable from the product portfolio viewpoint too. However, some of these attributes are bound to be rather obvious — if price and margin are not listed among the most important hit rate features, your model may be misspecified.

Gradient boosting is a non-linear modeling procedure, so a direct two-way interpretation for factor contribution does not exist. Usually a combined feature importance metric is used because model attributes have three importance dimensions to them. Firstly, the “gain” metric is a volume-oriented forecast contribution statistic. On the contrary, “frequency” conveys how often features occur as tree splits within the model. Finally, the “cover” metric is for the relative number of opportunities associated with each particular feature. In case you are not satisfied with the combined metric nor individual components, it is also possible to visualize individual trees to truly understand the model dynamics.

Scenario-Based Profitability Modelling

The hit rate engine enables “what-if” analysis for individual opportunities, which allows the model to be deployed as a sales assistant. This ML implementation provides salespeople with a statistically justifiable estimate on how hit rate and profitability evolve as opportunity price is increased or decreased. More attributes for a salesperson to tinker with can be included as well.

4. Hit Rate Engine as a Sales Assistant

To fulfil the requirements set by the sales assistant use case, a range of prices has to be fed to the algorithm. The resulting impulse response is a range of hit rates. If the margin is included in the model, it has to be dynamically adjusted as price changes by using a suitable dependency function.

Hit Rate = Model(Price, Margin, Features1-N) + Ɛ

Now that we get the curve of hit rates out by dynamically changing price and margin, it is time to add profitability into the equation. This is fairly straightforward as we already have hit rate and margin calculated for each price level. The formula of expected profit includes probability of winning, corresponding price and margin at this price. This is obviously something that corporations want to maximize.

Expected Profit = Hit Rate * Opportunity Price * Margin

Forecasting accuracy increases along with the number of entered model input features assuming that the underlying statistical model has been produced according to best practices. The behaviour of hit rate and profitability with respect to price can be visualized and embedded as a sales assistant feature in a CRM or CPQ system. Of course, this requires proper usability design to ensure that the complexity of the underlying model is hidden from the salesperson. The model does not have to be trained constantly, so response time is not an issue.

 

 


24.05.2018 / Mathias Hjelt

With SAPPHIRE 2018 just around the corner, let’s have a look at a key topic from last year’s event. Leonardo got a lot of attention in 2017, but still many are confused about what it is. Before the next wave of hype rolls in, let’s make sure we all understand what the previous one was about.

Put short: Leonardo is SAP’s brand for digital transformation. Specifically, it’s a brand used for solutions which have certain qualities. Those qualities are found in solutions which relate to IoT, machine learning, blockchain, big data. Hype bingo, if you will.

If you are still confused, here’s a list of some Leonardo-branded services and tangible technologies being marketed.

  • Leonardo Innovation Services = Design Thinking and prototyping services offered by SAP.
  • Leonardo Centers = physical places where e.g. Innovation Services can be delivered.
  • Leonardo Foundation = PaaS services on SAP Cloud Platform for IoT, ML, Blockchain, Big Data, Advanced Analytics
  • Leonardo Applications = applications built by SAP which typically are based on SCP, related to the qualities mentioned above, and possibly but not necessarily built using Leonardo Foundation services. Examples: SAP Cash Application, Connected Goods, Predictive Maintenance & Service, Brand Impact, Service Ticketing, Fraud Management, Customer Retention, Analytics Cloud.
  • Leonardo IoT Bridge = kind of a “Digital Boardroom” type of solution, gathering data from ERP, LoB apps and Leonardo Applications, giving a real-time view of connected things and business processes.
  • Leonardo Accelerators = a commercial packaging: Leonardo Innovation Services + Leonardo Application licenses bundled together, e.g. with an industry specific focus.

So there you have it – quite a wide spectrum of things and concepts. You just need to remember the common denominator: “stuff which has something to do with making your business better by applying IoT, ML, blockchain or big data”.


17.04.2018 / Pekka Tiusanen

The field of marketing has experienced various changes over the past decade. Digital marketing, social media presence and sponsored content are becoming increasingly important, but traditional channels retain their attractiveness to many organizations. Machine learning and better data availability will turn the game around for agile organizations with the courage to implement advanced analytics solutions.

Return on Marketing Investment

One of the most crucial aspects of marketing is effectivity. Therefore, associated financial outcomes should be evaluated and analyzed when marketing spending is decided. It is feasible to calculate return on marketing investment (ROMI) for each channel and marketing campaign.

Marketing resource allocation can be considered in the light of return evaluation. ROMI modelling also allows earnings forecasting in which marketing spending is used as an input. Simulations increase demand predictability and thus improve decision-making. The greatest financial benefits are typically realized in large B2C organizations.

Data Requirements

ROMI modelling requires revenue and margin data. Furthermore, organizations have to document marketing spending by channel, product and time stamp to utilize the approach. The quality of the results is largely dependent on data completeness, length and frequency. The picture below illustrates the sales of a product sensitive to national holidays with relatively sizable seasonal fluctuation.

Earnings Modelling

Earnings generation has to be modeled in order to obtain an estimate of ROMI for each marketing channel. The determinants of earnings vary according to product characteristics and operational environments. The resulting time series model can be deconstructed into smaller parts to obtain a quantitative estimate of each element with an effect on revenues.

It is often feasible to include a trend component when earnings modelling is carried out. The baseline of the model is built on observation history and endogenous behavior of the dependent sales series. Identification of relevant external factors is also essential to modelling success. Structural anomalies can be filtered out with a suitable statistical method often based on residual standard deviation.

Earnings generated by each marketing channel are displayed along with the rest of the model components. ROMI can be calculated based on these cash flows. The statistical model which inspired this blog post explained 94 % of the underlying variation in sales.

 


19.05.2017 / Mikko Koljonen

Cheating comes in many forms

Who wouldn’t have heard of all the bank related phishing frauds and of the Nigerian letters? Now there is a new scam on the rise and surprisingly this time it is all legal. SAP is currently ongoing the biggest technology transformation in its history and this will have a huge impact on reporting and analytics. Anyone considering the roadmap beyond SAP BW should beware in order not to be cheated.

Moving beyond from old SAP BW provides huge opportunities but also a major risk.

Scam vs. ignorance

Sometimes ignorance can cause the same end result as if you were getting cheated. Also – sometimes ignorance can directly result you being cheated.

We have discovered a clear pattern where unsuspecting targets are being sold fancy visions, but the truth what comes to implemented solutions is something completely different. We have seen victims who have been robbed huge amounts of money to get nowhere.

Your alarm should ring if you think any of the following applies to your organization:

• Any hick-ups when taking into use new generation best-of-breed end user tools – can be caused by e.g. data modelling, which has been done in an outdated manner and does not properly support you to use modern tools

• End users do not feel the value of the change – can be caused by e.g. dashboards and reports being merely copies of the ones used in the old system

In the end it is nothing less than your business that is at stake.

When doing things right you can reap all the business benefits. You can lower total cost of ownership with modern sophisticated solutions or improve your revenue and results with totally new kind of insight into data.

Being cheated or ignorant, you can lose big time. In the end it is nothing less than your business that is at stake.

Read more about the same topic:

Lauri Puolanne: Data warehouse – a burning platform?
Antti Lyytikäinen: Life after SAP Business Warehouse
Mikko Mattila: Third party tools with SAP BW/4HANA – From a problem child to a social, well-behaved citizen

Download the material:

10+1 things to consider when moving on from your old SAP Business Warehouse
10 tips for your road to self-service analytics


20.04.2017 / Mathias Hjelt

Long gone are the days when companies were likely to buy the entire stack of enterprise tools from their ERP software vendor, Mika Tanner pointed out in his recent blog post.

There has clearly been a switch from ERP-driven to best-of-breed software shopping and development. Adding to the equation, software buying power has switched towards business departments, and methodologies have shifted towards rapid and agile. The compound effect is that quick proof-of-concepts based on a broad range of technologies may spawn like mushroom in rain. Great success or architectural madness arises.

Many companies are still struggling with getting it right. In this post, I will highlight 5 topics to consider and pitfalls to avoid.

1. Be precise about division of responsibility and ownership of data

When a process gets sprinkled across multiple systems, each with different degrees of data sophistication, it can be difficult to choose which system should be responsible for executing certain tasks or leading a certain part of a process. Likewise, it can be difficult to decide which system should be the master of each data entity, and to which extent data should be replicated back and forth between systems.

Failure to address these topics with determination and clarity will cause problems in the short term (not getting the most out of your best-of-breed stack) or long term (e.g. data quality deteriorating instead of improving over time). Even if you don’t see the problems immediately, things may get out of control when you try to develop the next solution top of the jungle. (Putting an API on top of the jungle will not make the problem go away – see below)

My advice:

Be precise about the division of responsibility between systems. Be equally precise about ownership of data. Sounds simple, but many enterprises have serious challenges with this!

2. A simple API does not dissolve complexity

The startup world thrives on lean cloud apps interconnected over APIs. API talk also thrives among enterprise architects and salesmen. Best-of-breed buying is fueled by the assumption that anything and everything is easy to connect and extend, if there is an API.

Don’t overestimate the magic of APIs. APIs are terrific, but by no means a silver bullet to easily manageable architecture and walk-in-the-park projects. Publishing a complex process through a simple API does not make the complexity go away. It momentarily hides it from the people developing on top of the API. But in the bigger picture, there is still a full, hairy, complex stack of systems to govern and respect when you make changes to your processes.

My advice:

Build enterprise APIs, build enterprise software on top of APIs, but don’t forget that you are developing and maintaining full-stack solutions, which require full-stack governance and understanding. Choose partners and vendors who are up to the job.

3. The platform is the new monolith

Relying on the ERP as the center of everything is out of fashion, because it’s too monolithic. The same goes for building enterprise software too tightly bound to the ERP. There is plenty of buzz about how companies should build a digital platform as a foundation for rapid innovation. Buying software, add-ons or custom development that runs on the platform keeps your architecture coherent while helping you stay away from the evil ERP monolith.

But the risk is that your platform – be it a bare-bones cloud PaaS or a rich enterprise ecosystem in the cloud or low-code environment or a thin API layer – becomes the new monolith. If the platform sinks, down goes everything built on top of it. Many companies are currently facing massive re-implementation exercises as their “once best-of-breed but now sadly outdated” platforms are eroding, pushing massive chunks of enterprise software into sunset land all at once. Are the hot platforms of today less prone to future erosion? I don’t think so.

My advice:

Build on a platform when it makes sense, but always ask yourself: what happens the day when we want to or have to get rid of the platform? Can we re-deploy or do we need to re-write / re-purchase? Build independent, loosely coupled systems or services when your platform-monolith gut feeling warning bells go off.

4.Know your license terms

Software vendors want to make money. They want a huge share of your wallet. No surprise there. What may come to a surprise to some, is that e.g. an ERP system may come with licensing terms which are quite restrictive in terms of integrating with 3rd party systems. Recent news about a company having to shell out considerable amounts of money due to “indirect use” has brought more attention to this topic. Rightly so.

My advice:

Ask very precise and frank questions about licensing. Both from your 3rd party best-of-breed vendor, and from your ERP vendor.

5. Be bold enough to pull the plug

Lastly — quick Proof-of-Concepts are the stuff that agile business driven IT development is made of. Being able to try out new stuff without tedious planning helps you innovate faster.

But beware: PoCs which are set up in an ungoverned results-over-planning fashion, and never make it to a controlled transition to production at scale, also tend to become the stuff of enterprise architecture nightmares. Unless they are terminated at some point.

My advice:

Be bold enough to pull the plug on systems when appropriate. Get rid of solutions that never were designed for long-term, company-wide, future-proof usage. Alternatively, ensure that there is a solid path forward for the PoCs that you want to keep.


12.04.2017 / Karri Linnoinen

Every year Hortonworks, together with Yahoo, put on the DataWorks / Hadoop Summit. It’s a 2-3 day conference dedicated to Big Data and its technologies. This year it was my time to visit the summit, so I’ve compiled a quick summary.

#DWS17

DWS17 kicked off with an epic (to say the least) laser show.

IMG_3161

From the welcome keynote on Day 1, emphasis was on the Data itself. It’s not about Hadoop or the platform anymore, instead on how to create value from the data in your organisation or the data you have collected. That data is also the reason why the summit has been renamed from the “Hadoop Summit” to the “Dataworks Summit”. With the ability to process and use data in an entirely different way from times of old, new businesses will emerge from data.

“In today’s world, data is actually our product.”

Scott Gnau, the Chief Technical Officer at Hortonworks talked about how the Future of Enterprise is centered around four paradigms: Cloud computing, Artifical Intelligence, Internet of Things and Streaming Data. Many of these are already in use in organisations, Cloud computing especially. Artificial Intelligence, which in itself is a broader area, is getting a lot of traction as Machine Learning is becoming more accessible due to services like Microsoft Azure Machine Learning Studio.

As for the other keynotes on both mornings, the sponsor keynotes were a little hit-and-miss.

Delightfully, the last morning keynote on Day 1, by Dr. Barry Devlin, shook things up by outlining the fall of Capitalism, and how A.I will inevitably replace the factory worker. This is of course, if we continue on our present course. It was a very interesting take on the future of Big Data and life beyond it, considering the speed at which current and new technologies are developing. As technological progress increases at an exponential rate, a crash is almost inevitable. A some what morbid start to the summit you could say, but thankfully the presentation had a silver lining at the end — we are now at the turning point, where we can influence how the future turns out, and influence the steepness of the downward curve. Hopefully we are able to level it out and avoid Dr Devlin’s Skynet-esque future 🙂

Also on Day 2, the last keynote by Dr Rand Hindi, was a quick look into privacy issues in Cloud computing. With the introduction of personal voice-assistants like Amazon Alexa and Google Home, technology companies should be paying more and more thought to where consumers’ data is processed. Voice patterns are after all, just as unique as fingerprints.

Breakout Sessions

This year, as the focus was on data itself, you could see that many of the Breakout sessions were showcases of implementation by different companies. BMW, Société Générale, Lloyds Bank, and Klarna all showed how they’d leveraged Hadoop in their Big Data journey. Data Science was also in a big role at DWS17, as many of the customer showcases and Breakout Sessions had a Data Science theme.

Live Long And Process

Looking at the agenda for the two days at DWS17, you could see one thing jump out — Hive. Specifically Hive with LLAP. This was evident in the number of Hive (and LLAP) -specific Breakout Sessions. Apache Hive has been with the HDP stack for forever, and has been a staple part of many of our POC architectures at Bilot. Back in 2016, the launch of the Hive 2.0 LLAP Tech Preview made a lot of people happy, as the query speeds of Hive 1.x lacked the required punch, as well as missing full ACID support. Now with the newest version of the platform, LLAP is a reality (GA), and all the many sessions at DWS17 indicated it’s a big deal. Query times are reduced by an order of magnitude, which is definitely something to be excited about.

IMG_3096

LLAP also adds value to other newer technologies coming into the HDP stack. Druid, a new time-series optimised data store, can leverage LLAP’s parallel processing capabilities to speed up query times. I’m especially excited to test out Druid, as it will come bundled with HDP 2.6 and thus be deployable via Ambari blueprints. It’s currently in beta, but will hopefully mature quickly.

HDF

The Hortonworks Dataflow, powered by Apache NiFi, looked to be Hortonworks’ next big thing. Teradata for example has open sourced its new “data lake management software platform”, Kylo, which leverages NiFi for pipeline orchestration. Hortonworks’ DataFlow still requires a fair amount of infrastructure to run, but as its little brother miniFy (JVM-based version of NiFi) matures, I think the whole edge-node processing paradigm will take off in a completely different way. Especially when you can run NiFi on very resource-scarce systems.

But we’ll have to stay tuned.

HDP 2.6 and beyond

Funnily enough, the launch of the new major release of HDP and Ambari wasn’t hyped at DWS17 as much as I would have expected. Granted, there was a fair amount of buzz around its new features, but the focus definitely was elsewhere. That being said, it didn’t mean that the announcement wasn’t important. Many of the new, cool features are only available with HDP 2.6 and Ambari 2.5, so users will need to upgrade their existing systems to leverage LLAP and Druid, for example. I for one will definitely be doing some upgrading 🙂

Beyond the newest version of HDP, is Hadoop 3.0. It could be releasing as early as Q4/2017, and will bring improvements to resource management as well as container support (yay!). This will make Hadoop in itself more resource-aware, and mean better performance. The usage of Docker has exploded since its initial release four years ago, and some of the newer Hortonworks apps, such as Cloudbreak, already take advantage of the technology. So with the addition of container support to Hadoop, YARN could potentially control non-Hadoop services and applications deployed into containers.

In Summary

The Dataworks Summit is definitely something you need in your life, if Big Data is on your roadmap or you’re already knee-deep in it. I’m glad I went, since getting to talk to the developers and community members directly is invaluable.

Stay tuned for some blog posts on specific technologies related to what was showcased and discussed at DWS17. There are several key part of the new HDP release that can be discussed in greater length.

If you’re interesting in hearing about Bilot’s Big Data offering and how Hortonworks Data Platform can help your organisation, get in touch and let’s talk!


9.12.2016 / Mika Laukkanen

5.9.2018

Pian on kaksi vuotta kulunut tämän artikkelin kirjoittamisesta. Vaikka tuolloin oli jo kaikki merkit ilmassa, niin eipä olisi arvannut millaisiin mittasuhteisiin tekoälyasiat nousevat. Ennustaminen on vaikeaa. Kahden vuoden aikana on tapahtunut paljon edistystä, mutta edelleen ollaan pitkän tien alussa. Selvää vain on, että kelkasta poisjäänti ei ole vaihtoehto.


Tekoälystä on kirjoitettu viime aikoina todella paljon. Oikeastaan ei mene päivääkään ilman uutta tekoälyuutista. Kuulemma Slushissakin sijoittajien mielenkiinto kohdistui erityisesti tälle osa-alueelle. Erilaisia hypejä tulee ja menee, mutta tällä kertaa uskon, että kyse on enemmästä.  Asiasta joka muuttaa maailmaa vielä radikaalisti. Vaikka kehitystyö on kestänyt vuosikymmeniä, niin mielestäni ollaan edelleen alkutekijöissä – samassa tilanteessa kuin autoteollisuus oli 1900-luvun alkupuolella, kun ensimmäiset autot saapuivat kuluttajien iloksi.

Kannattaa myös huomata, että kehitys ei mene lineaarisesti. Tähän pisteeseen pääsy ehkä vei 60 vuotta, mutta lähivuosina kehitystä voi tapahtua enemmän kuin edellisenä 60 vuotena yhteensä.

Tässä blogissa tekoäly terminä kattaa erilaiset algoritmipohjaiset Machine Learningiin perustuvat ja automatisoidut ratkaisut. Niiden pohjaltahan nykyiset tekoälyt toimivat. Käytän myös termiä AI välillä tekoälyn sijasta, joten koettakaa pysyä mukana.

Miksi juuri nyt?

Ei ole sattumaa, että AI-ratkaisujen ja niiden uutisoinnin määrä on kasvanut reipasta tahtia. Ala on mennyt viime vuosina eteenpäin vauhdilla, jonka on mahdollistanut mm. seuraavat tekijät.

Big Data (pilvi) – oppiakseen algoritmit tarvitsevat dataa, jota on enemmän saatavilla kuin koskaan aiemmin. Aikanaan alan tutkijat joutuivat itse simuloimaan keinotekoista dataa, koska oikeaa ei ollut saatavilla. Olikohan niin, että vuonna 1980 gigan tallentaminen maksoin noin miljoonan? Ja vaikka dataa olisi ollut generoinut tai muuten saanut tuon gigan, niin mikään tietokone ei todennäköisesti olisi jaksanut pyörittää sitä riittävän tehokkaasti.

Laskentakapasiteetin kasvu (pilvi). Käytännössä AI-ratkaisujen ytimessä ovat erilaiset neuroverkot, joiden opettaminen vaatii merkittävää laskentakapasiteettia. Ei tarvita kummoistakaan ongelmaa ja big dataa, kun neuroverkon pyörittäminen tulee tehokkaallakin läppärillä mahdottomaksi.

Algoritmien ja niiden soveltamisen kehittyminen. Erityisesti Deep Learningiin perustuvat ratkaisut ovat tuoneet isoja harppauksia tekoälyn kehityksessä. Esimerkiksi seuraavissa kohteissa.

  • Kokeilepa Google haun puheentunnistusta, jonka AI-algoritmi vaihdettiin viime vuonna. Sen tarkkuus on aika uskomaton. Tuttuni sanoi, että se saa selvää 4 vuotiaankin puheesta. Eli rattiin ei ole asiaa, jos Google ei ymmärrä puhettasi.
  • Kuvien tunnistus on ottanut isoja harppauksia ja pari viikkoa sitten oli uutinen, että tekoäly lukee paremmin huulilta kuin ihminen. Kannattaa peittää se web-kamera, koska tekoäly lukee myös kasvojen ilmeitä. Tiedä vaikka tulevaisuudessa läppäri toimisi henkilökohtaisena psykologina. ”PC: Mikäs se nyt Mikaa harmittaa näin aamusta?” ”M: Ei mikään..” – ”PC: Nyt et taida nyt puhua ihan totta..”.
  • Kielenkääntäminen. Youtubesta löytyy videoita, joissa tekoäly kääntää lennosta esim. englanninkielistä seminaaria kiinaksi. Viivettä ehkä sekunnin verran. Tekeekö tämä vieraiden kielien opiskelusta jatkossa vain ahkerien huvia? Odotan tästä ratkaisua pakkoruotsin osalta.
  • Vielä parisen vuotta sitten AI-asiantuntijoiden käsitys oli, että GO-shakissa tekoäly voi voittaa parhaan ihmisen noin 10 vuoden kuluessa (normishakissa tämä tapahtui 1996). Kävi kuitenkin niin, että AlphaGo teki temput ja voitti parhaan ihmispelaajan alkuvuodesta 2016. Taustalla oleva tiimi oli tehnyt uskomatonta työtä yhdistellessään innovatiivisesti eri AI-metodeja taustalla.
  • Uutisten mukaan IBM-Watson päätyy 99%:sesti samoihin diagnooseihin kuin syöpälääkärit, mutta on löytänyt 30%:ia enemmän hoitovaihtoehtoja. Eikä niitä syötä kukaan Watsonille manuaalisesti. Se lukee kaiken alalla kirjoitetun materiaalin (julkaisut, tutkimustulokset, jne), jonka kehittäjät päättävät sille antavat. Sieltä se sitten poimii asiat ja pysyy ajan tasalla. Tri Housella on vakava kilpailija.

Kehitys on siis nopeaa ja AI-ratkaisut tulevat yhä useammalle alueelle. Usein emme kuitenkaan huomaa niitä, koska ne ovat ‘verhottuna’ ohjelmistojen ja palveluiden sisään. Ne ovat siis lähes näkymättömiä käyttäjille.

AI-ratkaisujen liiketoimintamallit?

Erityisesti meitä datan ja algoritmien kanssa puuhailevia kiinnostaa, että millaisia liiketoimintamalleja tekoäly tuo mukanaan. Tuleeko jostakin kaiken kattava yleinen tekoäly, joka osaa ratkaista lähes kaikki haasteet vai onko meillä miljoonia pieniä tekoälyjä, jotka hallitsevat jonkin kapean osa-alueen?

Itse uskon, että vastaus molempiin on kyllä, mutta aikaperspektiivit ovat erilaiset.

Ainakin seuraavat 10 vuotta tullaan kehittämään suppeita (narrow) tekoälyjä, jotka ratkovat jonkin spesifin osa-alueen haasteita (esim. optimoivat reittejä, ennustavat vikaantumista, kohdentavat mainontaa).

Yleisen tekoälyn (ratkoo mitä vaan haasteita) kehittämiseen tarvitaan resursseja, joita todennäköisesti löytyy lähinnä jättiyrityksiltä, kuten Googlelta, Microsoftilta, IBM:ltä tai Applelta. Ehkäpä nämä jätit poimivat parhaat palat noista suppeista tekoälyistä ja liittävät ne omiin kehitysprojekteihinsa. Aikataulu yleisen tekoälyn kehittymisen osalta voi olla pitkä, esim. kymmeniä vuosia. Sitä ei varmaan kukaan pysty arvioimaan tarkasti.

Liiketoimintamallien osalta on ainakin kolme päävaihtoehtoa (ml. asiakas ja AI-ratkaisun toimittaja).

  • Yritys hankkii oman tiimin tälle osa-alueelle ja sitoutuu pitkäaikaiseen kehitykseen. Tämä sopii hyvin isoille yrityksille, joiden liiketoiminnan kannalta datan hyödyntäminen on kriittistä. Tällaisia yrityksiä ovat esimerkiksi teleoperaattorit, rahoituslaitokset ja vakuutusyhtiöt. Tässä mallissa AI-ratkaisujen ulkoisella toimittajalla voi olla lähinnä konsultatiivinen rooli tai softan myynti.
  • AI-ratkaisujen räätälöity ostaminen toimittajalta. Tämä on ehkä tyypillisin skenaario. Asiakkaalla on ongelma X, johon toimittaja tarjoaa ratkaisua. Yleensä tämä tehdään projektina ja asiakkaan omistamaan ympäristöön. AI-ratkaisujen toimittajalle tämä tarkoittaa räätälöityjä projekteja.
  • AI-ratkaisun hankinta palveluna (pilvestä). Suomessa tällä osa-alueella on vielä varsin vähän tarjontaa, mutta maailmalta löytyy hyviä esimerkkejä. Itse näkisin niin, että (Microsoftia lainaten) tämä todella demokratisoi tekoälyn, eli tuo sen kaikkien ulottuville. AI-ratkaisujen toimittajan täytyy tässä vaihtoehdossa tuotteistaa palvelut pitkälle, koska projekteja ei voi täysin räätälöidä. Myös ansaintamalli poikkeaa räätälöidyistä projekteista.

Jokaisella vaihtoehdolla on omat plussat ja miinukset, mutta yksi asia on kuitenkin varmaa – aloittamatta ja tekemättä ei mikään valmistu, eli kannattaa selvittää AI:n potentiaaliset hyödyt.

Eräs pointti AI:n hyödyntämisestä

Usein yritykset lähtevät etsimään (AI) business caseja, joissa isot kertatuotot olisivat mahdollisia (~ miljoona lisämyyntiä). Joskus sellaisiakin löytyy, mutta ei aina. Tämä taas saattaa lannistaa ja luovutetaan jo ennen lähtölaukausta.

Edellä mainittu lähestymistapa ei kuitenkaan ole ainoa. Vaihtoehtoisesti voidaan etsiä pieniä ja maltillisia (AI) business caseja ratkaistavaksi, jotka kuitenkin tehostavat toimintaa. Esimerkiksi siirtäen manuaalisia työvaiheita AI-ratkaisun tehtäväksi.

Jälkimmäisessä lähestymistavassa on tärkeää huomata, että business hyöty ei välttämättä tule siitä, että tekoäly tekisi työn ihmistä tarkemmin tai paremmin. Se kuitenkin voi tehdä työn murto-osassa siitä ajasta mikä kuluu ihmiseltä. Kaksi esimerkkiä.

  • Talouspäällikkö laskee tuotealuekohtaisia budjetteja ensi vuodelle ottaen raportointijärjestelmästä viime vuoden lukuja pohjalle.  Työ kestänee tunteja. Kevyt AI-ratkaisu laskee tarkemmat ennusteet budjetin pohjaksi sekunneissa.
  • Hakemuksen käsittelijältä kuluu tunti tehtävässä, josta AI-ratkaisu suoriutuu silmänräpäyksessä. Tai sitten AI voisi ohjata hakemukset suoraan oikeille käsittelijöille, vaikeat kokeneille ja helpot aloittelijoille.

Kannattaa siis miettiä, että AI-ratkaisulla oikeasti tavoittelee ja millä aikajänteellä. Nopeita pikavoittoja on mukava saada, mutta pitkäjänteinen pienien etujen kumulatiivinen kerääminen voi kuitenkin olla se paras vaihtoehto.