Who Owns the Rapid Application Development (RAD) Landscape?

Assessing Your Competition

What’s comes to mind when you think about any competitive landscape? One of the biggest questions should be–and one that you can hopefully answer when researching a new product–is who, exactly, is your biggest competition? And how do the top competitors stack up against each other? This question also applies when taking it from a VC (venture capital) perspective. Many entrepreneurs and startups are of the opinion that they are so unique that they have no competition. This may actually be the truth, but if you need VC money, don’t claim this. Why? Because if you have no competition, they might think there is no market opportunity. Some startups are reluctant to mention competitors because they may have certain advantages, features or price points they can’t match.

But we digress. Having said all of this, do you as a Servoy user know what the RAD landscape looks like and who the competition is? There are three distinct categories: the first is no-code and low-code vendors, second we’ll discuss RAD platforms and third we’ll talk about DIY stacks. Let’s take a look at the differences.

No-Code and Low-Code Competitors

No-code or low-code platforms are extremely well suited for less complex or smaller, and often in-house applications. Let’s say you have done your research and find there is no off-the-shelf Software as a Service (SaaS) application available for your industry or specific need. Btw it’s easy to find SaaS apps, just check out for example G2Crowd or contact research firms like Gartner or Forrester. Companies like FileMaker (which by the way, have beautiful iPad templates), Mendix (big in the government space) and OutSystems (can compile to Java and .Net) stand out as ones you’ll want to consider. I would consider the latter as low-code and the others more on the no-code side.

RAD Platforms

For more complex applications, such as enterprise resource planning (ERP) or vertical accounting applications, you typically end up with RAD platforms or DIY (which we’ll discuss next). We have all heard of RAD environments that came up before the internet like Delphi, Powerbuilder, Uniface and FoxPro. And one that stands out as very well alive and kicking: Progress OpenEdge. Interestingly, these platforms provide us with the majority of our customer ISV clientele. Some of these platforms have slowly died or are dormant, and the applications built on them either need to be converted to something more modern and Cloud enabled, or the business wants to keep the database and business logic intact and simply wants a new modern front-end. The latter scenario is obviously less expensive and ensures a quicker time-to-market.

DIY Stacks

A DIY approach begins with picking a “language” (notice the difference between a “platform” and a “language”) like COBOL, Pascal, Fortran, and more recent PHP, Ruby on Rails and maybe even Node.js and the likes. And of course .NET and Java. Developers who are using this approach often refer to themselves as “full-stack” developers. They not only code the front-end and business logic by hand, but they also build and maintain all the NFR’s (Non Functional Requirements) by themselves. We see DIY approaches mostly happening in large companies and/or in off-shore scenario’s.

Modernize or Build Your App Servoy

So why use a RAD tool like Servoy to “save” your application? If you have a large or complex application (like an ERP app), and you need to modernize it, you probably don’t have the time to do a full rewrite in a DIY stack or you probably don’t have resources hanging around and available to do it either.

Back to the question, as a Servoy user, who IS your biggest competitor? The answer is not platforms or languages. You most likely juggle every single day with time-to-market and resource questions. You and your staff are obviously smart enough to build a “full-stack”. The question you need to ask yourself is what is the added value of having your own stack, the part that your end-user will never “see” or except by default. Our customers prefer to spend their resources on the part where they make their money, the front-end, the UX, the industry specific business logic, ie everything that makes their app superior and enables the end-users to do their job better, faster and more efficient.

My DIY story. My wife (and I) bought a new rustic wooden table the other day (Urban Home Outlet). I said: “honey, I can build you such a table for far less”. She replied: “I think you could, but it’s not gonna happen” 😉

We’ll continue this conversation in the second part of this series, coming soon to the Servoy blog. Tweet me if you know someone that wants to talk about DIY versus platforms, happy to chat.

How DevOps Avoids Cloud Pitfalls with Agile Development and Deployment

In the previous blog, we looked the advantages of cloud-based deployments. Today, we’re going to talk about what that really means, including the practical implications, the burden on your team, and risks that are involved.

It was several years ago when I first used the term DevOps in a software context. (In case you forgot, DevOps is a set of practices that automates the processes between software development and IT teams so that they can build, test, and release software faster and more reliably.)

So, when AWS was released about 10 years ago, I was optimistic, idealistic, and definitely unrealistic when I assumed that DevOps problems would never exist. Why? Because of cloud’s presumed unlimited scalability, availability, and guaranteed uptime, all of which would be available at a very low cost (and charged per second).

Impact of Cloud Downtime

Now that reality has set in, we know that a single customer with a single action can bring your entire app or website to a screeching halt. Furthermore, the impact extends beyond that one customer to all your other customers on that instance.

The same scenario is true for bugs and updates. In an on-premises situation, you might have one customer down. But in the cloud, everybody is down. This is where the phrase “continuous uptime” has a new meaning.

Downtime. It’s your worst nightmare, in many respects–it can cost you customers, credibility and revenue. You’ve experienced it yourself, when using Google Docs, Skype or Slack. And these outages happen to cloud-based apps, in spite of the fact that those companies have hundreds of people completely dedicated to avoiding downtime.

Growth Is Not Without Risks

As you grow larger, security risks will also likely increase. We’re not just talking showing the wrong customer data in a multi-tenancy scenario. (This actually happened to me last week with TicketMaster. While trying to unsubscribe, I was shown someone else’s customer data and was not able to unsubscribe.) But the bigger you become, the more of an interesting target you become to hackers and can be at higher risk for cyberattacks.

Another risk you probably haven’t considered is the “assumed” responsibilities your customer could blame you for. What if you are suddenly responsible from the electricity consumption of your AWS to the browser version and internet connection speed of your customer’s end user? We hear stories everyday of our customers’ users with broken IE browser versions from 2000, expecting our customers to fix it for them!

Then there are new data privacy and compliance regulation headaches. It is becoming a bigger responsibility where you, as an ISV, are now responsible for complying with all local rules and regulations. Take the GDPR in the EU, for example, with “the right to be forgotten” as part of the legislation. This “right to be forgotten” is not just an unsubscribe function–it means you are responsible for ensuring that all user information and all their transactional records are deleted from all your systems, including from your data backup system. Most ISVs don’t understand that even if you are not located in the EU, if one of your customer’s customer is, the GDPR rules must be enforced. Most ISVs don’t want to acknowledge this type of daunting regulation nor acknowledge that more of these global compliance mandates are likely to follow.

QAPaaS for Rapid and Continuous Application Development

All of these factors can have a significant impact on your costs. There are many known examples of where the “Holy Grail” of the Cloud turned out to be huge losses per individual customer instead of the dream of healthy recurring revenue.

Take a QAPaaS at IT

To try and mitigate some of the most severe issues we just described, you’re invited to try our QAPaaS stack. We designed it to assure a seamless process for continuous development-to-deployment practices, specifically to help ISVs like you with complex/large applications.
Contact me for a demo or trial.

Why Saas Is an ISVs Dream Come True and Devops, Not So Much

The first time I visited an ISV customer about 10 years ago, the owner showed me around the office and proudly told me about the 950 customers that ran his software. One of the larger rooms in the office had a CD replication machine. Years ago, back when CDs were part of everyday life, I had worked for ODME, a leading producer of optical disc machines, so I was taken by surprise when I recognized one in the office of an ISV!

I couldn’t refrain from asking: “What the heck are you doing with that thing?” (in a much nicer way, of course). He explained that he used it to make software updates to send to his 950 customers.  Ah, yes. Of course.

So, when you think back about those days and the excruciating manual work required to provide updates, it becomes crystal clear why SaaS- and cloud-based software is today’s holy grail for ISVs. Doing an update on a single server obviously beats shipping 950 CDs and then having to handle the 200 related phone calls from your (semi-annoyed) customers who are struggling to install it.

Let’s skip the other nightmarish part where as an ISV, we had to manage our own in-house server (farm), pull in an extra internet line as a backup, had hot-swappable backups and disks, and wrestled to come up with backup and recovery plans for power outages and any other disaster that might knock us offline. Let’s escape into the time machine and fast forward to today’s dreamy cloud setups.

Keeping the Cloud at Your Service

Nowadays, we expect the cloud to deliver. The ideal cloud scenario offers unlimited and variable scalability, is low-cost and extremely cost-efficient with a pay-as-you-use model. And regardless, running your application in the cloud is worth it because it’s always “up,” delivers stellar speed and performance, and offers continuous deployment of systems already in place. Truth be told, it’s more than a best practice for ISVs, it’s the only way for an ISV to run a business that makes sense.

But wait … this holy grail can quickly mutate into a nightmare, maybe even worse than what we had before. In the next blog we’ll talk about what can (and will) happen, how to deal with some of these scenarios, and what you should expect from your platform vendor.

Kicking Off Your Project or MVP

After reading our recent blog posts “Why Not to Start App Dev with UI” and “Developing Apps in a Vacuum–Sound Familiar, we are going to assume you’ve had a lightbulb moment about rapid application development (RAD) and are now a believer and want to try an MVP approach. If so, this means you’ve built the business case to modernize your complex business application and likely plan on taking it to the cloud as a SaaS-based application and improving the user experience.

Why You Love an MVP Approach

As a refresher, here is OUR definition of MVP (Minimum Viable Product):

M: As small as possible
V: It has to actually work – it’s not just a prototype or pilot
P: It has to be commercially viable, generating revenue or creating value for users immediately

The MVP approach supports your commitment to being cost-efficient, helping your organization expand, and attracting new customers with your new, appealing enterprise app. You understand the value behind creating an MVP, where you and your team create the most viable application quickly, with lots of user testing and iterations–all under the auspices of agile development sprints, where it’s okay to fail as long as you fail fast. This agile approach lets you deliver what stakeholders need and want, even as those needs evolve to keep pace with the marketplace. Now that you fully understand why this kind of approach makes sense–you and the team are ready to go for it.

The Elephant in the Room

But the question is where exactly do you begin? How do you tackle a big project like this and reduce the risk? You might as well ask, how do you eat an elephant? The answer–one bite (or byte) at a time. In other words, you slice it first into more manageable sizes, then you cut the slices in small pieces, so you can consume each piece one by one. In the case of a complex business application, this can be module by module or by sets of functionality. However you decide to go about it, you’ll want to pick the approach that offers the most value. This means you’ll need to assess which approach best aligns with and supports key business priorities.

Back to the immediate problem and that is deciding which bite of the enterprise application elephant to start with. Questions to ask yourself: “Why are we modernizing again?” Next, ask “Which is the fattest part, the part that I can resell the easiest?” Or “Which part is most unique?” or easiest to “chop off”? Other questions you should be asking is “How attractive is my mud-covered grey elephant?” “Is it possible to create a fit-for-purpose pretty pink elephant?” “One that is easier to transport to my customers to mobile-first?” “One that is totally UX focused?” “One with less functionality but is ready to go, can be configured by the customer itself, and doesn’t require consultants to implement?”

The Elephant in the Bathtub

Consider starting with a small floating elephant “app” in the bathtub. Then, start pumping it up by adding functionality, quickly, every step along the way. And eventually, you will end up with a beautiful, clean pink elephant that lets you retire the ugly grey one. Obviously, the project management aspect of large and complex transitions comes with a great deal of risk. For it to be successful, you have to manage it well. As a developer, it’s tempting to drive this project management process based on technical decisions. But for baby elephant projects to survive and thrive, you need to align your approach with business drivers, the need for innovation, and always start with UX first.

Appsurance Program

Save the sinking elephant! From a project management and risk reduction point of view, ask about our Appsurance Program. Even if you aren’t using the Servoy platform to modernize your application, you need a solid system in place and probably new processes. We’re here for you and want to share what we’ve learned during the previous 15 years, through many modernizations, rewrites and projects to help you avoid false starts or even worse–project failures.

Learn more here: Appsurance Program or contact me at [email protected]

Developing Apps in a Vacuum (Sound familiar?)

When I started my first software company in the midst of the dot-com boom, a product comparison kind of service, we needed to build the application from scratch and hired a bunch of the smartest software developers anywhere. Long story short, after 9 months we had had 6 rewrites of the backend infrastructure and not much to actually show for it, let alone a website or application we could demo to investors. This is, by the way, when I met Jan here at Servoy and his team who came in and saved the day.

How an MPV Can Save the Day

If I only knew then, what I know now.  In hindsight, I would have given gold for understanding the concept of a minimum viable product or MVP (to be used ideally in combination with a UX-first approach). The way it works is like this: Instead of going bottom-up and building the complete infrastructure first, we now recommend our customers to focus on the smallest possible minimum viable product we can help them build. This MVP should be commercially viable (for example, a very light-weight version of their app), or sometimes it’s focused on dashboarding, a “sexy” visualization tool to sell to the management level. In any case it’s an invaluable tool that collects immediate feedback from users. 

Light at the End of the Tunnel

Modernizing a business application the traditional way feels like waiting and looking for light at the end of the tunnel–a long, dark tunnel. One that goes nowhere fast. And then, when your business application is finally ready, either customers react differently than you had hoped, or new competitors with “point-solutions” pop-up and ruin the launch.

Don’t Make Us Beg

Please…whatever you do, give the MVP a try first. We get it here at Servoy. We know you can’t launch until your product is completely ready, every module with all its beautiful functionality. This may be true for your existing customers, but not necessarily for new customers that may have a need for a less complete app. In any case you’ll need feedback from users sooner, not later.

Up Next

Your application is huge and complex. Stay tuned for the next Servoy blog post where we talk about how to “eat the elephant.”

Happy coding!

One Big Reason Why NOT to Start App Dev with UI

You’re excited about your amazing idea to modernize your complex business application. You’ve scoped it, you know that it will solve a problem for your target users and it might even make you more competitive. You’ve identified your UI libraries and are ready to get started. Right?

Not so fast. Let’s take a step back and go a little deeper and think about what will make your application unique and better. What will make users want to come back to it again and again? What will make it stand out against the competition? You already know the answer, which we explored in our previous UX-related blog posts (blog.servoy.com).

Why selecting UI frameworks @ the start = no bueno

An easy, intuitive user experience is essential to making your application a success. In large, established enterprises, this philosophy is shepherded by a product manager, but in smaller organizations, developers can get carried away by looking at the process primarily from a development perspective. Maybe KendoUI is calling your name. Maybe it’s Twitter Bootstrap or Google Material Design that you prefer. But you must resist.

How an MVP Becomes Your Most Valuable Asset

What better way to put your users first then to let them drive how the application evolves, to let them help create the application they need? The best way to do this is through starting with an MVP, or minimum viable product, build it in an Agile way, with constant end-user testing, exposure and feedback. Think of it as efficient crowd sourcing to build your application, a way to enable rapid application development, and a product that is, by design, successful. Stay tuned for more on MVPs in the next blog post.

Here’s What Not to Do

Take a look at the video about “Best Practices: UI/UX Modernization,” which shows you where NOT to start in the application development process. There are plenty of similar recommendations from various industry experts to support this philosophy. Additional references about UX first as a best practice are included below.

Learn More about a “UX First” Approach

Here are additional sources around this approach:

Want to learn what this would mean to you, Get a free UX consult here.


Three Ways to Deliver a Better User Experience (UX)

Have you noticed a common theme in the last several Servoy blogs (“It All Begins With a Delightful Customer Experience” and “Driving the App Dev Vehicle Top-Down”)? They both focus on a single topic: the customer experience. This strategy of focusing more on helping the customer, not selling the product or features, has been around since the beginning of the digital era. But building a beautiful user experience into a business application—easier said than done!  

How to Meet Today’s User Expectations

For ISVs and developers who are building enterprise applications or modernizing complex business apps, the end product should have a focus of providing a smooth, seamless, productive, and intuitive customer (or user) experience. Today’s consumers of applications are sophisticated, with high expectations about the look and feel and the experience. The baseline for this experience continues to evolve, making for some tough competition. But what exactly do we mean when we talk about user experience. Do we mean an attractive UI, easy navigation…or optimizing productivity—or all three?

Defining and Designing Your UX Strategy

The secret to creating a great UX all begins with a well-articulated UX strategy. You might assume that a product manager (PM) could create and execute a UX strategy because their objectives are similar, with one big difference—UX strategy has a laser-like focus on the user experience and productivity compared with the PM’s focus on the product’s business value or profitability. The roles of UX specialist and PM are also alike in that both are concerned about whether the product is technically feasible, but the UX strategy takes a granular look at how a user responds to and interacts with an application. This includes an attractive user interface and intuitive navigation with the end goal of optimizing user productivity.

User experience strategists rely on the principles of UX design to help understand, describe and document the ideal experience. UX strategists communicate the target experience to the wider organization through concept models, diagrams and other abstractions. They oversee the final execution of that vision, to ensure the final output meets the stated goals. To some extent, all good designers do this. However, UX strategists focus only on this aspect, disregarding areas such as the information architecture. To sum it up, UX is a specialized field of study that requires education to become certified so don’t make the mistake and think that your product strategist (or even a CTO) can do what a UX specialist does.

Roadmap for a Successful UX strategy

The following are three key recommendations that will help you succeed in bringing your revamped or new business application to market better and faster. Your goal should be to invest in understanding how your users can benefit optimally from your application, whether it’s brand new or a modernized version.

To understand your users:

  1. Contract a UX specialist—Work with a UX specialist before you begin the application development process. This will be an upfront investment but one that pays high dividends by ensuring your application lives up to its potential. As mentioned earlier, this professional is specially trained in the principles of UX, a specific discipline that goes beyond graphic design and marketing.
  2. Do a UX study—The specialist will sit next to your users and observe them to understand the tasks they need to perform and the most productive pattern to help accomplish them.
  3. Create the ideal path forward—The UX specialist will provide feedback with clear direction on how to create the optimal user experience.

Stay tuned for more

In the next post in this series, we’ll talk more about UX design and why “failing fast” and using a minimal viable product (MVP) approach works best for rapid application development of business applications.

Recommended reading:

ROI of User Experience March 2017, Tech Republic

Get Your Free Trial of the Servoy RAD Platform Now.

It All Begins With A delightful customer experience

I’ve been in a leadership role at a small software company for longer than I care to admit.
To be honest, if you had talked to me several years ago, I would have bet my Mini Cooper on the fact that technology—specifically software development tools and approaches, would have evolved by now to be less complex. And in some ways, it is. With today’s low-code and rapid application development (RAD) technology platforms, application development can be easier than ever. But easier for the developer, not necessarily for the end user.

As I mentioned in my previous blog post, a common mistake that many developers make is to get caught up in the features and functionality of a program and forget to have empathy for the end user and their experience. The development process often starts in a “bottom-up” manner, when it should start with the customer, defining who that is, and their objective. That adage, “It’s all about the customer” remains true today.
As a software vendor, my company—like many ISVs—is challenged by increasing competition, diminishing resources, and ever-higher customer expectations around the end result. But so many technology products miss the boat on this. Let me give you a few real-world examples of what I mean.

Dear *[FNAME]*

Recognize that? One recent—and very common—example just happened at my own company. My demand generation team was using a new-to-us tool, the MailChimp app, to email our monthly newsletter to our customers and prospects. Cutting and pasting the identical command from the source code in MailChimp *[FNAME]* into the next template did not work, even though logically, it should have. To the human eye, the code appeared identical and the command should have pulled in every recipient’s name from our database. As a result, this entire series of emails went out with this salutation: Dear *[FNAME]*

Enhancements, Innovations and Upgrades Can Come at a Cost

When applications are continually enhanced and upgraded, the user experience can have a dramatically negative impact. Take Skype, for example. As an end user, every time there is an update, I am forced to get used to an entirely new user interface. Although I’m well-versed in technology, it’s annoying when I end up fumbling trying to figure the new way to share my screen during an important customer meeting. I’ve also seen a lack of integration between the mobile app and the laptop version causing instant messages to be lost deep into cyberspace, and co-workers getting very mad at each other in the process … Facebook is another example of how an “upgrade” can change how users interact with other users and the application itself—and they’re not shy about complaining about it.
If you look at more sophisticated programs such as Google Analytics, it takes complexity to a whole new level. If you are doing anything digital (which, of course, you are), you need GA. It gives you essential information about (you guessed it!) your customer’s digital behavior. The downside is that you almost need an advanced degree to navigate within the application, as well as decipher the meaning and nuances of its metrics. Even for the tech-savvy among us, GA is not for the faint of heart.

5 ways to create a great UX

The terms user experience (UX) design and user interface (UI) design are often used interchangeably, but they have different meanings. UI design focuses on what the interface looks like and the optimal arrangement of elements on the screen. UX, on the other hand, focuses on empathy for what it feels like to interact with and use the software while getting your work done in the most efficient way.
Here are 5 ways you can help create a positive UX:
1. Understand your user and their goals (Duh!)
2. Eliminate technical issues
3. Focus on sub-second performance and quick interaction
4. Simplify navigation
5. Use recognizable icons consistently with intuitive paths

Regarding bullet 1 above, about understanding your user, you should consider doing it the way Jonar redesigned their app. After every sprint, they put a novice user in front of what they built and instructed them to place an order or do some other task without any help or instructions. If the user could not do it the sprint failed.

Work Smart, Code Less

The good news is that if you pick a RAD environment you’ll have more time to perfect and excel in UI and UX. While using a RAD, you don’t have to build and maintain a stack, which frees you to focus on where you add value – the UX side of your app.

Stack the Odds in Your Favor

Our goal is to keep it simple but at the same time, keep the customer experience your top priority—and we help you keep it simple, so you are free to do more meaningful activities at your organization. If you want to learn more, feel free to message me directly or visit the Servoy website.

Driving the App Dev Vehicle Top-Down

It’s All About the User eXperience

My team and I are constantly talking to our customers about putting their customers first. Because when it comes to developing or modernizing an application, we all know that in today’s digital era, you need to put the user first. Industry advice repeatedly recommends Start from the front end, and build from the “top down” and you can hear the words echoing down the internet pathways.

Not surprising, is it? This coming decade is often labeled as “the decade of design” with the increasing digitization of products and services–and the need to make them consumable, visually appealing, and user-centric. Designing with user experience (UX) in mind is simply good business.

Backing Yourself Into a Corner with a Backend-First Approach

But as a developer, it is tempting to jump right in and build “the app for that” yourself, from scratch. You take pride in your developer prowess. And you appreciate the power of your backend coding and its capabilities, so that when you get to the finished product and look at the “front end” user interface, you lean back, survey your handiwork, and smile with satisfaction. Your work here is done, right? Everything works well and makes sense to you, because you’ve been working with the core technology for so long.

Alas, it is all too easy to lose sight of this. In fact, recently at Servoy, we made this mistake when building our new website. We wanted a sexier website, one that was easier to navigate, and one with a more appealing user design. (Check it out and see if you agree we succeeded: www.servoy.com.) We are smart, we said to our collective self. Let’s build it ourselves, from the bottom up. We had access to WordPress, an industry-proven CMS. So pushing the website live was no problem. And superficially, we did accomplish our goal fairly quickly and inexpensively.

The website looked great. Everyone loved it. Big thumbs up. But wait. There was one big problem we discovered a couple weeks after launching the site. We forgot about one tiny little user, Google! Our user interface was fine, but some important SEO-related tags were omitted in the source code. Actually, ALL the SEO-related tags were left off and the website had turned into a maze of redirects. As a result, the visits to our website plummeted and we were left scratching our heads. Several weeks later, we called in SEO experts for an assessment. Two months later, we confirmed that the problem was fixed. SEO is on track. (The happy ending is that site visits ARE on the rise.) But all of this could have been avoided if we had started from the top down, with the end-user and Google [wink] in mind – and enlisted the help of experts.

Modernize Complex Biz Apps with a Top-Down Approach

The point is this: to do things right, you need to start with from the top down. This logic even makes sense when calculating deadlines, for example. You start at the deadline and work backward with estimated times of subtasks.

At Servoy, we help you easily and quickly modernize your complex business applications with a better user experience, which is a win-win for you–and for your customer. Your customer gets the app in their hands quickly and you get the app to market faster. CSAT is high all the way around.

By the way, stay tuned for more insightful articles from me coming soon–about rapid application development platforms and more!

Follow me on Twitter at @YBOOM or connect at www.linkedin.com/in/yvoboom

Servoy featured at ProgressNext modernization and UX session

During Colleen Smith’s main product session at ProgressNEXT 2017, Colleen interviewed John Harlow, VP Professional Services at Progress and Jan Aleman, founder of Servoy. The interview and discussion involved the modernization of complex Progress applications, and underlined the importance of the delivery of a great User Experience. It’s a brief interview but it lends insight into what is happening with modernization in the Progress world. Progress’s approach to modernization greatly reduces the risks experienced by other methods while delivering a superior User Experience.