I’ve written about it before, but in late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my world-wide distributed, 2000 people organization to adopt Lean and Agile Software development methodologies in a large-scale, systematic and consistent manner. The transformation was a major project and I have blogged about it on the SAP Community Network before (see my blog posts Square OneGood Riddance and Different people). The transformation was a major effort over several years and is still ongoing today — Lean and Agile are a journey, a mindset, not a one time act of implementation. In the meantime, we have added additional methodologies, e.g. Design Thinking, into our set of tools and they actually fit very well with Lean and Agile.

When we started the whole transformation, we often got critical remarks from people in our own organization who were concerned that Lean was a methodology originating in production environments — Lean was invented by Toyota in the 1940s already — and was not a fit for Software Development. That’s when I started to think about how to convince people that Lean (and Agile) was more than something for the automotive industry. Even in retrospective and after having had hundreds of individual talks and discussions around Lean, I like my original storyline around Lean Software Development back then. And I thought it might be worth sharing… So here’s my “dog and pony show” presentation why Lean is relevant for any larger Software Development organization:

Lean Software Development -- We're not building cars -- luckily Lean Production goes back to Toyota.
Taiichi Ohno introduced it first in 1940.
It was originally targeted at manufactoring.
A lot of criticism we hear about Lean in Software Development seems to come from the wrong perception that we would believe we can apply this 1:1 to our business.
But we know we are not building cars – luckily!
Lean Software Development -- Software Development is a creative process We are in Software Development which is non-deterministic by its nature.
It’s much more like animation movie making or modern architecture – you need to get the craftsmanship right, but more important to success is the creative and innovative character of what you are doing.
It is a creative process, it’s an information creation process, learning is part of the journey and hence change is inherent to Software development.
So rather than ignoring change, one better sets himself up to cope with it right from the start.
Lean Software Development -- Eliminate Waste & Maximize Customer Value Nevertheless, what is common between car manufacturers like Toyota and us in Software Development is the strong desire to sustainably and profitably stay in business.
In essence, it means eliminating all the waste that keeps you from maximizing customer value.
Lean Software Development -- The core concepts of Lean Software Development Luckily, we can look outside and see that a lof of people and companies in the same business as we have thought about and made practical experience how Lean Software Development can work.
Just to name some examples: IBM has e.g. transformed their DB2 business, Salesforce.com has changed an 500 employee organization to an “agile development model” in recent years as well… And Microsoft has radically changed their way of developing e.g. their OS platform and development tools following lean concepts and agile principles.
Mary and Tom Poppendieck have condensed their findings into writing and the following slides will explain in a bit more detail what the 7 core principles of Lean Software Development are.
Lean Software Development -- Think Different The first thing to keep in mind is the fact that “Lean” is not a one-time activity, some procedure to implement and then you are done.
It is about mindset and about sometimes surprising or seemingly counterintuitive thinking.
It is for sure about continuous reflection on how you are approaching things.
The foundation of lean is about continuous improvement and respect for people.
Lean Software Development -- Think Less is More -- Eliminate Waste Principle #1 is to eliminate waste – and without going into details, all Lean Production “waste types” translate naturally into software development process “waste types” as well…
Lean Software Development -- Think Three Sixty Kickflip -- Amplify Learning The second core principle is about learning as much and as early as possible and about correcting what you are doing.
Like training to ride a skateboard in a half- or full-pipe: repeat often, learn quickly, adapt in the next cycle.
Obviously, this principle gets manifested in fixed takt cycles, shipping working software early and often, involving stakeholders and customers from the start in each takt evaluating and giving feedback about the software, doing Scrum reviews and retrospectives to thrive for perfection in execution, looking at software development from an end-to-end perspective, etc.
Lean Software Development -- Think Marriage -- Decide as late as possible Fooling yourself to believe you can predict the future or making decision based on premature information at hand, can be very costly to revert if you have to change plans afterwards.
So core principle #3 is about making decisions as late as possible – but not later!
One example is to tackle problems with a set-based approach, trying out more than a single solution in parallel, only later deciding on the best option. Or doing early prototyping and first getting customer/stakeholder feedback…
Lean Software Development -- Think Pizza -- Deliver as fast as possible Core Principle #4: Deliver as fast as possible – both internal and external.
It’s the-fastest-to-market who wins, not the biggest!
It helps to avoid “inventory” on the shelf, gives you feedback early and allows you to put the right things into the next (short) development cycle – maximizing customer value!
Lean Software Development -- Think Rugby -- Empower The Team Most challenging is “think different” probably for management – which is why we need “lean freaks” in management.
It is about the insight that you get the best results, if you empower the teams, the colleagues who know best how to get things done, how to approach a certain goal. It is about respect for people.
It is about getting rid of “process police”: you manage things, and you release people.
Lean Software Development -- Think Brain Surgery -- Build Quality In If you want to deliver fast and are dependent on fast feedback, if you want to maximize customer value, then quality cannot be an afterthought.
You have to build quality into the product and the process simultaneously.
And quality is more than defect-free software! It is about change-friendly code and architecture, about usability, about flexibility – it is about the integrity of the whole product.
Lean Software Development -- Think House of Cards -- See the Whole Finally, think from a customer perspective – think from the delivery side.
Don’t just optimize one area, but strive for making the whole a success.
Lean Software Development -- The 7 Principles To become “lean”, all of the 7 core principles have to be considered jointly, not “pick some, ignore the others”…
That’s why Lean and Agile make perfect sense in software development as well. Dear Automotive Industry — no offense meant! 😉

In late 2008, we started a major transformation of our SAP NetWeaver development approach, processes and organization: We made a bold move with my 2000 people organization spread out into development labs world-wide to adopt Lean and Agile Software development methodologies in a systematic and consistent manner. The transformation was a major change effort and I have blogged about it on our SAP Community Network before (see my blog posts Square One, Good Riddance and Different people). Looking at where we stand today as an organization, our ability to deliver customer value, to deliver reliably, to adapt in an agile manner, to interact with customers and to innovate our product portfolio in a high quality manner, I consider this multi-year transformation a big success!

With the move to systematic, standard Scrum methodology within the organization, cross-functional teams moved into the focus of our interest. “Cross-functional team” meaning people across the necessary disciplines working closely together as “one team”, namely software developers, software architects, information developers, UX designers, Scrum Masters and Product Owners to name the usual suspects. The great thing about these “cross-functional” teams is the ability to optimize the interaction between everybody that you need at the table to get the product done: efficiently and effectively. The more closely we can get this team to cooperate and interact, the better. They will share a better understanding of the overall goal of what they are trying to achieve, communication paths have been shortened as much as possible, diverse skills will increase the ability of the team to develop better ideas and approaches to the problem at hand, delivering more customer-centric results. All of this is also supported by the principles behind the Design Thinking methodology. And last but not least, once being “standardized” on Scrum approach, you can start training and developing complete teams in certain further skills, e.g. agile test practices, increasing likelihood to establish new software engineering practices in a sustainable manner.

ScrumWell functioning teams are a huge asset! While we sometimes like to see software developers as creative artists that can barely be forced into any constraint — at least that’s the romantic point of view that I myself tended to fall into when I was still developing software myself –, a fact is that almost all bigger software development projects are not done by a single individual but quickly by a number of people that somehow need to collaborate to get something relevant done. So the infamous “lonely guy behind a door” is something one does not necessarily see as the ideal working setup if you want to keep your customers happy and your business secured. Well functioning Scrum teams with predictable and transparent progress on the tasks at hand can be a big relief here.

Most of the time where I have seen teams to be dysfunctional or failing, have less been a general issue with working in cross-functional (Scrum) teams but rather could be attributed to the following:

1. Bad cut: The team did not work on a common problem, but was just a collection of people working on unrelated individual topics; sometimes “cutting” teams in a different way made this issue disappear

2. Bad chemistry: There were individuals in the team that did just not buy into the team as such; sometimes just assembling teams a bit different made this issue disappear

Very often I have been hearing discussions about the question whether teams have to be co-located, i.e. all team members being in the same physical location, or could — or even should — rather be distributed, e.g. across different locations or timezones.

I think either position — when taken rigorously — is somewhat shortsighted. Here’s why I think so:

We form cross-functional Scrum teams to make the group internal communication and interaction as efficient and “personal” as possible and get diverse skills to the table. Of course there are modern means of communication like phone, instant messaging/chat, Skype, telepresence etc. that have made the physical distance less of a problem. Still, if you imagine that a team sits in the same office physically and makes use of these communication means mentioned, you would ask yourself whether it wouldn’t be more efficient to just ask the question across the table or listen in on some side-discussion going on spontaneously on the whiteboard behind at the wall? Would be strange, wouldn’t it? So while it is not impossible to work together even when distributed, it is probably more efficient to be co-located. At least in most cases.

At the same time, there are good reasons to accept or even actively establish a “distributed” team: e.g. if your product manager needs to be local to your customers in a certain region or a certain market. Or if there is specific or outstanding talent that you did not find “locally” but had to look for abroad. And this was considered more valuable than the potential loss in optimal communication efficiency associated with it.

So I think the important thing here is: there may be very good and valid reasons to accept that a team is distributed, but those reasons should be well considered and consciously decided. Not arbitrary “accidents”. And they must for good reason outweigh the benefits of co-location.

Rules should cover the common sense 80% case. Exceptions always apply.

I believe it’s the best times ever for software developers.

Software developers never had more influence than today. Look at companies like Apple, Facebook, Google, Amazon, Microsoft, SAP and others, to name just a few, that have made it into the top ranks of fortune 500 companies within the past few years largely based on software assets directly or indirectly. Starting as startups and outgrowing many other industry players by sheer speed and total market capitalization. All based to a large extent on the work and intellect of software developers.

At the same time, it has never been easier and cheaper for a software developer to get her hands at an abundance of hardware power for a bargain price and software components for free:

  1. Cloud computing with hourly or resource based hardware subscription prices make upfront investments into expensive computer infrastructure unnecessary
  2. There are few problems where there wouldn’t be a number of Open Source software components available on the Internet free of charge to be thrown at the problem you’re trying to solve. The tools necessary, you get for free as well.
  3. You are not familiar with any technology used? No problem: There’s tons of information on the Internet, readily accessible if you have a rough idea what to “google” for. And if you are tired of reading, how about all the video tutorials on YouTube?
  4. You need to market your product? It has never been easier and cheaper to get your message out to millions of people via social media.
  5. Last but not least, the Apple Store or Google Play allow you to easily distribute your product to millions of potential users — and they even do the invoicing for you.

 

My early contact with management of organizations ;-)Back then when I started developing software myself, things were quite different. You had to invest in hardware upfront, software libraries and frameworks were rather the exception than the rule, the Internet did not exist and what you needed to learn you were teaching yourself out of books that you got in University libraries and bookstores if you were lucky.

I can still remember that during my first “professional” software project — I was freelance student programmer at SAP in 1988 — I was coding a graphical windowing system on my own as part of some graphical org chart rendering and manipulation product that connected to an R/2 Human Resource backend system initially and later to an R/3.

Atari-TOSThese graphical windowing systems were state-of-the-art on the computers I knew from home, a Commodore Amiga or the famous Atari 512, but if it came to Personal Computers in the office environment, the DOS console was still predominant. As Microsoft Windows was still not something to be assumed commonly available at customer sites, I had to come up with my own solution. So I coded a windowing library, mouse drivers, clipping algorithms, UI control libraries, printer driver code etc. What a stupid idea from today’s perspective, but back then? OK, perhaps it was even stupid back then… But nobody kept me from doing it 😉 The more concerning thing though is the following: How often do we make the same decision today? Re-invent rather then reuse? That’s why I believe Open Source is the way to go in many many cases.

6502 assembler (multiplication algorithm)“Back then” as a developer, you were basically working in a single programming language that only changed every few years. I started as a student in seventh grade with Basic on a Commodore VC20 that a friend of mine had invested into. Only to figure out quickly that the really cool and fast stuff needs to be done in 6502 assembler/machine code. I can still remember one family vacation as a highschool student when I was writing a hundred pages of assembler program “freestyle” with paper and pen at the beach in the shade to later on type it in when I was back home — LOL.

Later I switched to Pascal, Modula II, Java and C/C++ if it came to “serious” programming languages. It was only when I ported the ABAP kernel on all the SAP supported Operating System platforms from C to C++ compilation — I wanted to embed an XML parser I had written in C++ into it — that I blew up the kernel’s binary to a size of more than 100MB due to the C++ debug information required oll of a sudden. That was when someone wise pressed the emergency button and decided to promote me away from development into management to make sure I don’t create further trouble ;-).

Today, you have to handle a much bigger number of computer languages if you want to stay up to date with the trendy programming environments. The number of special purpose Domain Specific Languages is constantly growing, each of them often coming with their own specific environment and libraries, and JavaScript is on the best way to establish itself as the universal glue language not only between all the other domain specific languages and frameworks but also as a bridge between the gazing crater between client-side and server-side software development skills.

While in a way the fundamental principles and truths about software engineering and computer science have basically not changed over time, I believe that formerly as a software developer you were much more busy doing the nitty-gitty detail, from the ground up, fixing one screw after the other individually kind of development work and today as a software developer you are much more busy with “orchestrating” how you put powerful libraries, components and frameworks together. It’s like getting from building a car in a handcrafted manner to industrial mass production of cars from pre-fabricated components. The impact you can create as a single software developer, as a team or a software company, is by factors bigger than a few years ago.

What hasn’t changed though, is the enormous fun and satisfaction that comes out of the creative work that software development meant back then and still means today. “Look, mom! Look what I have created!!!”

Hey, how come I feel so old all of a sudden???? 😉

Life’s a marathon. You need courage to start, strength, endurance and will to pertain and a bit of luck to be successful. Not all of us have their share of luck though.

That’s why Susan Keohan, one of our esteemed SAP Mentors, has initiated the SAP Community Challenge Fund Raising Campaign during SAPPHIRE NOW 2013 benefitting Doctors Without Borders.

During the 3 days of SAPPHIRE NOW 2013 from May 14-16 in Orlando, Florida, all the participants who sign up for the challenge will contribute to the fund raising by logging footsteps made, kilometer covered running, coffees consumed or any other “challenge” they come up with.

Susan put it like that:

“It is well known that over the course of the conference, attendees will be logging some serious footsteps. Some may even organize into morning runs – before the heat of the day can beat on us. Practically everyone has a smartphone that can track your distance or some other device like a Fitbit that will also track it.

If you will be doing enough running or walking, and prefer to track something else, how about how many coffees you consume, or how many evaluation cards you fill out after a session?  Or how many SAP Mentors you can get photographed with?  
You decide – anything that is fun, OK?”

I personally will contribute to the challenge by running and counting the kilometers covered. My goal is to go for the marathon distance over the three days of the Sapphire Now event. Let’s see whether I go beyond ;-)…

At the end of Sapphire Now 2013 in Orlando we will do the math, sum up all the contributions made, e.g. kilometers run, and make a corresponding donation to Doctors Without Borders based on our individual commitment.

Want to join and support the campaign?

If you want to support the campaign with your own contribution, either as participant or as sponsor of one of us already signed up participants, please don’t hesitate to sign up at our SAP Community Challenge Fund Raising site on the SAP Community Network or drop me a note that I should enter you…

THANK YOU FOR YOUR SUPPORT!

images

Today’s the day. As if the gods had known it and are for once supportive to me, the sun’s shining when I wake up. It’s still only 2°C outside, but boy, the sun is shining. Finally. Today we will have our first rendezvous this year. Like every year on April 1st. The day starts with an appropriate breakfast — pankakes, maple sirup, icecream, orange juice, and a cappucchino, to get into a mix of Californian and Italian feeling. Ready for our day.

It was a Monday as well. April 1st, 1996. A very remarkable day for me actually. It was my first day as an employee of SAP Labs LLC. At the time still in Metro Tower in Foster City, before SAP Labs moved to Palo Alto where it is still today. I had just finished my Computer Science studies at university and had been working on connecting the SAP R/3 system to the Internet as my diploma thesis, when this whole thing turned out to be the start of a development project at SAP: the Internet Transaction Server. It makes for too long a story, but I ended up having the opportunity to come to California and work on the project at SAP Labs for 3 fantastic years. 

When I open the garage, she’s still there. I am relieved. Sometimes you wonder how you would react if the door opened and she was gone. Just a small pile of red rust left on the floor. Where she had been before. But she’s still there. As I have left her last October. Hidden under a red cover. It’s almost a celebration to uncover her. Carefully pulling the cloth off and revealing her step by step. Till finally, she’s back in old beauty. A bit older, but who isn’t? Still in perfect shape and her eyes blinking in the sun… She’s my 1969 Alfa Romeo Spider 1750. A real beauty, I think.

Alfa Romeo Spider 1750

I can still remember how exciting it was to arrive in California and start living and working there. Everything was a new experience and needed to be explored. I only knew San Francisco from the movies or stories I had heard and now being there, visiting the City in all its beauty, absorbing the buzz and the new impressions was for sure worth an experience. That’s when my love for the City got started. Love at first sight. She really left a mark with me.

Some careful wipes with a soft cloth to get the last signs of winter off — some dust here and there. We need some checks of fluids and the battery — still fine. So I carefully take a seat behind the steering wheel. Insert the car keys, send a prayer to heaven and turn the ignition. The engine gives it a try, but only for a split second. We try it a second time. Nothing. Hey, we’ll need some time together again, as it seems. Lot’s of talking. Begging. And finally, I’ll get her started… Not very smooth yet, but we’ll get there. As every year…

Alfa Romeo Spider 1750

We worked in a small team. Just four guys and a mission: Get the product ready in no time. I can remember how we worked like crazy: Thomas G did the development and benchmarking tools, Michael B did the R/3 specific protocol adaptations, I did the server core and the installer and Michael H took care of all the rest, including our travel itineries to Germany and back every few months. Some days we worked through all night, just to get the next milestone done or reach yet another looming deadline. It was the best team I ever worked in. The most influential project that I ever had the opportunity to be part of. Lot’s of hard work, but also lots and lots of fun! 

So finally, after some time getting warm with each other, we can take off… Leaving town behind us. Driving through the open fields. The cold wind blowing around my head, the wooden steering wheel feeling nice and soft in my hands, the sun above, the heating slowly getting warmer from below. It’s that very special feeling again. The one that makes her so unique. And she’s getting into it as well. Her engine gets warmer and runs smoother and smoother with every mile that we pass. She’s back to life. Finally. I think we’re getting into it again this year. It’s all memories and nostalgia about previous summers we’ve spent together. It will take some time, but we’ll get there again. We’ll have a great time together.

The three years passed like nothing. For some or the other reason the decision was taken to go back to Germany and not stay in California. It’s difficult to tell in retrospective what set the trigger. Many reasons coming together. But I guess you have to loose something first to really learn to appreciate what you had. Till today I wonder from time to time why I didn’t stay in California? How would my life have been since then? How would it be today? What opportunities did I miss? Was it right to go back to Germany? But then, in the end, I tell myself that it doesn’t matter. Decisions were taken differently at the time. Even though it was one of the best times in my life, it’s the past. And so things are as they are. What does it help to speculate about what could have been? It’s all memories by now. The only thing one can influence is the future.

Me and herSo Maybe this will be my year

We all experience it many times every single day. With italian cars that just won’t start in the morning. With Exchange Calendar appointments that simply disappear. With mobile apps that just won’t connect to the Internet when we need them. With auto-correct features in email clients that changed some words in your email in a career-bending or relationship-ending fashion without you noticing before you pressed the send button.

What I refer to is the bitchy randomness at which technology failures light up our days. Light up in flames. And like with all things people love from the “consumer space”, the expectations rise also towards the so-called “enterprise space” to follow accordingly. That’s commonly referred to as “consumerization of IT“.

Over the past months and years, we got painfully aware that even in ABAP the developer community has become comfortable with the status quo, complacent almost as to how easy and predictable it is to quickly code a new application to serve your employer’s or contractor’s needs. Far too easy, we believe. We all feel that it has to remain a certain science, wizardry, black magic to understand how a computer program actually works. And it has to feel arbitrary to some extent. Like bringing up your kids.

My team got notice of this burning issue already some months ago, but it took us a while to build up the necessary sense of urgency around it. And luckily, with Design Thinking, we got the tools at hand to really confront the problem heads-on. How could we bring the random malice of the consumer space experience to enterprise computing? What we came up with is simple but effective. As always.

After building and pushing around a fancy straw prototype of the solution in a Design Thinking session, we decided to introduce the COME FROM statement in ABAP. It contrasts with the GOTO statement, which for good reason has been considered as an approach too naive to effectively confuse programmers by acclaimed computer science legend Edsger W. Dijkstra already in 1968, as it does not impact the control flow of a program by telling where to jump to in execution, but rather tells where to come from whenever program execution happens to pass the given source code location. It started as a notion, but we quickly turned it into an ingenious idea and then into a brilliant concept. In particular if one looks at the additional attributes that one can add to the “come from” statement:

COME FROM [WITH PROBABILITY <expression> ].
where <expression> can be any valid ABAP expression yielding a floating point value between 0 and 1, or whatever else at which the execution is not determined at all.

As common sense implies, the COME FROM statement will be executed with the given probability, resulting in the programm execution continuing in the first statement following the COME FROM statement or continuing at the statement at the <source code location>.

Without thinking for too long, even the most junior developer will realize what enormous excitement such statements can bring to otherwise trivially boring code.

In a relentless effort to bring unnecessary reduncancy into the set of ABAP language features, we have also decided to introduce a new statement for execution blocks:

SKIP. <statements> END SKIP [WITH PROBABILITY <expression>].

The careful observer will have recognized our villainous brilliance to move the probability expression to the end of the SKIP execution block in order to further reduce code readability.

We plan to introduce these new ABAP language features with SAP NetWeaver 7.4 after some more intensive validation with customers.

With SAP NetWeaver 7.5 we will then provide a set of new capabilities in the ABAP development tools to improve the effectiveness of the new statements above.
First, we will introduce what we call “progressive obscurity” in the “ABAP for Eclipse” editor: with this feature you can — based on personalization of your Eclipse settings — determine whether the editor shows or hides the SKIP and COME FROM statements from display. This adds enormously to the fun during professional code review sessions. We are also testing whether randomly hiding normal statements outside of SKIP blocks could further help to confuse code reviewers.
Second, we will add support for the above statements in the ABAP Debugger and the ABAP profiler, which will be enhanced with predictive code execution capabilities built right into the tools themselves interfering with the underlying runtime Virtual Machines.

We are also working on bringing the above concepts into other programming languages: River Definition Language (RDL) is a natural candidate of choice. But also for Java we are pushing a proposal into the Java Community Process (RCP) to embed these capabilities into Java 8. For C/C++ we have started discussions with the ANSI committee. The ECMA committee has been approached by us to embed the concepts into ECMAScript/JavaScript and the major browser vendors have been invited already to a workshop in Walldorf. If we do something, we do it right.

Obviously, all of this is only a stop gap solution to bridge the time until the probabilistic behavior has been pushed further down the stack into the hardware itself. We have started to try to convince major CPU/MPU builders like Intel and AMD to add the above features to their hardware designs yielding utmost performance in randomness.

We understand that such a hardware driven approach will take some time to be ubiquitously available in all IT landscapes. We have therefore triggered efforts with Operating System makers to provide software solutions to the market that already today bring the benefits of random behaviour to end users. Solutions include TCP/IP drivers, DNS and DHCP servers, network domain login modules, Exchange server modules and file system drivers that will show arbitrary failure and outage behavior.

A renowned IT analyst company, that wants to remain unnamed for unspecified reason, has estimated the 2017 market for such solutions to exceed 37 billion US$ in total. While we consider the market significant, we have certain concerns though how much of this market we can actually tap into with a standard software solution, as corporate IT departments already today seem to have deployed partial solutions for random infrastructure behavior. At least that’s what we deducted from end user reports we’ve evaluated.

Patents are of course pending.

Hope is at the horizon. The days of waiting are numbered. With probability 0.5.

All will be fine

You meet them everywhere: At “hackathlon” events, at conferences, in developer forums, at StarBucks, even in the supermarket in front of the cereals and before you can even address them with “Son, why don’t you come over to our side of the platform?” they pull out their light saber, wave the shining and humming blade fiercly in front of your nose and shoot the probing question at you: “Father, what’s your API???”.

This is them. The next generation of programmers. The “scripting kids”. The developers that rule the mobile apps space. The ones that are quick and nimble if it comes to combining the latest in mobile app development — whether it’s native Android or iOS, whether it is HTML5, CSS and JavaScript doesn’t matter — with services provided by the Facebooks, the Twitters, the Amazons of the world, exposed as Application Programming Interfaces, or “API”s. They know that stuff like the inside of their pocket and if not they know how to figure it out quickly on the Web. They have their favorite server-side platform, whether it’s php, Ruby or node.js — it doesn’t matter. Some might even remember Java. They are fluent on these platforms and there is little interest in switching. What for? You glue your mobile app together using your favorite technology, which is defined by you being super productive in it plus it being somewhat at the forefront of being hip in the community — hey, that’s part of the fun.

So, “what’s your API??”

If we — SAP — want to attract a larger developer community to our technology, then clearly we need to address the needs of this generation of mobile application developers. It’s many of them. And they are active in a highly attractive and massively growing space: mobile apps.

And I believe there are 3 aspects of this that we need to tackle:

  1. We need to enable our own platform, i.e. SAP NetWeaver Cloud (aka HANA Cloud Platform), at the relevant level with APIs itself. A simple example is management of the platform itself (e.g. deploy, start, stop), but also services like monitoring, configuration etc. are obvious examples.
  2. We need to make it easy for applications and services built by our partners and customers on top of our NetWeaver Cloud platform, to API-enable their offering. Our customers own highly relevant business content and services and can expose these offerings easily via our NetWeaver Cloud platform to e.g. mobile consumption. This is where the highly valuable business content for a developer community enters the scene.
  3. We should provide the means to manage those APIs on top of our platform, make it easy to document, find, consume, monitor or meter those APIs. This should come as a service of the platform itself.

This morning, I had my monthly takt-end “Product Review meeting, a day-long meeting where my management team and myself take a look at the aggregated sprint results of our various products in development. We do Scrum in a very systematic way in my organization with around 2000 developers spread around the world. The Product Review takes a full day and constitutes the only “status update” about products and programs that I ask my organization to come up with. And that’s enough, by the way.
Today, we took a look at the current status of Gateway-As-A-Service, which is the SAP NetWeaver Cloud-based incarnation of our SAP NetWeaver Gateway product, a gateway that exposes business functionality implemented in our SAP Business Suite and accessible via Remote Function Calls (RFC), Business APIs (BAPIs), Dynpro screens (via “screen scraping”) and various other programming frameworks, in a standard-compliant manner based on REST and OData protocols (serialized as JSON if needed). So you can easily consume any of the business functionality in e.g. your mobile app in a simple, coherent and standard-compliant way. I am totally excited about the fact that soon our customers and partners will be able to expose any business functionality in the SAP Business Suite to the Internet and mobile applications without even installing an SAP NetWeaver Gateway in their corporate infrastructure, but can do so by simply connecting securely via our Cloud platform where we handle all the infrastructure provisioning. That’s a major step towards getting to those APIs we talked about above. Not the full story about APIs yet, but I am confident we’re getting closer every day…

I am very confident — I am convinced — that we are able to handle all the technical challenges at hand. The bigger challenges we will have to address are the following:

  1. Bridge — or smooth out — the inherent friction between expectations of extremely straightforward and simple access to business functionality on the consumption side, i.e. for example in the mobile apps space, compared to the variability and complexity of underlying business processes supported in the backend business processes. This will be harder the more “generic” the APIs exposed will be — the intrinsic problem of customizable standard software that can potentially do every variant of a certain process –, and it may be simpler the more specific the use case will be — e.g. if one of our platform customers exposes a specific service to the Internet, it can be completely “hardened out”, resulting in much easier APIs. So perhaps we should rather focus on making it easy to “harden” out specific versions of APIs than trying to expose everything “generically”.
  2. Solve the business model underlying the API consumption model: It’s great to expose APIs technically, but for sure there need viability and monetization considerations to be taken into account — not just for SAP as a platform provider, but in particular for our customers and partners willing to expose APIs for their services on top of the platform.     

So all of this comes with considerable challenges, but the opportunities opened up by such an approach of API level access to the platform and SAP customers’ business use cases are enormous.

“Success is where preparation and opportunity meet.” [Bobby Unser]

Any thoughts out there on this?