Recommendations for Improving DataPower Developer Productivity

Harder, Better, Faster, StrongerDaft Punk

Introduction

When a device is started for the first time, the only interface that is enabled is the command-line interface (CLI) accessible via a direct cable connection. While all configuration changes could continue be made via this interface, it is not user-friendly. Therefore, a second interface, the WebGUI, is enabled.

The WebGUI provides a browser-based interface where administrators can click and drag to make configuration changes. It is sufficient for initial deployments, but not as more demands are placed on the environment and more projects become interested in the technology. The initial ‘good enough’ state soon turns into a ‘not enough’ state as the development team is unable to keep in front of the incoming tidal wave of changes. Project deployment times increase, developer stress increases and the only solution is to either hire more developers or to turn away viable projects. Both of these bring substantial additional costs to the enterprise.

This article will discuss tips to improve developer productivity and allow the team to work smarter and more effectively.

Automated Deployment

A typical DataPower installation will have between 2 to 6 environments on which a solution must be deployed before promotion into production is allowed. These generally are: development (DEV), System Integration Test (SIT), User Acceptance Test (UAT), Business Acceptance Test (BAT), pre-production (PAT) and production (PROD).

For each environment, the solution needs to be replicated from the previous environment and modified with environment specific updates. This includes new URLs or updates to whitelists for new certificates.

To complicate things further, there can be multiple devices that comprise each region. Typically, PROD is implemented as 4 devices, two per datacenter. A full deployment could require the solution to be installed on 10+ devices (2 per environment, and 4 in production). After all that work, the project may find a bug and need to redeploy from DEV all over again. If this process is manual, even a 10 minute click-fest per device can become prohibitively time-consuming.

Every manual deployment introduces the potential for a mis-click to go unnoticed and the result is an environmental mismatch between regions. These defects are nefarious. They impact unrelated projects at random points in their development cycle. The project and development are left clueless as to why the project throws errors after promotion into a new environment. Time is spent to identify and correct the issue.

Every mature technology requires an automated deployment process. A developer should be able to run a script to promote the solution into the next environment. The script turns a deployment task from minutes (or in some situations, hours) to seconds. This frees the developer to perform more higher value work.

Platform Patterns

A DataPower environment is typically brought into an enterprise by the infrastructure architects to implement a specific set of patterns. These patterns should be identified and broadcast to the solution architects. Requests for known patterns should then have an associated rapid turnaround time for implementation.

This idea is akin to giving a menu to a customer when seated at a restaurant. Projects should be encouraged to order off the menu as much as possible, as this leads to lower costs all around.  The restaurant has already taken the time to prep the food to quickly cook the dishes based on the menu they offer. The same can be done for DataPower solutions. The incentive is that ordering off the pattern menu is cheaper and faster to prepare/implement.

Projects that meet the pattern requirements shouldn’t have to pay for a chef (SME) to first listen to a description of the order by the customer (requirements), head over to the grocery store to buy the components (research technology) then sit down figure out a recipe (design). Yet, there are customers that treat every order as if it requires bespoke customization.

Once the DataPower patterns are established, the team should immediately create a reusable template of the pattern. The project implementation tasks now become template customization instead of custom design. After a few of these deployments, the speed at which the team is able to deliver will increase substantially.

Utility Scripts

When working in the DataPower environment, there are bite-sized tasks that need to be carried out a fairly often. These include

• Enabling or disabling the debugging probes
• Flushing the document and stylesheet caches
• Restarting a domain

These tasks require a few mouse clicks to perform and need to be done pretty often during the development cycle. As an example, enabling a probe would require someone to:

• Log into the device
• Switch to the Domain that hosts the solution
• Click the Troubleshooting Icon
• Click the Enable Probe button on the appropriate service

These are low-value time-consuming tasks that are repeated multiple times per day, even more often when a transaction can be routed to multiple devices in a region.

A suite of these tasks should be scripted and become a core part of the developers toolkit.

XSLT Development Environment

DataPower leverages XSLT as the technology to transform documents. While they can be created by hand in a basic file editor like notepad or in DataPower itself, it can be very error prone. The lack of a built-in parser and modern IDE syntax highlighting result in wasted developer time. The developers time is spent on mundane technical tasks that don’t provide any direct value to the solution.

Investment in a stand-alone XSLT IDE is a must for a productive DataPower development team. There are many tools out there and they should be evaluated by the team to ensure that the XSLT generated is readable and the source maps artifacts can be safely stored in the configuration repository.

Reusable Configurations

This is a similar to the platform patternize recommendation above, but applied more generally.

In a DataPower solution, there are a suite of configuration objects that are static for all solutions in the environment but need to be recreated every time. An example would be an SSL Validation or Identification Credential.

On top of that, there are common best practice settings that should be applied for every object. An example of this is the backend server timeout duration. The default values for objects in DataPower do not necessarily reflect the best practice settings for the enterprise implementation. Differences between the proper setting and the default setting is an opportunity for bugs and platform instability.

Typically to implement these best practice settings, the developer will work with a process document to configure these objects every time they create a solution (or worse, they forget and your solution is now missing critical configuration settings). This is a repeated waste of effort and a constant risk to quality.

DataPower experts shouldn’t be wasting time recreating static configurations.They should be able to store and then import the object from the best practices repository. Given this base is a known good state with proper configuration, the project can use this base to build its custom functionality.

Self-Service Information

One of the biggest drags on the developer productivity are ‘quick questions’ that come directly from the project. These consist of constant small information gathering questions such as:

• What certificates does an endpoint accept?
• What is the URI for a service?
• What backend URL is a service pointing to?

These questions all require developer time to answer by clicking in the GUI and copy-pasting configuration settings back into the requestor.

There’s no reason why this information can’t be automatically provided via a self-service web page. When there is a standard pattern for solutions, there is also be a standard location where this requested information is stored. This means that the request can be automated.

The user should be redirected to the self-serve site where the information is contained. This frees up substantial amount of developer time by preventing these configuration queries from occurring in the first place.

Conclusion

A DataPower environment begins at a state where manual process is the standard. If the environment isn’t pushed towards improving developer productivity, then costs will increase and quality is put into jeopardy.

This article discussed recommendations that can implemented to ensure the DataPower environment continues to innovate and can keep up with the growing volume of projects that wish to leverage the platform.