Dan Naselius is vice president of HumanTouch, LLC

In an era when U.S. agencies are being told to do more while spending less, they're increasingly turning to Platform-as-a-Service (PaaS) to support business applications.

Moving development processes to PaaS, in fact, would save the government about $20 billion annually, according to industry research. Agency users now taking advantage of PaaS are spending 47 percent less time on software projects than they did previously. Overall, the federal PaaS market is expected to grow to $1.25 billion by 2018, up from $700 million this year. That's 15 percent in annual growth.

There's a surge in demand because many decision-makers are eager to explore options in "as a service" IT delivery models. PaaS represents a bridge between Software as a Service (SaaS) and Infrastructure as a Service (IaaS). It allows IT departments to fast-track app deployment with platforms that are pre-tested and ready to scale as needed. Thus, these departments emerge as the one-stop service/app provider shops for their users, reducing dependence on custom development and systems integrators, and containing in-house costs.

Yet, even with the anticipated rise in the presence of PaaS within the public sector, barriers remain. More than half of federal IT executives say they're taking a "get the toe wet" approach here, using the cloud for only a limited number of specific apps. Among the reservations: About one-third question the performance of cloud services, and one-quarter have concerns about the technical aspects of integrating cloud apps or infrastructure within legacy systems.

Such sentiments about perceived obstacles are perfectly valid. But we've found that they're easy to overcome – as long as you're aware of the following three classic mistakes which organizations commit in adopting PaaS, and how to avoid them:

Mistake #1: You Force the Platform to Fit the Application

It's a cardinal sin to turn a rich, interactive platform into a coding platform. But we see it quite often. Those wanting to move to a PaaS model focus on moving the app to the platform, as opposed to re-envisioning the app to the platform. They seek to apply what they know to something new and unfamiliar.

This undermines an essential value point of PaaS. You end up with an app that requires significant custom code and that is expensive to develop and maintain. It's also difficult to use, since it's been "shoehorned" into the platform, as the app wasn't created with the platform in mind.

PaaS shouldn't be about coding. It should be about configuring existing platform features. That's why we recommend you start with the platform, not the app. Find a platform that's best suitedfor your needs, so you'll invest less time and expense into making relatively minor configurations to make it work for your users. Then re-envision and re-architect your app leveraging the power of the platform.

Mistake #2: You Try to Force the Legacy AppDev Model

Another critical mistake we see is sticking to the legacy AppDev model while designing and building your app on a platform. It's a different world and the waterfall model is long dead. The nature of PaaS lends itself to speed and agility

Instead of investing months and months in requirements gathering and prototyping, PaaS allows you to rapidly prototype your app and get critical user feedback along the way. This significantly condenses your timelines as you can show the customers a proof on concept to flesh out the most critical requirements, then rapidly configure the platform and get the solution back to the users to validate it meets the business needs. Then move to the next set of requirements and on and on. This agile model results in a better end product, makes your users happy, and gets the app in the hands of the users much faster.

Mistake #3: You Fail to Collaborate with Business Users

Ultimately, the business users are going to determine the success or failure of PaaS. If you proceed with the transformation without getting their input every step of the way, you'll risk falling short of expectations/requirements, which puts the entire PaaS model at risk.

Once again, we encourage a proactive route. After you've shown what a cloud platform can do for common workloads, sit down with influential users and collaborate upon a thorough, detailed summary of what PaaS should "look like." Because PaaS is already capably fulfilling the basic workload tasks, these influencers are likely starting to come up with creative and even inspired ways to take it to the next level. If you align their vision with the technology, you'll increase the chances for successful outcomes. The entire idea and power of PaaS is to allow the business users to drive the solution, which ultimately results in a better solution and higher adoption rates.

We understand that – anytime you introduce "new tech" – you're going to encounter some pushback. But if you take a proactive, well-planned approach to PaaS, you'll minimize the misgivings, swiftly converting skeptics into "true believers." They'll see that IT is supporting a wide range of performance-fueling apps faster than ever, and that, thanks to cloud platforms, "more with less" isn't so onerous after all.

Share:
In Other News
Load More