An Opinion Blog: Floorplan Manager – A Compromised UI Solution from SAP?
I’ve been reviewing a lot of code lately; much of this based on changes to Floorplan Manager (FPM) applications or development of new Floorplan Manager apps. And do you know what I have not come across yet? I have not come across a Floorplan Manager app that I think is a good clean, simple design. Don’t get me wrong. Some of what I see is very good based on what is available, but when you think about software concepts like separation of concerns and variations of UI patterns like Model-View-Controller (MVC) – there seems to be one or two things that always stick out as limitations. It’s like your elegant design having a party and this small piece of bad design shows up uninvited…Awkward!
So there’s a lot of good in FPM, so let me highlight my theory about what was architected to be great:
- The ability to get a consistent style of interface, especially with Global User Interface Building Blocks (GUIBB’s).
- GUIBB’s providing the ability to create UI’s with small amount of code in a feeder class (which is mostly very similar each time); and some configuration.
- The whole FLUID editor (and the improved workbench in the latest releases)
- Reuse of UIBBs within a UI in different applications
- Plus lots more
The biggest feature though is the ability to provide configuration based enhancements/adaptions or personalisation capabilities for SAP developed content without modification and in many cases without even coding. And this is what I feel is the main point of FPM. To benefit customers, and not necessarily make life as easy as possible for developers (though it doesn’t go out of it’s way to not do this either).
Note – At my current customer, we saw the benefits and committed to FPM rather than straight Web Dynpro because we know it’s the future of Web Dynpro development (note I didn’t say future of UI development). After spending more time with it, and realising the above, we’re less certain this was the right approach for custom developments.
So where it becomes tainted is when you need to develop one of these from scratch. In essence, my concern is for all of SAP’s developers who are developing non-Fiori/BO/Mobile business suite applications with FPM and customers wanting to develop their own apps.
My issues are:
Poor examples of enterprise design being trained/highlighted.
Lack of consistency by SAP themselves in using it.
Reliance on singletons, highly structured wires, or events containing data that don’t provide any real controller to your application.
Lack of realisation within many consulting companies that FPM is not just Web Dynpro and that training is required.
The Fear Uncertainty Doubt (FUD) that goes with UI development and FPM causing simple UI’s to become very expensive.
Let me explain further below but first may I also say one thing that is really great is the FPM Developers Guidelines/Cookbook. It truly is a cookbook in terms of size. e.g. Imagine you have a large recipe book and you go and try eat all the recipes in one go – Futile right? I think I’ve gone back to the FPM Cookbook hundreds of times to get more recipes out of it. It is a great reference, but be warned, it will overwhelm most people if they try to learn FPM from the developer guidelines (which I tried to do initially).
Anyway, let me explain the issues and being a helpful consultant I’ll provide a recommendation to SAP/yourselves to get around this issue.
Please note: This all assumes you don’t want to move to HTML5/Gateway development for business applications just yet 😀
Issue #1: Poor examples of enterprise design being trained/highlighted.
With FPM, the training appears to cover the basics from what I can tell but doesn’t get into design patterns per se. I didn’t get any response to my question specifically asking about this so can’t be certain:
The cookbook covers off aspects but no holistic view of how it should all hang together. So many options but “WHAT SHOULD I DO!?”!
Many examples on SCN look at single UIBB’s, or a screen with multiple UIBB’s talking to each other without application context. e.g. Very few examples of real applications.
Now I just noticed this book which has one section of the book which looks hopeful – Definitely something I’ll check out at TechEd next month:
Issue #1 Solution: TEAM FPM are doing a good job of trying to resolve this; and I think it’s the “recommended” end to end examples that are probably missing to really solve this issue. Ideally the end to end design should show a low-fi mockup of what is required and the thinking required to design the solution. Not an easy blog to write but would be very valuable to the SAP community. Note – There are a number of frameworks in place each requiring different thinking, but let’s just go for the simple scenarios first.
Another option is to buy that book and see if there are any answers there. If you’ve read it, would love to get your feedback, otherwise I’ll get back to you on that one.
Anyway, for now, checkout TEAM FPM blogs, and also look at the following wiki page (slightly dated now days but still has good info):
Note – Part of the issue is also to reinforce the underlying UX patterns that are required within the GAF/OIF/OVP’s since you’d be very surprised what some developers think is normal within a GAF going from Initial screen all the way through to Confirmation screen as an example. At the end of this blog you’ll see what I’m going to do in the end for simple apps which will probably become an anti-pattern but at least it will be easy to create and maintain the FPM app IMO.
Issue #2 Lack of consistency by SAP themselves in using it.
Have you ever worked on HR FPM apps? What about GRC apps? What about the EPM Model examples considered to be a good example of design. HR uses Singletons most the time (arghh!); I believe GRC uses a monster framework which makes FPM development very easy but makes understanding it all a nightmare. EPM is almost nice with it’s use of shared data but lack of application controller was my problem I saw with many examples there.
For reference, here’s where Sandra Thimme referenced the EPM models within the Netweaver stack as a good starting point for enterprise examples:
Plus link to EPM Model information she references:
Issue #2 Solution: Partly same as issue #1; though we do need to grasp all the different frameworks out there and preferably get them under control. GRC is becoming another HR or CRM with how much unique behaviour is being built into these frameworks.
Issue #3 Reliance on singletons, highly structured wires, or events containing data that don’t provide any real controller to your application.
All I want in a simple application pattern is a controller, a model and set of views. The views should be able to map to the required model/data via the controller. The view can fire events that reach the controller, but the controller effectively controls the overall behaviour beyond a view.
Now use of Singletons is reasonable within the controller (using the app controller within FPM), but do I then create Singletons for every View? Do I reuse singletons across different views even though they may not relate? How do I know what visibility the Singleton’s have. In essence, singletons are not the answer here unless we’re talking about one-off UI’s that are not reused. Yuck…
Wires seem to do the trick, but locks you into this list<->object style of interaction with specific coding also required. It’s also very behind the scenes to the application and a little out of control IMO which personally I don’t really like. Good thing about wires is the visibility given though directly in the FLUID editor. Note of warning – I’m very green when it comes to the usage of wires so probably have a lot to learn and maybe the above can all be solved easily.
Shared data – Well – This is probably my recommendation for larger apps and something worth exploring further as a good standard – though still a little hidden in terms of context unless you go searching the code.
Issue #3 Solution: Now this one requires development effort to the whole FPM framework. Extending the Application concept to similar to the context mapping in Web Dynpro would be fantastic so that visibility is easy. I’m guessing we’re not going to see a change here and have to live with one of the approaches above with hopefully at least some improvement in visibility within FLUID. Awkward!
Issue #4 Lack of realisation within many consulting companies that FPM is not just Web Dynpro and that training is required.
So as the System Integrator, you win a brand new greenfield implementation or upgrade project. Fantastic. Maybe it’s just ERP – Okay – We have ERP trained consultants – all good. Now unless you have a very strong technical director in your company – will they really know that things have ever so slightly(!) changed since Web Dynpro was introduced; and even if they do realise, do they have the power (& budget) to ensure that developers working within the UI space need training? My guess is rarely this is the case (at least in Australia where SAP training seems to cost more than in some other countries and developers typically need to know everything and cannot get all the training they need).
e.g. I remember early on my current project, people were looking at modifying the solution quite often not realising that configuration or enhancements in FPM were possible. Luckily we had a process to require approval to be given for modifications and implicit enhancements the current development lead and I had gone to the enhancing FPM apps session at TechEd last year to understand what was possible.
Issue #4 Solution: This is a common issue for SAP consultants across many areas, and realistically, it will come down (again) to the solution to the first issue since budgets for training are difficult to come by. Having one person officially trained, then doing internal training can be quite cost effective. At the very least, you can afford to buy the book I mentioned above!
The other point is for customers to check the credentials of customers, and ensure appropriately trained consultants are used. e.g. Asking for certification, while I personally don’t feel is that important, is one way of ensuring that a level of recent training has been undertaken. It also means that customers need to have the ability to review resumes and potentially interview their key developers.
Issue #5 The Fear Uncertainty Doubt (FUD) that goes with UI development and FPM causing simple UI’s to become very expensive.
There’s a theme going on with these issues. Lack of training and enterprise design examples are causing this. Simple Applications should take only a couple of days to build including documentation (but excluding stakeholder UI design/requirement sessions, reviews and approvals) for a experienced FPM developer who has a few Enterprise patterns up their sleeve already.
To bring home my point, get a developer to quote doing a simple ABAP report; then get them to quote on the same report in FPM. They should take around the same amount of time if they use the right GUIBB’s, and alternatively format the ABAP report nicely.
Issue #5 Solution: See above! In addition, to get things moving, see the end of this blog for my first step to resolve at least this aspect for simple applications.
Off-topic issue: One last issue slightly unrelated to FPM:
SAP: Please add the ability to save default variants to the search UIBB – It’s such a glaring omission from the UIBB and I get people incorrectly implementing POWL’s for reporting purposes just to provide this functionality!
What’s my next step for all of this?
Well, I’m obviously going to be asking a lot of questions and requesting a lot favours at TechEd next month in Vegas (Mentioned a few times now – Can you tell I’m excited?), but also, I’m challenging myself now to post within the next week or so, the first end to end design approach and pattern that is reasonably easy to build and maintain with limited bad code (FYI – The awkward part of my design includes statics). The development lead at my customer has implemented this pattern to help him (and myself) better learn FPM and it’s quite effective and reusable for the very simple requirements we had. I’ll post it as a document in order to get improvements made over time since I know there will be better ways to doing this.
What’s your next step for all of this?
If you’re SAP Product management for FPM – Please control the other developers outside your space in SAP by listening to their concerns and providing guidelines to them on how to do this consistently in order to get maximum benefits. No more rogue framewoks please. And how about publishing these guidelines on SCN so everyone can benefit?
If you’re a developer – push for training, buy the book (letting me know if it’s any good), keep reading SCN, record the FPM cookbook and play it over and over while you sleep. And let SAP know what needs improving and any ideas on idea place to improve the tools.
If you’re a customer – Ask your SI what they are doing to get on top of the new tools (not just FPM)? Review CV’s, especially when doing custom development. Build your own list of approved UI patterns based on the SAP patterns, and get user experience owned internally.
If you’re an SI – Train your people on the skills they need to do their job before they need it, or at least just in time – noting that they will need play time to come up with enterprise designs. At the very least, have a good development architect who you invest in who can train/mentor the team when required. Preferably make that person a director/senior manager/partner, and give them budget to train people on projects properly!
And for everyone – provide your feedback on your experiences below, whether you disagree on the above, what you love, what you hate, or what you plan to do in Vegas at TechEd outside of the conference (I’m always up for new ideas on what to do before TechEd too)! Have fun all and thanks for reading.
Update post SAP TechEd 2013
I should add to above that after speaking with the folks who build FPM at SAP TechEd, they informed me that saving of default variants is in the current release of NetWeaver (actually been there a couple of support packs I believe) – Huge win for the Search GUIBB! They also gave me more feedback/information that I need to consume but will provide a blog hopefully next month once I get past my Matt Harding’s Fiori Like Challenge – Let’s Ideate (e.g. Brainstorm)…(Part 2)