We are getting more and more questions from traditional SAP shops to help them set up a bimodal architecture. The benefit of this bimodal architecture is obvious to us, but it is great to see that others are starting to see the enormous business potential of the idea.
So what is bimodal architecture? We like to compare it with a marathon runner versus a sprinter. Your backend landscape (e.g. SAP, JDE, Oracle) is typically depicted as the marathon runner: in it for the long run. A marathon runner needs tranquillity, stability and peace of mind, just like your backend transactional core needs to be stable and reliable and to keep on running regardless of the conditions. Changes are brought about slowly and rightly so.
But for your front-end development you need an altogether different pace. If you want to have an application on top of your SAP backend to support a campaign, you need to have that done as fast as possible and, equally important, if you find a flaw or improvement during the first days of that campaign, you want the app adjusted as quickly as possible. The same goes for any customer facing application: if you find a bug or a quick win, you want that change implemented as fast as possible to help your sales teams to win in the marketplace. When you think about it, why don’t your vendor and employee facing applications deserve the same treatment?
It seems that once people look outside of the SAP bubble and ecosystem, they really see the value of SAP and what they can do with that massive functionality – armed with an RAD development platform.
At NovioQ bimodal architecture is at the heart of every project we do: use SAP (Mode 1) for what it is best at – secure and well-performing transactional recording – and use an independent development platform for truly agile application development.
With the emergence of Rapid Application Development (RAD) platforms, Mode 2 architecture has grown from a theoretical possibility to a real proposition. Now that some of these platforms have matured from great, but incompletely worked-out ideas into comprehensive enterprise level development environments that are not only in theory, but also in practice low-code or even no-code, they are ready to take their place in bimodal IT.
RAD brings real collaboration
The beauty of working with a well-built RAD platform is not only the obvious time and money gains in terms of fast delivery, but also the fact that the technical side of development is very much understandable to the business. All applications we build are a co-creation between the business and the development team. And the business people – without any prior development experience – can fully participate in not only the mock-up phase, but also during actual build. And vice versa: the technical people are involved from the start of the project and help the functional people shape their requirements around the current technical possibilities.
What’s more, the time to build applications has been reduced so drastically, that the functional people need to deliver specifications at full speed. And even then there is a serious risk that the developer will deliver applications before the functional consultant has finished specifying the next one. So you really need to manage a tight ship to make sure resources are not wasting their time waiting for others to complete their work.
The reduced development time also eliminates the need for offshoring. Because of the high delivery speed it is advisable that the team members work together face to face. Because the number of resources needed to build an application is dramatically lower than in traditional SAP projects this has no adverse effects on spending, but is a major leap forward in quality. Of course you can keep using offshore resources, but be aware that the cost of detailed specification adds to the cost of the project and quality of the deliverable is likely to be lower.
How does Fiori fit into all this?
Building Fiori applications is hard work. You need an experienced team well versed in SAPUI5, CSS, Java, ABAP, SAP Gateway, Portal and possibly some more, like a Sharepoint consultant. And because of the size of the team you will need a project manager, PMO and secretary. If you are to build a new application from scratch that goes beyond the classic master-detail scenario, then you will need a hefty budget and serious project management to get the job done, while you will need to have the same skills available for support during the lifecycle of your application. Fiori is not fit as a Mode 2 in bimodal architecture.
Another problem we see with using Fiori is that we see a rift in the ABAP community. People need to make a choice to become either a frontend (SAPUI5, Java, etc.) developer or a backend (ABAP) developer. The added value of the classic ABAP developer is that he or she is not only capable of creating sound programs, but also understands the SAP processes and functions under the hood. This advantage will be lost, once the community splits into frontend and backend development camps. And if the frontend developer doesn’t understand the SAP processes anymore, what is the advantage of sticking to SAP frontend technology?
What we recommend customers: if SAP delivers an out-of-the-box Fiori application that fits your needs, use it. When you need to extend the Fiori application with custom data or when you need to interact with other systems than one SAP installation, it might already be worth your while to develop from scratch using an RAD platform, depending on the impact of your custom requirements. When you need to develop an application from scratch, we always recommend RAD.
At NovioQ we have taken a long time to look at most RAD or PaaS development platforms out there, after having being rather disappointed in SAP’s Composite Environment 7.3. In the end we decided there was only one platform out there that could deliver in terms of rapid delivery and easy integration with SAP: OutSystems. The platform sports a native SAP connector that allows for easy use of SAP Remote Function Calls. But OutSystems is also planning to connect to the SAP Gateway using OData. The fact that OutSystems is continuously improving the way it connects to a major system like SAP is one of the reason we enjoy working with it.
SAP integration with OutSystems is a breeze. Simply connect to the SAP system you want – you need an IP-address and user credentials – and start consuming Remote Function Calls in the exact way that you use OutSystems functions. And of late we are not alone in our choice for OutSystems. Forrester has identified OutSystems as the new leader of low-code platforms (source: Forrester Wave™: Low-Code Development Platforms Q2 2016):
In the end the proof of the pudding is in the eating. We have done quite a few successful projects to this day, building applications on top of SAP using OutSystems. These are not apps, mind you, but serious business applications that run in a browser or on any mobile device with the level of security, stability and performance one expects from a business application, and fully integrated with SAP.
Once people embrace OutSystems, it is amazing to see how enthusiastic they are about RAD development and the creative plans they come up with for future applications. It seems that once people look outside of the SAP bubble and ecosystem, they really see the value of SAP and what they can do with that massive functionality – armed with an RAD development platform.
Question? Remarks? You can contact me at my LinkedIn account or send an email to firstname.lastname@example.org