DataPower is a weird (but, wonderful) beast. It has a tendency to break some of the traditional IT silos that develop within infrastructure groups. That can lead to a lot of friction and amusing arguments in which everyone is simply talking past one another. In this post, I want to describe the roles and responsibilities that are required to be able to support a large DataPower deployment.
I’m not going to try to answer what groups should own this role within an organization in this post-that’ll be a future post. But, I want to describe the needed roles.
The following table describes the roles that I see needing to be filled in a DataPower shop.
|Tasked with operational support of the appliances. Very similar to a Web Administrator role in the JEE Application Server space(WAS, JBoss, Weblogic). This role is typically responsible for promoting changes created by DataPower Developer through the environments and into production. This group is responsible for maintaining system availability, troubleshooting problems, and often considered the “owners” of the technology. Connectivity configuration such MQ Queue Manager objects, WSRR Server objects, etc. are sometimes owned by this group. This role is generally responsible for low-level services such as DNS & NTP configuration. This group will generally do the initial bootstrap on a new appliance and firmware upgrades.
|This role is responsible for creating DataPower Service Objects, building the applications, defining policy, implementing Service Mediation logic, implementing error handling/logging/reporting, writing stylesheets, etc. Often an organization will need to step back and evaluate where this roles’ responsibilities end. For example, should a DataPower Developer be responsible for creating the MQ Queue Manager objects? Should the DataPower developer be responsible for building AAA objects? The answer in both cases is that it depends.
|Responsible for configuring the network interfaces, VLAN Sub Interfaces, IP Address Management, and static routes. This configuration requires close coordination with the DataPower Administrator. Often this role is rolled up into the DataPower Administrator role.
|Responsible for configuring RBM access control for DataPower users. Responsible for key management on the appliance. Sometimes responsible for application level security policy-ie, creation of AAA policies. If the appliance has an HSM module, this role would be responsible for the initialization and maintenance of the Hardware Security Module. Sometimes, this role is rolled into the Datapower Administrator role-depends on the organization.
|This role is responsible for defining the macro architecture within which DataPower is a component as well as the internal DataPower architecture or design. Responsible for defining standards in conjunction with the DataPower Developer and DataPower Administrator roles. This role should be evangelizing the role of DataPower as an ESB or XML Gateway (or other) within the organization.
Depending upon the organization’s size, these roles may be combined to suit the needs of the organization. In a small shop, they may all be the same group. The development role may be split between various teams or it may be centralized.
One of these roles will need to have physical access to the datacenter. DataPower may be robust, but like every appliance (and every piece of technology), every now and then it needs to be power-cycled.
The DataPower Administrator and DataPower Developer roles have some interesting characteristics. In order to be successful in either of these roles, the resource needs to have an eclectic mix of skill sets that lie somewhere between a Unix System Administrator or Network Engineer and a Java Developer. This resource is comfortable with the numerous configuration details associated with an appliance, but also understands the various XML & WS-* specs that DataPower supports. Likewise, this resource needs to understand networking concepts and be able to troubleshoot network related issues-not solve them, just narrow down the problem. This unique combination of skills needed to support DataPower introduces the beginnings of the challenges encountered trying to support SOA appliances.