A funny thing happened at the F5 booth during SAP's TechED 2008 last week (6,000+ SAP Developers in Las Vegas, Nevada for the entire week of September 8th, 2008), several groups separately asked me how they should handle the politics of administration and system management: "how do I grow my local traffic management solution, add web acceleration but not give up the control I have with my current software based solution?"

It's a great question for me because I'd drafted this post about User Roles and Partitions last month and I didn't know exactly how relevant it was to our users.  As I came to find out, it's quite relevant.

The concept of a User Role and Partition will be familiar to anyone who has worked with delegated administration.   Entitlement of responsibilities are restricted by job function, thus a developer can have one level of access and a network administrator, another.  F5 extends this paradigm to the concept of Partitions, which are segmentations based on application function.  For example, in a company with both SAP Portal and Microsoft Sharepoint, an SAP Portal group would have one partition and the Microsoft Sharepoint group would have another, neither with the ability to change the other's configuration.  All of this is done through the standard F5 web-based interface.

Agility is maintained because the subject matter experts on a particular application are allowed to execute their portion of the tasks directly and without having to delegate their expertise to another set of administrators (network admins).  Network administrators on the other hand can sleep well at night knowing that system administrators can't take their boxes down.

In the case of SAP, the world's leading provider of business software solutions, the question arises from customers who want to augment or move away from SAP's Web Dispatcher (SAP's software based technology for server selection and load balancing).  Web Dispatcher is often managed by application administrators and introducing F5 equipment seems like a loss of control and ultimately agility for these administrators that are used to doing load balancing configuration for themselves.

For those not familiar with SAP, the software is all about speed and time-to-delivery in the application world.  In many cases a new SAP application can be developed and deployed in just a few days.  But the network administration portion of it can take weeks to complete in the traditional IT organization where requests have to be filed, meetings held and configurations vetted out.  There are many good reasons for this traditional model, including preserving the overall uptime and stability of the network and not impacting other applications, but it's not the only way to achieve those goals.

To summarize all of this, let's walk through an example.  Here we have an organization with BIG-IP Local Traffic Manager (LTM)  and three stakeholder groups, network administrators, SAP Portal developers/administrators and SAP Business Intelligence developers/administrators.

Step 1 - Network administrators configure and prepare the network to suit the needs and requirements of the business.  Fail-over, overall monitoring and other critical functions are squared away by the network administrators who retain full administrator rights on the box and can view, edit and control any aspect of the units.

Step 2 - Two partitions are created, one for SAP Portal and one for SAP Business Intelligence, by the network administrators.

Step 3 - User accounts are created on BIG-IP LTM for each of the SAP development and administration groups and assigned to the appropriate partition.  Each group presents the list of individuals that need access.  A good rule of thumb is that for each role, there is one primary person and one backup.  Generic accounts, not tied to an individual, should be avoided for auditing and accountability reasons.

In this example, 8 accounts are created in total, 4 for each group. For Portal and Business Intelligence each, a Manager primary and secondary and an Operator primary and secondary.

Step 4 - The creation and negotiation of a Service Level Agreement (SLA) is highly recommended.  This step is critical to ensure standard operating practices across all three groups.  The agreement must spell out who is responsible for each part of the system, how each person can be reached and what the remedies will be for any outages.

Step 5 - Users are provided training through the use of Deployment Guides (e.g., SAP NetWeaver and Enterprise SOA (BIG-IP LTM, WebAccelerator, FirePass, WANJet)), through hands-on training by network administrators or through on-site training.  In reality, learning how to configure load balancing on BIG-IP LTM will come easily to any administrator who is already familiar with application concepts and/or is already running SAP's Web Dispatcher.

Finally, each user then takes over responsibility for the their own systems.  As a best practice, shared documentation should be available to all groups, to post experiences, schedule system-wide downtime and benefit from each other's learning processes.

Roles are well documented on the http://www.askf5.com site, as well as http://DevCentral.f5.com, but I will include a summary of the roles here.  Look to DevCentral particularly for great articles on iControl and Roles and Partitions. The roles are: 

Administrator - Complete access to all objects and configuration synchronization on redundant system pairs.

Manager - Create, modify and delete virtual servers, pools, pool members, nodes, custom profiles, custom monitors and iRules(tm); view all objects.

Application Editor - Modify nodes, pools, members and monitors; view all objects.

Application Security Policy Editor - Complete control of the Application Security Manager; view all objects (analogous to administrator for BigIP systems with ASM installed).

Operator - Enable and disable nodes and pool members; view all objects.

Guest - View all objects.