Companies of all sizes and in every industry are racing to innovate, both to keep up with the rapid pace of economic change and to optimize business processes in alignment with the sheer volume of advancements in enterprise technology. With cloud and mobility nearing preferred status for business applications, and with the Internet of Things (IoT), sensors, and connected business networks having a significant impact on how companies operate in an increasingly digital economy, innovation is an imperative.
One way in which the race to innovate manifests itself is with the steady drumbeat of custom applications that companies are developing on top of their enterprise stack. For the SAP customer, development is facilitated with SAP Cloud Platform, which customers are using to build, run, and extend their existing SAP environments. Having the right tools and platform with which to tackle innovation, however, is just one component of an end-to-end development process culminating with an innovative app that provides real business value. As many companies are all too familiar, an app’s innovation can only make an impact when widely adopted by end users who are satisfied with its ease of use and reliability for adding value to the business.
A Changing Development Mindset: Design-Led Development
Traditional thinking pertaining to the creation of a custom-built application held that only an IT department had sway over development. In the days of mostly static, behemoth on-premise landscapes where change moved at a glacial pace, this thinking made sense. With the challenges of custom coding, integrations, and other technical requirements, the concerns of line-of-business (LoB) administrators, analysts, end users, and other stakeholders were secondary; when there was input and collaboration, it was given in the form of change requests that for the most part came after deployment or the end of development and, as many developers know, were often related to concerns about poor usability or flow.
Along with the astounding pace of innovation, the consumerization of IT is also responsible for transforming this traditional way of thinking for how people consume apps and how companies develop them. People can download an app on a smartphone in seconds and begin interacting with it like it’s second nature. Why can’t they do that at work, they wonder? Or, at the very least, why can’t they be more invested in whether an app works according to how they complete their day-to-day responsibilities? They certainly are not going to tolerate anything less from a personal app, and that same mentality is infusing itself at the enterprise level.
To address this concern, SAP has developed and released Build, a set of cloud-based tools built on design thinking methodology for non-technical users to develop enterprise applications on top of their SAP environment (see
Figure 1). The concept for Build took shape as an answer to a question: What if non-technical end users were invested in the design and development phase earlier, and could validate an enterprise app’s progress throughout the entire development process (see
Figure 2)? So a set of tools aimed at accomplishing this goal — including a set of learning tools, design best practices, easy collaboration and feedback, and progress monitoring — could significantly reduce the number of change requests, reliance on IT, and overall cost involved. Importantly, this process — design-led development — would also help ensure that an app’s usability meshes with the expectations of end users from the outset.
Since its September 2016 release, more than 40,000 customers have used Build to assist in app development to create more usable and more effective enterprise apps. Overall, these customers are reporting 50% shorter development timelines, with 75% fewer change requests. One company in Europe, frustrated with the development of a sales app, turned to Build and reported that it was not only the most efficient development process they had ever encountered, but that it was enormously helpful in changing the organizational mindset about IT, which is now recognized as a consultative and collaborative partner.
4 Foundations of Build
Build has four foundational parts that, together, encompass everything non-technical users need to ensure they build the right apps with the right experience and the right cost.
1. Learning
Because Build’s target audience is non-designers, it was important to include a knowledge-based set of learning tools to guide users in design-led development. This does not mean Build offers a crash course on how to write code, a skill that is not required; rather, it offers practical advice concerning basic design thinking concepts. Before building a prototype with Build, the learning set provides users with a “roadmap” to help them arrive at a vision for a finished product. It helps novice designers ask the right questions about how to drive a superior user experience (UX), or how to build an app that helps move a company toward digitization, and provides SAP Fiori best practice design concepts as a path for translating questions into action.
2. Gallery
Designing an enterprise-grade business app can seem daunting, especially for those end users and non-technical folks who are not well versed in the app development game. The Build gallery turns intimidation into inspiration by giving product owners, business analysts, and others who are new to app development real-world examples of what constitutes a good UX and user interface (UI). The gallery is populated with many SAP Fiori apps built on SAP Cloud Platform that customers and partners can use in their organizations, or clone to use as a starting point to repurpose for their own ideas.
3. Prototyping
When IT ran the show for extending an enterprise platform with custom-built applications, the earliest that end users would weigh in was with change requests after costly development had already occurred. This sent developers scrambling to remedy the issue and come up with a second iteration, and the time-consuming process would start all over again. Because users recognized that it was a drawn-out process, they were prone to reluctantly accept designs they weren’t fully satisfied with, just to avoid another iteration with no guarantee of a better UX. With an agile requirement-gathering process, Build transforms this traditional development method by pushing out a prototype early on until an app’s viability, desirability, and feasibility has been thoroughly assessed by the business and IT. With collaboration from a diverse group of stakeholders prior to development, a working prototype can be created with Build and handed off to all users in a matter of minutes. With learning tools and apps available in the gallery, users can be confident that this working prototype is more than just a trial balloon, but rather a model that has many UX best practices built-in.
4. Feedback
With the fourth and final foundation for Build, the creator of the prototype can see the hard numbers about how users are interacting with the prototype: where they’re clicking, where they’re hesitating, how much time they’re spending on a screen, and other valuable information. This is because with Build, users working with a prototype can easily offer comments and suggestions that a developer can see on a screen in near-real time. Build can help transform how apps are developed on top of an SAP environment, but it does not mean that change requests are eliminated. What Build can do, however, is make them far less frequent and costly. Early use case studies show companies are moving to high-fidelity prototypes within two or three iterations, and are doing so using the SAP Fiori and SAPUI5 building blocks that define the look and feel of an enterprise-grade app on SAP technology to extend their existing SAP environments.
Once the prototype is complete and all feedback has been received and incorporated, the prototype is exported into SAP Web IDE, the SAP Cloud Platform development environment. Here, the entire code for the UX layer of the app is generated. A developer will only need to complete some business logic and connect the app to back-end services before the app is ready to be deployed in the cloud.
Sharing the Secret to Success
The conception of Build started out, as is the case with more than a few innovative ideas, with internal pain points. During the initial development of SAP Fiori, teams were inundated with change requests. To combat this, development teams sketched designs very early in the process and sought feedback from all stakeholders prior to actual development. More than 100 interviews with customers followed to understand their pain points and development processes: When did validation occur, or when was prototyping done, for example?
Prototyping tools are helpful only if everyone involved in application development is on the same page, shares a vision, and can draw from the same well of knowledge for how to optimize the tools at hand. The realization struck that by adopting design thinking methodology and embedding the tools, the know-how, the learning, and the process together in one solution, it would be possible to transform the way people develop software on top of SAP systems.
With the tools that Build offers, end users cannot help but feel vested in the process. In the testing of a prototype, for example, with Build they can work with embedded test data that the customer provides. This fact, combined with the prototype using real SAPUI5 and SAP Fiori elements, provides for a painless validation point because the customer is working with a model that they’re likely already familiar with. When the developer and users arrive at a working prototype, Build provides the code line for the front-end layer, leaving the developer to create the back-end business logic and connectivity to services. By using Build and incorporating design thinking into the process, there should be no need for change requests, barring unforeseen circumstances.
For more information, visit
www.build.me.
