Thoroughly Modern: Understanding Your IBM i Web Application Needs With Application Discovery

February 8, 2021 Scott Gingerysty and Derek Woods

Considering web and mobile development on IBM i? Before you start coding, it’s helpful to assess and validate your vision with a Discovery. Adding this step to your development process increases the likelihood that your project will succeed because it gives stakeholders a clear understanding of what you need, how the application will solve users’ problems and what it will cost.

Fresche’s Web Application Development team is frequently called upon to consider a new business application and estimate how much it will cost to build it. With the amount of detail we typically have at this point (to wit: almost none), we can plausibly only suggest that it will cost more than a breadbox and less than the Death Star (we think). That’s where the application discovery phase of a project comes in handy.

What Is A Discovery?

There are a couple of different discoveries that we can undertake: a strategic modernization Discovery, and a Web Application Discovery. The former is a comprehensive strategic assessment of an IBM i shop’s infrastructure, applications, and business vision. The latter is a much more focused endeavour, looking at a specific need. We’ll be discussing the Web Application Discovery in this article.

The Web application discovery phase aims to understand what is needed and estimate the cost of building it. Once it has been scoped and estimated, the decision to proceed or not is made. The goal is to understand enough of the users’ needs so as to make a reasonable estimate of the cost to build. Estimates aren’t really meant to be accurate (in fact, the words estimate and accurate mean different things), but they can be more or less close to the mark, and the application discovery process helps us get closer to that mark.

Key to the whole process is understanding the user needs, and the value that answering those needs provides. This really means getting close to the ultimate users of the application and living in their world. To effectively do this we need to cultivate a certain way of thinking.

The Discoverer’s Mind

The discoverer has an interesting challenge: to find out the customer’s real needs, and to propose a solution that meets those needs.

Why do we say real needs? Having worked in software development for many years, all too often we have been in the situation in which the customer states “we need x, y, and z”, only to find out later that they merely wanted these things (sometimes without even knowing why). And to everyone’s later dismay, realizing that some of those wants didn’t serve the needs they truly had.

So we want to unpack what they need, and the value that this provides them. To truly understand their needs, we need to be in their world. We need to abandon our preconceptions about what we think we know and empathize with their problems. To consider a discovery through different lenses, try looking up some of the synonyms for discovery: detection, disclosure, encounter, introduction.

We have a lot of experience building software, and we think we know a lot about it. And yet with that expertise comes the risk of believing that “we know better.” The Zen concept of Shoshin, or “beginner’s mind,” can be helpful here. Although we have many years of experience in software and solution development, we need to try and think like a beginner, and soak up the world of our customer. We need to be vigilant about not prematurely pruning the decision tree, so to speak.

The Discoverer’s Toolkit

Web application discoverers have many different tools and strategies at their disposal. Here are some of them:

Setting the stage: Discovering a whole new world, understanding key needs, and eventually proposing solutions is not a trivial task. Having a good start is imperative to success. We kick things off with two very simple, yet important, questions.

What are your goals?

How will you measure success?

These two questions are perfect for forming the foundations for the discovery activities to follow. They help everyone clearly understand the main goals and the key Measures of Success (MOS).

Don’t be afraid here. Jump in and put them up on a white board with reckless abandon. You are not writing them in stone, because this is a discovery and you are just getting started! Almost every activity in a discovery should end with a review of the goals and MOS to see if we are still aligned or if we need to make adjustments.

Other important things to consider when defining goals and MOS are to consider the audience. We want to hone in on the true users of the application. This means that we need to find the right people.

Personae, User Stories, and Interviews: We now have some high-level goals and MOS. Up next, who is going to use this thing? Who are they? Are we talking to the right people? The real users of the proposed product?

Often the needs are delivered by an intermediary, such as an IT team member or manager. We’ve been in the unfortunate position of having an intermediary tell us that they don’t want to give the users a voice, because users will ask for the moon. We need the actual users telling us about their world and what they do.

Sometimes we are told an application will service user A only to find out later there is Manager B and Customer C who weren’t considered. We need to be conscious of all user types, no matter their level of interaction with an application. A simple activity we can do here is map out the typical workflow of the “jobs” or “operations” to be completed. This helps us identify the user types, or roles.

Now that we know our different user types (personae), we can dig deeper to understand them. How do we figure this out? Let’s hear the story straight from the source: for our next Discovery activity we interview users.

This provides insight into what they need to do, and why (the user stories). During these interviews it’s important to keep an open and unassuming mind. We’re looking to identify nuances or subtle things that a user does. It is not just the “What?” or “How?” a user does something, it’s also the “Why?”

Questioning the Answers: Consider the “Five Whys,” made famous by its use at Toyota. Although this method of inquiry is typically used as a troubleshooting strategy, there is no reason why you can’t think this way when learning about user needs.

For example, we were doing a discovery for an application where dispatchers assigned jobs to contractors. The stated need was: “We need to know how jobs are allocated to contractors.”

From the managers, we heard:

Why? So we have a better idea how many jobs a day we complete
Why? We want to maximize the number each contractor gets
Why? It gives the contractor more opportunity to maximize their pay
Why? Because we can better plan the jobs of the day
Why? It helps us better serve our customers

From the dispatchers, we heard:

Why? So we have a better idea how many jobs a day we complete
Why? We want to maximize the number each contractor gets
Why? We want to be fair to our contractors
Why? Because we want happy contractors
Why? It helps us better serve our customers

Notice that there are some slight variations in the reasons between user groups. This was new and enlightening. Armed with this key information it helped us identify key metrics that we included into the user UI. Everyone wins!

Wireframing (Because a picture is worth a thousand words): Before we start slinging code we like to validate our customers’ thoughts and vision with a wireframe. A simple visual representation of how a proposed application will work, a wireframe can be as simple as some sketches on paper or as interactive as an HTML skeleton of the proposed application. The key is to illustrate what the users will do and how it solves their problems.

We use a wireframe to share our thoughts with the customer frequently and make sure we are going in the right direction and speaking the same language. Like the Goals and MOS, the wireframe is another artifact we can reference often and modify organically as the Discovery pushes on.

Although there are many different tools and strategies regarding wireframes, they all share some of the same moments of Zen:

Fail fast and often
Get user input early and often
Grow the wireframe together

“A designer has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

The Joy of Discovery

There is a satisfaction, a joy even, in learning what people do. There is nothing quite like the “aha” moment when we truly understand something, especially when a simple thing is drilled into and found to be more nuanced than it appeared. And this can go both ways: the users know that they have been heard, and they have been understood. Nothing facilitates user engagement like the shared understanding built during the discovery. Now they have some skin in the game, which is exactly how to finish the Discovery phase and take the next steps.

If you’re thinking about embarking on an IBM i web and/or mobile development project, I encourage you to give us a call. We can discuss what you have in mind and point you in the right direction. You can reach us at 1-800-361-6782 or info@freschesolutions.com.

We also encourage you to attend Fresche’s virtual IBM Application Modernization Series, which begins tomorrow (Tuesday, February 9, 2021). Every Tuesday and Thursday until March 9, we’ll focus on an area of IBM i modernization, from roadmapping to web development, field resizing, testing and almost everything in between. You can learn more and register here.

This content is sponsored by Fresche Solutions.

Scott Gingerysty is a Web Developer and Application Modernization expert at Fresche. To say he is passionate about IBM i application modernization is an understatement. Since 2013, Scott has breathed new life into business-critical RPG applications using Presto, Websmart PHP and JavaScript. Whether it is new development, augmenting existing applications with modern technology, or modernizing GUIs, Scott helps companies integrate, leverage, and extend applications to meet current and changing needs.

Formerly on the development team for award-winning web development tool WebSmart, Derek Woods is now a Software Product Manager at Fresche. He started his career on the IBM i in 1999, just in time to pull the night shift for Y2K support. With dozens of successful web application deployments under his belt, he has a keen interest in helping everyone continuously get better.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search