Considering PaaS? Listen to Mick Jagger

In the last five years, federal clients have embraced infrastructure-as-a-service  and software-as-a-service products to support ongoing cloud mandates.

For all their complexity, these solutions are relatively simple to implement because they are either unseen by the end user (IaaS) or driven by agency policy that dictates how solutions will function (SaaS).  Either way, the need for stakeholder management is limited. This is not the case with platform-as-a-service products, however.

While IT professionals have historically written code to support implementations, PaaS works best when product functionality is configured to meet the requirement. This creates problems when stakeholders want to replicate the way business is currently conducted because such functionality may require complex, custom coding.

Platform providers, like Salesforce, have an army of developers, QA staff and testers who ensure their product releases function flawlessly. Aggressive customization in PaaS creates significant risks -- risks that custom code won’t work with an upcoming release and risks of escalating operating and maintenance costs to sustain the custom code. Wasn’t avoiding those risks and the point of the cloud in the first place?

With platform products, IT managers must aggressively control stakeholder requirements to maintain the platform’s integrity. My client advisory rule of thumb follows my favorite Rolling Stones song:

You can't always get what you want
But if you try sometimes well you might find
You get what you need

In large organizations, any level of change is disruptive, and major system changes are often seen as a threat. Some of the common pushback I’ve received includes “We don’t do it that way,” “Legal said…” and my personal favorite, “We’re different.”

Helping stakeholders understand the difference between what they need and what they want is a challenging task, but it is directly tied to a cloud project’s success. Here are some of the approaches I have found effective with PaaS implementations:

Educate key stakeholders early. PaaS products have been constructed to meet the dynamic needs of commercial enterprises, which are often five to 10 years ahead of public sector efforts. This means that they meet the majority of stakeholder needs out of the box and offer additional functionality. 

Persuade stakeholders by identifying functionality that makes their lives easier with the product they have already purchased. Needs and even wants may even be addressed with  out-of-the-box capabilities.

Include product and solution architects in stakeholder discussions. PaaS product architects are essential to the design and ongoing “what if” analysis that is performed as part of problem solving. They are valuable experts who can help explain the product’s capabilities, design alternatives and cost options. In conversations with stakeholders these experts convey confidence in the product, expertise in having seen the problem before and understanding of a vast array of designs. Include them in design and implementation discussions to help convey how the solution can fulfill needs and wants.

Establish a ‘no-code’ policy up front. Establish a design policy that pushes architects to maximize the product’s functionality without coding. Equally push business users to modify their business processes to meet out-of-the-box functionality. A no-code policy forces all sides to work together and compromise on design. It may take longer in development, but the across-the-board benefits are felt over the long term.  

If there’s specific functionality that is absolutely required, it can be custom coded --  the world won’t come to an end. Just remember that true need in federal agencies can be defined by regulation and policy.  Everything else is a want … and you can’t always get what you want. 

Establish a trade-space to discuss options. PaaS solution design is not black or white -- it’s an ever-changing shade of grey that is influenced by regulatory changes, stakeholders, politics and personalities. Create relationships with stakeholders and have a constant dialogue with them about their needs and what product options are available.

Most business and program owners I’ve worked with are unhappily using outdated technology to support their work. A trade-space where options can be openly discussed and considered is likely to increase  the level of engagement.

Use independent software vendors. ISVs provide solutions -- often built on the PaaS platform -- that provide additional functionality without custom coding, which lets IT managers purchase specialized functionality that makes the PaaS product even more robust. Some of the functionality I rely on ISVs to provide includes document generation and electronic signatures -- functionality that is fundamental to solid government-to-citizen engagement and ones that I can implement rapidly with PaaS solutions. Stakeholder needs and wants can often be met with ISVs for small, incremental costs. 

The path forward

Out-of-the-box functionality, complimentary vendor tools and limited O&M costs makes platform products an obvious choice for many federal legacy systems. Getting stakeholders to embrace the change these products create is difficult, but not impossible.

IT managers who guide the transition will likely, as Mick Jagger sings, get a “fair share of abuse.” However, educating stakeholders to what PaaS solutions provide can overcome initial obstacles. Expert advice from product architects can maximize the platform’s potential, and a continuing dialogue led by a trusted IT advisor -- solidifies individual stakeholders into a team.

These approaches don’t guarantee a project will be a success, but they help address many of the common challenges faced during PaaS implementations.