Why Dick Hirsch is mostly wrong about ByDesign guerilla tactics
In his The specified item was not found. Dick Hirsch picks up the Redmonk beat about having developers at the heart of go to market. To be 100% clear on this, Redmonk is a strong advocate of having developers front and centre of pretty much everything and especially product marketing. I have some sympathy with that view but not always. I am also aware that Redmonk has a special place in the hearts of SAP developers. Be that as it may.
On ByDesign, Dick says:
Suggestion 1: Don’t create a separate developer community for partners
On occasion, I’ve heard some indication that there should be some separate community for ByD developers. This would be a mistake. Exploit the passion and experience of the existing SCN community.
It is easy to see why Dick would hold that view but it is a fatal mistake.
- I speak with a lot of SAP customers and user groups. The number one gripe about SCN is that it is way too focused on the Business Suite. Almost everything else gets drowned out.
- If you look at the BPX community, that’s been a hell’s on earth job to get into reasonable shape.
- There is a dearth of conversation that BusinessOne customers can tap into. All-in-One fairs little better.
- Business ByDesign is unlike anything SAP has put into the marketplace. It needs to be treated as such.
- When you look at the construction of the SAP Mentor community it is 90% drawn from folk whose primary interest is in the Business Suite. That is changing as new people with interests in River, BOBJ and mobile come into the picture but it doesn’t change the fact that SCN is cemented to the Suite audience.
- If the BYD audience is largely going to be business focused then, for example, how does SCN think that those same users are going to live with the crappy UI associated with blog post creation here (for example.) They won’t.
Why would anyone with an interest in ByDesign come to SCN? It is nothing like the Business Suite. It is not a sale to a technology buyer but to mid-sized companies that have a need for an integrated suite they can easily implement – no coding required.
Heck – there isn’t even a points development area for it yet!!
SAP is working – albeit with what seems glacial speed – to bring the VAR community up to speed. It has shown the SDK to developers. Those who ‘get’ ABAP and C# will have little problem dealing with what is in effect a scripting language. So where is the place for a ByDesign community inside SCN?
I agree that having a vibrant developer network for BYD is critical but it will be many a year before those same developers will need to be sharing code. Instead I predict we’ll see developers rapidly develop add-on modules for the white spaces SAP is not going to cover. They will likely share those in the context of a marketplace but that’s about it. And from what I’ve seen, there just are not going to be that many issues with the SDK to warrant a large community.
I could be wrong of course but let’s put it this way: when I can follow a script, code it and have something ‘new’ running in BYD then ANYONE can do it.
I also believe BYD developers need their own identity. At the moment, those who know the Business Suite are making the instant comparisons and asking questions like: ‘Why can’t I just write ABAP?’ Clearly SAP has a messaging issue here but in short – this is different, you’re not going to be getting anywhere near the source code. You will be playing with business objects and forms. A totally different way of working and thinking. And it is this difference in thinking that to my mind is the hallmark of why a BYD community should not come anywhere near SCN. Anything else risks the ‘old world’ anti-bodies from stifling innovation on this solution.
Rainer Zinow does a fantastic job of working through the technical ins and outs of BYD. Rainer will likely admit that he needs to improve on changing his tone from one that sounds like SAPense to one that reflects business language. If you agree with that then it is easy to see how BYD will be an odd fit inside SCN.
Dick’s second suggestion makes a HUGE amount of sense:
Suggestion 2: Find a BusinessByDesign SAPMentor
This suggestion may be premature. I know that the ByD SDK hasn’t been released yet.
Still, I’d like to suggest that there be a SAPMentor who is a BusinessByDesign expert. The synergy would be amazing and the inclusion with this group would help promote this new development environment.
Note to Dick: the SDK has been released but version 2.6 is the one that everyone is waiting for – due later this month.
I am currently in the process of developing a paper which SAP will have rights to distribution. In that paper I, along with my co-author Brian Sommer, talk about it as a business solution first and foremost. It is not a toolbag of bits and bytes although good implementations will need the knowledge of process experts.
I can therefore see some cross over from the BPX community into one for BYD but that’s about it.
Rather than try live with the old I’d be MUCH happier seeing SAP carve out a separate identity for BYD devs. That’s what makes market sense, whatever you believe the role of developers should be for this solution.
Can't refute anything you have said here Dennis but I can refer you to Jeanne Carboni's announcement about a better blogging environment at the very least.
Migrating SCN Blog Functionality in 2011
So that weakness will be addressed going forward.
But as one of the movers and shakers of new community development, I'd love to hear more about creating a separate and vital BYD community. Top down? Bottom up? Where? What would it look like?
1. Users 2. VARs 3. Devs
I want to see how the VAR community is going to shake out first. Some of SAP's BYD go to market people have been talking to me about that but there is still some work to do. I think that once that is out of the way then we'll know more. But remember that this is a community over which SAP doesn't have much immediate control There are LinkedIn groups in and around this topic and they may well stay in that location unless SAP can offer them a much better experience.
Plus VARs + Devs may end up being the same group. It is very early days so I would not want to be hard and fast at this time.
I thin also SAP might have to realise it has no ownership over BYD communities. They may well form on their own, That's a distinct possibility.
I would suggest everyone fellow SDNer to check #Salesforce Developer Network. I'm not writing this to compare & elicit contrasts b/n 2 Developer Nwks (Not against @Salesforce either), but I can't stop wondering what can stopping from going beyond, as I believe SDN has a better 'cloud' of 2Mn developers & more? Please have a read on this post & see where SCN lies in customer-partner-developer centric race: http://bit.ly/grUUgN
I'm not sure how great ByDesign for Partners would evolve "without" the collaboration of an in-situ SAP team to take care of any issues/resource allocs. I'm pretty sure without a good communication mechanism, a product can 'sustain'. There was indeed a mixed speculation for ByD Configurator (Pricing! Profits?) & Partner Development Infrastructure (AppStore? Cost? #What's in it for me?), but there were no forums to discuss. SAP TechED Bangalore 2010 saw a lot of doubts, anxious questions esp. in ByDesign as a partner's model. There are doubts still I believe, and I'm sure each product would have its niche for its own, but BIoD/ByD/River seem to be bit different. I was astonished when BI On-Demand (Web based!) didn't have such a promo like ByD (Would regard this a great work!)
Like Salesforce market thier custom code engine #APEX DNwk, ByD developers must exercise some control & regulations, follow some best practices etc. Understanding a customer centric requirement is the 2nd >> BPX community (Accepted! "that's been a hell's on earth job to get into reasonable shape.") Its' more customary in SDN/BPX esp in BOC sometimes developers & customers needed to move towards products/services!
Just to explain why is, when BOBJ was introduced, there were not many takers, But soon as "Business Objects" was marketed as a seperate suite, with a better insights on its benefits, There were a lot of takers. (Geeee... Here comes the Auoroa! EIM & BO4.0....)
Just want to finish with a small story. Happened to meet a fellow collegue, who wanted to implement ERP for his 200+ org. I did hear him say "Why can't I find a 'ByD Forum' in SDN". -1
I'm not stating we need something similar to CodeExchange & go forward on that etc... But it would be great for a product to follow the developer's way!
Sure, I guess as Vijay Vijayasankar blogs, BI lost its clout. (Good blog Vj http://bit.ly/fpwvGO) 2010 saw BW/BI stopped being the big thing every one want & saw a paradigm shift to Business Objects while quitely being re-baptized as "EIM". (SDN forums got changed as products started changing! ) There were multiple ideas, no clear overviews, roadmaps [except for certain Partners, not denying that fact, but... ] As a customer, it ultimately sums to what product should I buy?. Sure every guy will have a question, Is the money I'm gonna spend on it worth the salt? +1
Does Salesforce have a better mousetrap? I can't answer that and I doubt I'd want to do so anyway.
But I wonder if Arun is missing the central point. It's not that there should not be a place for BYD devs. I'm definitely NOT saying that. I am saying that SCN is not the right place largely because it is so heavily focused on the Business Suite.
Demand may come more quickly than any of us imagine with Bill McDermott re-committing to 1.000 customers by end 2011.
nice discussion toppic.
"How does SCN think that those same users are going to live with the crappy UI associated with blog post creation here (for example.) They won't."
This is a real prob of SCN not only for ByD users, but solved in the near future (hope so).
"Those who 'get' ABAP and C# will have little problem dealing with what is in effect a scripting language. So where is the place for a ByDesign community inside SCN?"
Those who get 'ABAP' are already on SCN. Why they have to switch to another community. Same happend to the JAVA guys. We are all SAP developer, not ABAPer, JAVAer or ByDer -> one plattform for all dev and business related toppics.
"I also believe BYD developers need their own identity"
Why? What if they are also ABAPer or SAP JAVA-devs? Schizophrenia?
Uwe
In other words - you don't need to have the same skills. And that IS confusing some of my SAP Mentor colleagues who are steeped in the Suite.
To your point about one platform for all dev - on that one my friend you can dream on. BYD is a totally different thing. Yes, built using ABAP (to which nobody is going to get a sniff except by royal decree.)
Bottom line - it requires a different mindset to that which dominates the BusinessSuite thinkers. Nothing wrong in that. Just different.
I'm watching this very closely both from the outside and on occasion on invitation inside the BYD tent. I've been convinced for some time this has to be a stand alone solution in the sense of being part of the SAP family but detached from the mainstream. I've watch what the anti-bodies do...like spend 90 days thinking about what the community might look like when I can spin up a WordPressMU community environment with all the necessary bells and whistles in 3 hours.
I'm "just" an ABAPer, but always willing to learn from other teams like Basis, Java and BPX and so I'm reading often in other forums as well. And in the future I hope to read about ByD blogs, wikis and forum entries ON SCN and nowhere else.
But first: we have to improve the look AND FEEL of SCN. In this point you so right.
Uwe
The fundamental differences are that architecturally, BYD is multi-tenant (hence can't touch the base code) and they have created a completely new UI and SDK.
Functions will be exposed into the SDK over time but SAP is being very cautious to ensure that anyone building new 'stuff' doesn't break the underlying system. So of course this is not moving fast enough for developers (as usual) but it is fast enough to allow SAP to get a good bunch of customers under its belt, discover the places it really has to do the heavy lifting while helping developers get done those pieces which turn out to be important but not for the core. It's all a fine balancing act and to be honest I would not want to be in development's shoes trying to make those decisions.
What we'd like to be able to accomplish is:
- Move to a more friendly platform for everyone to be able to contribute more easily. Today it is very difficult to ask non-developers to participate in the community because our platform is just simply difficult to use. Developers can work their way through it. Business users not so much.
- Provide a way for like-minded people to interact and engage with each other without having to sift through mountains of conversations that have nothing to do with them. (i.e., the classic would be technical conversations versus business conversations -- both sides could be annoyed by the other side consider it just "noise" in the stream.)
- Provide a way for people who want to cross the boundaries into other topic areas a way to do that if they have something relevant to contribute. (i.e., make the walls semi-porous so that people are not locked out of conversations they may have relevant and valuable contributions they could make.)
These are all challenges we are wrestling with and hoping to achieve with the new platform design.
Thanks so much for jumping in to get the conversation rolling Dennis!
Chip
Can't agree with most of your points. Here is why:
Most crucially, Dick introduced his blog post with this:
"Without a thriving development community (such as that present in the SalesForce community) the best “Go To Market” Strategy – regardless of whether the product is OnPremise or OnDemand - is doomed to failure. "
Dick is right on the money here. As you know, I've been harping on about the importance of community for BYD Add-on development since last year. Here are my recent posts regarding BYD and community:
http://www.pixelbase.co.uk/?cat=56
Let me go through your statements step-by-step:
you write: "The number one gripe about SCN is that it is way too focused on the Business Suite. Almost everything else gets drowned out."
SCN is far more than that. It's also to a large extend a technical hub of knowledge and expertise. I would argue that the people who said this don't know SCN that well.
you write: "Business ByDesign is unlike anything SAP has put into the marketplace. It needs to be treated as such. " and
"If the BYD audience is largely going to be business focused then, for example, how does SCN think that those same users are going to live with the crappy UI associated with blog post creation here (for example.) They won't. "
I sense that your main gripe is the tooling, not the place where it is held. Well, I think that could be easily sorted. The site where the BYD community forum is hosted could be somewhere else. This brings me to another point, actually: what kind of community are you and Dick talking about? I remember vividly from conversations I've had with SAP that "community" to them means an "end-user" community, which obviously is a totally different aspect. But I digress.
you write: "Why would anyone with an interest in ByDesign come to SCN? It is nothing like the Business Suite. It is not a sale to a technology buyer but to mid-sized companies that have a need for an integrated suite they can easily implement - no coding required."
One vital thing you're overlooking here is the A2A and A2X APIs. Developers have a choice here and I predict that the A2X APIs will become increasingly important in the medium term, especially if SAP creates a dev community-unfriendly high entrance barrier to the BYD add-on market for solution partners. No coding required when implementing, but lots of architecting, designing and coding required to develop an add-on solution. So a forum where people concerned with this type of work can exchange ideas is very important. Does it matter whether it is on SCN or not? I don't think so? Would I like better tools than what we have on SCN? Sure!
you write: "I agree that having a vibrant developer network for BYD is critical but it will be many a year before those same developers will need to be sharing code. "
Well if they can't share code in a SAP provided space, they will go somewhere else. Why? Because they can! Also: because it will speed up their development process and innovation. They don't want to re-invent the wheel. What you're saying does not make sense.
you write: "Instead I predict we'll see developers rapidly develop add-on modules for the white spaces SAP is not going to cover. They will likely share those in the context of a marketplace but that's about it. And from what I've seen, there just are not going to be that many issues with the SDK to warrant a large community."
And how will they come to a sleek and efficient dev process without code exchanges and forums? You're saying you're supporting a vibrant dev network, but then you're saying it will be years before they need to share code!? I can't see how this works together. As far as issues with the SDK is concerned, I have spent a 4hr session in app testing in a lab with SAP at TechEd. There was still a lot to be sorted out, believe me.
you write: "I could be wrong of course but let's put it this way: when I can follow a script, code it and have something 'new' running in BYD then ANYONE can do it"
I assume you're referring to the scripts we were given at TechEd. I was in the workshop, too and all we did there was to extend an existing business object and display a handful of fields on an existing view. Developing an entire new add-on for a different white-space that SAP does not cover is a TOTALLY different game, requires more experience. It's not like developing from a script. A dev process such as this would be extremely well assisted by a forum or place for developers to exchange. The underlying principle is not different from SCN. Whilst I don't like the SCN tooling either, I can see why SAP is thinking along those lines.
you write: "I also believe BYD developers need their own identity."
OK, some agreement here.
you write: "At the moment, those who know the Business Suite are making the instant comparisons and asking questions like: 'Why can't I just write ABAP?' Clearly SAP has a messaging issue here but in short - this is different, you're not going to be getting anywhere near the source code. You will be playing with business objects and forms. A totally different way of working and thinking. "
This conversation has moved on to a while ago to "Why not use Javascript? Like River does…". JS is going through a second springtime recently (thanks to jQuery etc), so the question is apt. I still believe that SAP has some tricks up its sleeve here. (OK, a bit of wishful thinking). Those people concerned about the language used in BYD all understand that ABAP wouldn't have been the right choice. And: ABAP development also includes forms development and business object design. Not that totally different after all !
you write: "And it is this difference in thinking that to my mind is the hallmark of why a BYD community should not come anywhere near SCN. Anything else risks the 'old world' anti-bodies from stifling innovation on this solution. "
Whilst I can see why you're wanting a fresh start, I have to disagree that SCN stifles innovation - because that's what you're essentially saying. I know "Innovation" is becoming an overused term by SAP these days. Analysts struggle to define it in press conferences I've been told. 😉
A dev community is very important, not in the mid or long term - it needs to be in place form the word GO. Maybe SCN wouldn't be the best place for it, but that's only a logistical problem.
Regards,
M
You can say all you like about what people do or do not think about SCN - I am expressing the reality of what people experience when they come to the property. To deny their experience or say they should take a deeper look is not helpful.
Underpinning what you're saying is a move towards getting at the code and that just is NOT going to happen. I really wish people would get that straight.
Neither is SAP going to listen to arguments about this or that approach. They have made their decisions and developers will either get on with it (as some are) or spend their time arguing the finer points of this or that language - none of which writes a single line of useful code but continues arguments geeks love and which are of absolutely no interest to people who use systems.
Hasso said to a bunch of us over a year ago: 'over my dead body' in talking about access to the code. That's good enough for me and for good reason. You cannot run a multi-tenant system and allow people to touch the code. That's one of the principle reasons I want to see a BYD community as far away from SCN as possible. No contamination.
There's huge pressure on SAP to open up the box but it would be suicidal and almost certainly kill BYD in a heartbeat. SAP knows this and you can be sure that If they did do such a thing I would publicly flay them.
I don't know how many times I've heard it but you've really got to get that thinking out of your head. This is one of the fundamental problems holding up development rather than taking it forward.
My problem is NOT with the tooling although I don't think there is any argument about how crappy SCN tools are. Fact remains, business people won't use it. Holy crap, it takes me 2x, 3x longer to get a post up here than it does on my own blog. I could rant on for hours about that but we know something better will come...eventually.
Your mind reading argument that I am somehow conflating lack of innovation and SCN is plain wrong. There's plenty of good stuff going on, I know that. That's not the point. It is about the old style anti-bodies that want to drag SAP BYD back into the ABAP comfort zone instead of understanding the new reality.
Folk working in BYD are going to be spending most of their time, in the short to medium term on config - not code. How about supporting them first and see what they want? That's a business and process centric approach. Nothing to do with code which dominates SCN.
But the proof is in the eating. We've already seen B1 community pretty much failing, BPX has had a tough time...what makes you think that an SCN hosted BYD community will fare any better?
BYD needs the best help it can get if it is to fulfil the company's vision and having seen what's happened re: other technologies in the SAP stable and knowing there are better alternatives I cannot see any sensible reason to have it here. But heh - SAP will do what it wants and so will customers.
You're getting the wrong end of the stick here. Your view, your reality still seems to be that developers are almost zombie-like banging the doors for access to backend SaaS code. As I have said before, those who have interest in the topic are way beyond discussions such as this.
Please stop talking about this myth that all developers are profusely demanding to access backend code. If they do, then maybe out of personal interest, as BYD was completely developed from scratch and therefore is an interesting piece of software engineering. But apart from that you really have to get that notion out of your head. Any extension of the existing BYD suite has to be done via the SDK. Those with beef in the field know this for some time now, so stop going on about it.
As far as BYD is concerned, you would like to be practical and don't need geeky discussions. I can tell you that we're absolutely aligned on that one. Interestingly enough, you're saying that "some" are getting on with writing code. Only time will tell if these few are enough to develop all the meaty add-ons required. I'm not talking about a few custom fields here and there like in a TechEd Workshop. I'm talking a full blown add-on suite for a white space, which won't be built in a week or two. In this area, other developers and I think SAP is heading the wrong way.
Just to reiterate, because I think there's a misunderstanding: My interest is in add-on development and the toolkit that is provided by SAP for this. That's because I'm a developer by trade. Implementing a SaaS solution such as BYD is a different thing and requires other processes. It's important we all stick to what we know.
I've been planning a separate response, but since Michael has written down my thoughts exactly, I'll comment here: as a developer (and btw, having been in that same session at TechEd), I totally agree with Michael that, as far as (serious) add-on development is concerned, there is a lot to gain for SAP AND it's customers by setting up another developer community around the BYD SDK. SCN would IMO be a natural fit for this, because 1. The developers are here already, and 2. CodeExchange is a good way of sharing code (and indeed, this is not going to be backend code, but SDK-language code).
On the other hand, I can imagine another business-centric community around BYDesign itself, and that wouldn't need to be anywhere near SCN. So I think this split could really do the job both ways.
Regards, Fred
I agree and think that the users/owners of the BYD implementations should decide where their online community should be. I think also keeping it as far away from ABAP developers is a great thing. Honestly I still see way too many ABAP type questions in some of BPX forums where ABAP should not even be discussed. However since I am not BYD user/owner of a BYD customer implementation its not my call.
Take care,
Stephen
ByDesign is nothing but software. Anyone who understands software would have no problem understanding the philosophy and the requirements of ByD. Yes, multi-tenant requirement is something unique to ByD. All we probably need is a "delta" training on this. Not sure why this would require a completely different mindset. Aren't we already using "multi-tenant concept" to some extent in current environment? Like running more than one app or db or both in a Virtualized/non-virtualized environment in one server.
Let us look at the other side: 10+ years ago, a mistake was made in my opinion. BW required a different mindset. R/3 is pre-configured/general purpose software to a large extent. However BW was not. The design work for BW was/is mostly performed by the customers. Even though SAP's documentation explained/supported DW principles, there was a messaging issue. So all major benefits of BW is not being exploited. Not only we failed to exploit the benefits of BW but also inadequate level of DW knowledge led to performance issues, gaps in meeting the business requirements, budget overruns, code maintainability etc. Based on this experience, I would think building a Berlin wall between ByD and SCN is a great idea.
My 2 cents.