Inspired: Stephen Wolfram

I just came across a super cool implementation, and now inspiration, for all the data and insights I am collecting on my personal site. (NB. I am not suggesting my life is even remotely unique or insightful and valuable to science versus Wolframs).

I do hope that one day I can look back and quantify the memories, experiences and insights I had the opportunity to enjoy.

The Life and Times of Stephen Wolfram: TimelineTimeline of significant events in Stephen Wolfram’s life, from birth through school, awards, publications, starting his company, major projects. The Personal Analytics of My Life—Stephen Wolfram WritingsUtilizing data analysis capabilities in Wolfram|Alpha Pro, Stephen Wolfram looks at his quantified self based on his large collection of lifelogging data.

Implementing LLMs in our internal mobile apps: Design, Demos, and Deployment

This is a summary/blog of my presentation which I recently gave internally at SAP during the One SAP Mobile Summit. The event brings some of the best and likeminded SAP mobility related groups and teams together during a week long, in-person, and virtual summit.

One-SAP-Mobile-Summit-LLMsDownload

This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 110,000 employees. I believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise. As an SAP champion, I enjoy sharing and promoting my experiences and knowledge with others through the SAP Community, if you enjoy this post, check out some of my past content. read more

Enterprise Mobility @ SAP – Conversational UI bot platform

This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years and believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.

This post is also a follow on to the post about SAP Relay, our internal realtime chat application, if you are interested reading that post might provide some context. read more

Enterprise Mobility @ SAP – Relay

This is another blog post of a series around the enterprise mobility IT team at SAP. We are an internal IT team focused on managing mobile devices, applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years and believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.

Introduction

As mentioned in previous posts, apps are an essential cornerstone of mobility @ SAP. Whether they are employee initiated or driven by innovation, we adopt the underlying processes and do our best to deliver solutions that increase our end users’ productivity. This post will take a deep dive into the ideation, architecture, design, and lifecycle of an internal app called Relay. A real-time chat application initially developed in 2012 using the Business Technology Platform (Previously known as the SAP Cloud Platform). A variation of the application might be familiar to some of you SAP community users, as Messages. We recently retired the application internally due to the increased adoption of MS Teams and Slack. However, I believe that some of the concepts and premise behind the application are still relevant to share. read more

Enterprise Mobility @ SAP – Mobile App Development

This is the second blog post of a series around the enterprise mobility IT team at SAP. We are an internal team focused on managing mobile devices, applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years. I believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.

Introduction

Apps have been a cornerstone for deploying mobile devices at SAP, and like any symbiotic relationship, the success of one depends on the success of the other. Our employees have realized the benefits of simplicity, speed, and availability in consumer applications and the power of their mobile devices. They have brought that same expectation to the enterprise and expect that these same traits be available in their work lives and daily processes. This is often how our mobile projects are initiated. In my eyes, the employees who demand innovation are the unicorns of the enterprise – they are passionate, willing, and eager to buck the norm and innovate on processes, which could be decades old, but rife for improvement. read more

Enterprise Mobility @ SAP – Introduction

This is the first blog post of a series around the enterprise mobility team at SAP. We are an internal IT team focused on managing mobile devices, mobile applications, and developing custom apps for SAP’s 100,000 employees. I have been a part of this team for the past six years and believe we have some unique stories, software, tools, and insights to help others in the community considering, or currently undertaking, some of the challenges which surround mobility and its adoption in the enterprise.

Introduction

SAP has been on the leading edge of adopting, deploying, and developing its Enterprise Mobility strategy for over ten years. It was one of the initial early adopters of Apple in the enterprise, with a field deployment of over 11,000 iPads in 2011. At the time, it was the second-largest deployment worldwide. Not only did SAP deploy and encourage the adoption of these innovative devices in our employee’s hands, but the team also had a early start on developing native iOS apps to support and empower our employees in their daily lives, enabling them to be more productive anywhere. read more

Who to write usefully

What should an essay be? Many people would say persuasive. That’s what a lot of us were taught essays should be. But I think we can aim for something more ambitious: that an essay should be useful. To start with, that means it should be correct. But it’s not enough merely to be correct. It’s easy to make a statement correct by making it vague.

http://paulgraham.com/useful.html

You Don’t Need Big Data – You Need the Right Data

I enjoyed this article from Max Wessel at SAP talking about how big data is not always the answer, but more specifically that you need the right data. There is a lot to unpack when you start apply and adding your business processes to this context.

The term “big data” is ubiquitous. With exabytes of information flowing across broadband pipes, companies compete to claim the biggest, most audacious data sets. And businesses of all varieties — old and new, industrial and digital, big and small — are getting into the game.

Masses of social, weather, and government data are being leveraged to predict supply chain outages. Enormous amounts of user data are being harnessed at scale to identify individuals among a sea of website clicks. And companies are even starting to leverage huge quantities of text exchanges to build algorithms capable of having conversations with customers. read more

Cards against SAP

Being an SAP Mentor I had the wonderful opportunity of meeting and interacting with many different SAP Executives and Leaders (One of my favorite was Hasso Plattner) … and in these meetings we would often chat about technology, platforms, innovation and the future of the company. In order to flip the script a bit and make things fun, I decided to put together a “Cards against SAP” type game, I never had the chance to use/introduce it, but here are a few questions I thought would be fun to ask:

  • The keynote this morning was completely ruined by _______.
  • The keynote this morning was awesome thanks to ________.
  • A SAP product would not be complete without ______.
  • In the context of SAP Products ….praise _____ , Marry ______, Kill _____.
  • If I could make _______ happy, my my life would be complete.
  • SAP as a company could do without ___________.
  • SAP as a company could really use ____________.
  • My boss is ___________.
  • I think SAP stands for:
  • read more

    DevOps/CI/CD for SAP HANA

    DevOps, and particularly Continuous integration (CI) and continuous delivery (CD), are terms which has been adopted widely and over the past few years in the software development industry. It’s use is currently creeping outside the scope of development and into various departments wanting to decrease long delivery cycles and increase product iteration. For those unfamiliar with the terms in the software space, or premise behind the idea: CI/CD is essentially the automation of the delivery of your software development projects into production and the broader goal is to bring Development and Operations closer together. In this blog we will mainly focus on CD as it pertains to HANA XS development.

    Inside SAP IT, and like a lot of other IT departments, we are trying to increase and simplify the deployment of our HANA XS projects and move to a more agile approach in delivering solutions for our internal customers.

    Firstly, some background: As many of the XS Developers out there know, the HANA repo is not necessarily the easiest “file system” to work with. The fact that data is stored in the DB, in a propriety format and each file needs to be activated, makes it tough to automate basic operations like moving or copying. In order to work around this topic, we decided that all of our code deployments were going to be done using HANA’s preferred native “packaged” file type known as delivery units (DU). These contain the entire active code base of a project (or subset of a project), changed as well as unchanged files.

    In the past we manually deployed code to each of our instances individually, this required manual intervention and developer/operations availability which we hoped we could streamline. The DU import process we decided to use is a feature which was introduced in SPS09 through a command line tool called HDBALM. This allows any PC which has the HANA client installed to import packages and delivery units to a HANA server. While there are options to commit and activate individual files from a traditional file system folder system (using the FILE API), we felt the benefits of a DU were better suited to our use case (for example, hdb* objects which may need to be created in specific order).

    Since we have the ability to deploy our code to our various servers using HDBALM, we needed something to get the job done! We used our internal instance of Atlassian Bamboo. We use this server for our HCP HTML5 and Java apps which make it a logical choice to keep our projects grouped to together. Our build agents are redhat distros and have the HANA client installed. We also copy over the SSL cert since our hana servers are using https and these are needed for hdbalm.

    In this case, and example, our landscape is relatively simple with a Dev, Test and Production dedicated HANA HCP instances.

    Screen Shot 2016-03-14 at 8.52.56 PM.png

    We store our “ready for deployment” delivery unit on our Internal Github instance, we do this so that the file is version controlled and also visible and accessible to our dev team. The premise is that the dev team would push a version of a delivery unit after their sprint, and its ready for deployment to Test. This could easily be a file system as well. However, we like to use the push/tag/release of our Github repo to trigger the build deployment.

    FYI: Bamboo is a great tool and a nearly zero cost barrier ($10). If you are considering a build server which has a quick and easy installation (*nix) and setup, I would highly recommend it.

    Since we have gone through some of the logical details, here are some technical details covering the topic:

    As mentioned previously, our build process is trigged by a new delivery unit being committed to our github repo. Our bamboo build agent picks the build up, saves it on the build server and deploys it to our Test instance. A email is sent to our dev and test team with the results. Before the import process, we check the version identifier on the existing delivery unit which was on the server, and we subsequently check it again after the import for comparisons and decide if the import was successful (along with the results of the import statement)

    (Keep in mind the below commands include $bamboo_variables) but would work just fine to replace them with actual values.

    You can find the code here in a github gist (where it will be maintained)

    export HDBALM_PASSWD="$bamboo_DestXSPassword" export https_proxy=http://proxy.wdf.sap.corp:8080 echo " " echo " " echo " " preversion="$(/home/i847772/sap/hdbclient/hdbalm -s -y -h $bamboo_DestHostname -p $bamboo_DestHostPort -u $bamboo_DestXSUsername -c $bamboo_DestSSLCert du get $bamboo_DeliveryUnitName $bamboo_DeliveryUnitVendor)" if [[ $preversion == "" ]]; then echo "Initial install of the DU"; preinstallversion="0.0.0" else preinstallversion=$(echo $preversion | grep -Po '(?<=version:)[^r]+' | xargs) fi echo "Pre Install version: $preinstallversion" IMPORT_LOG="$(/home/i847772/sap/hdbclient/hdbalm -s -y -j -h $bamboo_DestHostname -p $bamboo_DestHostPort -u $bamboo_DestXSUsername -c $bamboo_DestSSLCert import "$bamboo_DeliveryUnitFilename")" postversion="$(/home/i847772/sap/hdbclient/hdbalm -s -y -h $bamboo_DestHostname -p $bamboo_DestHostPort -u $bamboo_DestXSUsername -c $bamboo_DestSSLCert du get $bamboo_DeliveryUnitName $bamboo_DeliveryUnitVendor)" if [[ $postversion == "" ]]; then echo "Unable to query installed delivery unit version" postinstallversion="-1" else postinstallversion=$(echo $postversion | grep -Po '(?<=version:)[^r]+' | xargs) fi echo "Post Install version: $postinstallversion" export HDBALM_PASSWD="" LOG="${IMPORT_LOG##* }" if grep -q "Successfully imported delivery units" $LOG && [[ $postinstallversion == $preinstallversion ]]; then echo " " echo " " echo "******************************************************* Import of the DU completed, but the version has not changed *******************************************************" echo " " echo "Its possible you have not incremented the version numbers" echo " " echo "******************************************************* Log File $LOG *******************************************************" echo " " echo " " if [ $LOG != "" ]; then cat $LOG else echo "No log file, ensure the job is running on a machine with HDBALM" fi echo " " echo " " echo "******************************************************* //Log File *****************************************************" echo " " echo " " exit 0 elif [ $postinstallversion == "-1" ]; then echo " " echo " " echo "******************************************************* Import of the DU Has failed *******************************************************" echo " " echo "******************************************************* Log File *******************************************************" echo " " echo " " if [ $LOG != "" ]; then cat $LOG else echo "No log file, ensure the job is running on a machine with HDBALM" fi echo " " echo " " echo "******************************************************* //Log File *****************************************************" echo " " echo " " exit 1 else echo " " echo " " echo "******************************************************* Import of the DU has completed successfully *******************************************************" echo " " echo "Installation successful" echo " " echo " " exit 0 fi exit 0 read more