The definition of the word ownership has varying meanings across organizations, but there is always a group that retains control of the technology. It’s typically the group that sponsored the adoption of the technology and owns day-to-day support of it. But, sometimes, the technology initiative began with an Enterprise Architecture group that hands of ownership of technology.
Last week, I wrote a post about the Roles and Responsibilities that I have found need to be addressed with DataPower. In that post, I mentioned I’d be talking about what groups those roles should belong to in a future post-here it is.
I believe a healthy conversation about who will be responsible for which aspects of DataPower is the starting point on the first day of a DataPower deployment project-if it hasn’t already occurred. It will save many headaches down the road. As I mentioned in the Roles and responsibilities post, DataPower blurs some traditional lines. So, it can create confusion early on.
I’ve been in shops where the Information Security group feels they should own DataPower because it is a security appliance, the network group believes they should own it because it is just a router, the middleware administrators feel they should own it because they have to support it, and the development teams want to own it because they’ve got a lot of stuff to implement on it. I was in one shop where the network team was given responsibility for DataPower. Things were great for an hour or so. After we finished the initial bootstrap of the appliance, we setup the first service. About twenty minutes into that, the network guys decided they didn’t need to be involved in DataPower anymore.
I believe the correct answer to who owns DataPower is answered by appropriately defining the roles and responsibilities needed to support the appliance, defining which team owns each, and establishing standards and design patterns that all teams agree to abide by. Or, at least something close enough to that so that the technology can function on a day-to-day basis.
The DataPower Administration role typically goes to the same group that support JEE Application Servers. The DataPower Development role is either a new team composed of people with the appropriate skill sets or lives in an existing development team. The Network Engineer role is typically folded into the DataPower Administration role. Though, IP management is usually done within the network group; depending upon the architecture, a DataPower appliance may use many IP addresses and be connected to numerous network segments. The Security Engineer role will either go to the existing Information Security department or be folded into the DataPower Administration role-it depends on the existing Information Security standards. Key Management, account management, or the like may have specific rules that must be enforced. Likewise, be aware of other existing standards that may impact how roles and responsibilities are handled.
I’d recommend a centralized DataPower Development group whose members are assigned to projects as work comes along. This facilitates the implementation of adherence to standards. Likewise, being the only DataPower person on a team of fifteen Java developers can get a bit lonely. Again, it depends on the organization.
The DataPower Architect role may be filled by an Enterprise Architecture group or a technical lead in the DataPower Administration or DataPower Development group.