Now that you’ve met me, let me start by laying out my assumptions about who you are as my fellow traveller. If you’re still reading at this point, I have to assume you are interested in partnering with SAP. There are a lot of other enterprise providers you can go with (IBM, Google, SalesForce) so why are you picking SAP? The main reason needs to be that you want to be able to sell your solution into SAP’s customer base. SAP has established a long hard fought relationship with some of the biggest customers in the world and established itself as most trusted brands in enterprise software space. That’s big and it means SAP can get you into a lot of doors that otherwise you’d have to spend a lot of time and effort just to find the right people to talk to. That opportunity comes at a cost. Luckily for you most of the cost will be in your time and effort to get your solution in a form that SAP can easily sell. We’ll get into the details of that as we go, but for now you should look at SAP’s partner program and decide how and when you’d like to join up. You don’t have to put any money on the line now as there are free ways to explore much of what SAP makes available to you in order to kick-start your development.
You can get started with joining the program free of charge by applying for the SAP PartnerEdge Open Ecosystem – Build option. You’ll need a legitimate business entity to do this. If you’re an employee or a student or a consultant you’ll probably not get past this point as you really do need a business entity and supporting website to move forward. You can still follow along our journey, but you won’t be able to do all of the things I’ll cover. Once your solution development is well underway you’ll want to consider upgrading to the regular SAP PartnerEdge – Build option as it allows you to list your application on the SAP App Center and initiate go-to-market activities with SAP’s sales teams. My colleague Ivo has put together a blog series that maps out the logistical steps you’ll be taking while I’ll concentrate on both a conceptual and actionable view.
I’m also going to assume you come to this series of blog posts as a developer or at least the technical side of your effort. You might be a startup or part of an R&D devision of a large company. It doesn’t really matter. Most people who come from a technical background have an idea of what it takes to develop and idea into a software solution that looks something like this.
Most of the effort will be in the building part of things and then when we feel it’s all good to go, we hand it off to some sales team and move onto the next project. Mission accomplished, right? Not really. You’re in the middle of your next project and now you’re getting all sorts of bug-fix requests and the sales guys all claim that they can close some huge important deal if we just add one more little feature that somebody they’re courting is asking for. Let’s be a little more realistic about what it really takes to put out a successful software offering. Firstly, get over the notion that it’s all about the development. When the the development is done, you’re really only then getting going and you’re probably only about half done anyway. Look at the left side of this diagram(blue).
These are the typical development tasks. I’ve added some things that are more machine learning oriented but we’ll get to that later. The important thing to realize here is that there are a lot of sales and marketing tasks that are needed when you’re looking to sell into the enterprise ecosystem and they take a lot of time and effort as well(green side). The next thing you should realize is that this is not a linear process where you take one shot at the development effort and you’re done. Don’t get me started on the waterfall model of software development where everything is specified completely at the beginning of the project. I was suspicious of that methodology 30 years ago and it NEVER works. The biggest reason it doesn’t work is that it doesn’t allow for discovery! You will learn new things about what you’re building as you go and you need to be prepared mentally and financially to continue around the cycle a few times at least before the sales momentum starts. In an extreme case you may even pivot to a whole new solution domain in the middle of your project. Be open for this possibility and start gathering feedback as soon as possible, even before your idea is fully formed! Let’s focus on two parts of the above diagram, the idea and feedback.
What you’re doing is really just market research or dry testing your idea. You’ve been talking about your idea to friends and family haven’t you? What did you do with those responses? Did you alter your idea? Did people ask where they could find out more or how they could stay in touch with your efforts? Did they say “I know the exact person in that industry you should be talking to.”? You need a place to direct people to in order to and capture their ideas about your idea. This is where SAP and Qualtrics can come into the picture. If you sign up for a free account at Qualtrics, you can create one survey to start capturing feedback. This is what I’ve done with my website for ConcileTime so far.
I’ve build this skeleton site on my team’s Cloud Platform Cloud Foundry account. You can get a free trial account on your own as well. Understand that while you can explore many things about SAP’s Cloud Platform in this way, you can’t do everything or do it forever. You’ll have to get a real account at some point, but I’ll leave it to you to decide when that makes sense to you.
The main thing to note about the website is that it has a Qualtrics survey imbedded in an iframe on the page and that it uses a custom domain name. When you build on cloud platform, by default your applications will have a name of the form.
Most of the time it’s even worse than this as the system will by default concatenate your application and space names together in order to create a unique hostname. I’ve told it to use conciletime, but it still uses it’s own landscape us10.hana.ondemand.com and cfapps and it starts getting long and unruly. While you can add a custom domain later in the development process, I recommend starting out day 1 with it. You’ll need to start establishing your brand for your idea and there tend to be a lot of interdependencies in your code, your docs, your marketing materials, so why worry about refactoring all of that later when you can start on the right foot now?
I registered the domain conciletime.com with GoDaddy a prominent domain registrar in the US and I went through all the steps to purchase a valid wildcard domain certificate from an outfit called Comondo(cheaper than GoDaddy and seemed legit). I’ll have “excursions” from this main path from time to time that I put in separate blog posts that stand alone and I can link to from my main journey here. I’ve captured the domain and certificate processes, but have put those posts together yet. The important thing now is to start using the brand you’ll be developing now so that you can build upon it instead of having to go back an refactor it all later.
In the next post I’ll start getting into the code of the project so far. I’ve tagged the GitHub repo to align with each post to make it easier to see the state of the code at the time when the corresponding blog post was created. The main branch will continue to be the latest work-in-progress so it’s not guaranteed to build correctly at any give moment. I’ll try to make sure the tagged commits at least build properly so that we can have stable reference points. Although you wouldn’t know it from looking at the website, there is a lot in the code already. Mostly this is because I wanted to get the custom domain stuff working, and working with authentication, and working with multitenant concepts, and working with continuous integration, and using Cloud Application Programming methodologies. All of which I’ll get into in later posts. Feel free to start looking at the project if you’re interested(links below).
-Andrew (Your Naïve Sherpa)