Organizational structure in PureApplication System operations

A guide for the perplexed

Adopting IBM® PureApplication™ System will require changes to your IT organization, simply because many of the challenges that IT organizations typically spend a great deal of effort addressing either do not exist when you are using an Expert Integrated System, or are reduced in scope and effect. Here is a comprehensive summary of the type of organizational structure and the corresponding changes that are necessary in order to successfully adopt PureApplication Systems. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Kyle Brown (brownkyl@us.ibm.com), Distinguished Engineer, IBM  

Kyle Brown is a Distinguished Engineer with IBM Software Services for WebSphere, specializing in SOA and Emerging Technologies. Kyle provides consulting services, education, and mentoring on SOA, object-oriented topics and J2EE technologies to Fortune 500 clients. He is a co-author of Enterprise Java Programming with IBM WebSphere and Persistence in the Enterprise. He is also a frequent conference speaker on the topics of SOA, Enterprise Java, OO design, and design patterns.


developerWorks Professional author
        level

Rajeev Gandhi (rgandhi@us.ibm.com ), Senior Technical Staff Member, IBM

Rajeev Gandhi is a Senior Technical Staff Member in IBM Software Services for WebSphere, specializing in PureApplication Systems. He has many years of experience in the IT field. His current area of expertise is providing consulting, services and education to internal IBM teams and clients on PureApplication Systems.



Venkata (Vishy) Gadepalli (vgadepal@us.ibm.com), Software Engineer, IBM

Venkata V. (Vishy) Gadepalli is a member of the WebSphere Enablement team in Raleigh. He has over five years experience in the IT field. His current area of expertise is enabling and consulting for WebSphere products, specializing in WebSphere Application Server, Portal, and Personalization. Before joining the Enablement team, Vishy was a member of the WebSphere development team. You can reach Vishy at vgadepal@us.ibm.com .



November 2013 (First published 17 July 2013)

Also available in Chinese

Introduction

In April 2012, IBM introduced the IBM PureSystems™ family of Expert Integrated Systems with its first two products, IBM PureFlex™ System and IBM PureApplication System. In November 2012, IBM PureData™ System, optimized exclusively for delivering data services, joined the PureSystems product family.

As the IBM PureSystems products have been introduced — particularly IBM PureApplication System — we’ve received a lot of questions from clients about what impact this new class of systems will have on their IT organizations. An earlier article addressed some of the general areas of organizational change that adopting PureSystems will entail. This article expands upon these notions and provides more detailed guidance specifically to organizations seeking to adopt PureApplication System.

IBM PureApplication System is a platform system designed and tuned specifically for transactional web and database applications. The workload-aware, flexible platform is easy to deploy, customize, safeguard, and manage. It reduces the amount of labor and time required for clients to support new and existing workloads. IBM PureApplication System implements the PaaS layer to provide superior IT economics. With PureApplication System, users can either create their own patterns of software, middleware, and virtual resources, or reuse patterns from IBM that are entirely functional out-of-the-box. Users can provision and share these patterns within a unique framework that is shaped by IT guidelines, industry standards, and years of best practices and industry standards, hence "Expert Integrated Systems."


The unique value of patterns

IBM has uniquely built expert knowledge into PureApplication System with patterns of expertise. A pattern can be thought of as a pre-defined architecture of an application. Each component of the topology will come pre-installed with the OS and middleware, and the pattern will be fully integrated across components, pre-configured, and tuned, with built-in hooks to advanced services like security, monitoring, caching, and so on.

Patterns of expertise contain proven best practices for complex tasks learned from decades of client and partner engagements that have been captured, lab tested, optimized, and then built into the system. With each PureApplication System, IBM provides several ready-to-use patterns for common enterprise software such as IBM WebSphere® Application Server and IBM DB2®. You can also purchase additional patterns for other middleware such as IBM WebSphere MQ, IBM Integration Bus, and IBM WebSphere Portal, among many others from IBM and business partners through the IBM PureSystem Centre. In addition, you can use the built-in editors to easily customize existing patterns or build new ones from ready-to-use components or from custom components you create. Each pattern can then be deployed multiple times. PureApplication System provides lifecycle management around the deployed patterns, known as instances.

Patterns deliver faster time to value by removing manual steps and automating system delivery. Patterns improve efficiency and simplicity by reducing IT costs and resources, and by reducing the amount of in-house expertise required for deployment of solutions. Patterns also increase control since repeatable, optimized deployments reduce the risk of human error. Details of the different types of patterns that are available in PureApplication System are described in these Preparing for PureApplication System articles.


Major steps in adopting PureApplication System

Once you have made the decision to acquire PureApplication System, your next steps will be in these four major areas:

  1. Install and setup PureApplication System in the data center

    There is a set of pre-installation steps that are needed to ensure that the data center has the proper prerequisites needed for PureApplication System. This ensures that the logistics, power requirements, network, and other requirements are met prior to the arrival of PureApplication System hardware arriving at the client site. IBM has a well-defined process for obtaining this information and makes it available to the systems engineer at installation time. Although the installation is performed by IBM, client participation is required in obtaining this information, and perhaps in making changes to ensure that logistics, power, and cooling requirements are met prior to installation.

  2. Determine and develop workloads to run on PureApplication System

    This involves determining which workloads should be moved to PureApplication System, and developing new or using existing patterns to deploy the workloads. This step is primarily performed by the client, although IBM can assist through services engagements or by helping you establish a Center of Excellence.

  3. Deploy and manage workload lifecycles

    Once workloads are deployed, these tasks will include managing workload lifecycles, monitoring resources used by the workloads, applying maintenance to patterns and to deployed workloads.

  4. Manage the PureApplication System

    This set of tasks involves the overall management and monitoring of PureApplication System to ensure the smooth running of all the different workloads in the system. Management tasks include creating different cloud groups within the system to provide the isolation needed by different user groups using PureApplication System, handling the security authentication and authorization, auditing, applying system maintenance, and so on. Monitoring tasks include looking at the overall system utilization, bottlenecks, and making the necessary adjustments.

Simply stated, adopting PureApplication System requires changes to your IT organization because many of the challenges that IT organizations typically spend a great deal of effort addressing either do not exist when you are using an Expert Integrated System, or are reduced in scope and effect. The remainder of this article describes the types of organizational structures and changes that are necessary in order to successfully adopt PureApplication Systems in an IT organization. This is described in the context of building a Center of Excellence for PureApplication System within your organization. Also included are descriptions of the roles that IT team members must take on when adopting PureApplication System.


Overall changes

Based on our observations, the general principles referred to in the article Aligning organizations to achieve integrated system benefits with IBM PureApplication System will likely lead to some general changes in your organization, particularly:

  • You're going to need more generalists and fewer specialists

    This is probably the biggest overall change to your organization. The approach taken by IBM PureApplication System folds all of the major parts of a large-scale, virtualized, distributed system into one package. As a result, you will find you need a split between a larger team of low-cost generalists who can handle simple deployment and monitoring tasks, and a much smaller team of high-skilled specialists that address specific issues. Tasks that now take teams of specialists days to accomplish can be accomplished by lower-cost, lower-skilled generalists in much less time. Likewise, when problems do occur in your application, the unified console and unified logging and monitoring capabilities make it possible for a single specialist with a higher skill set to debug and solve those problems faster without having to call in a SWAT team to deal with the issue.

  • Integrated organizations will implement DevOps

    As noted in this article, a consequence of adopting PureApplication System is that your organizational structure will tend to become less compartmentalized and more integrated. This observation at the heart of a new set of initiatives from IBM Rational® and IBM Tivoli® on IBM SmartCloud® Continuous Delivery (sometimes called DevOps). Automated deployment to IBM PureApplication System is a key part of this new initiative. But continuous software delivery is not the only benefit of decreased compartmentalization. Through increased collaboration, your organization will get better at planning projects because there are fewer things that can go wrong when the systems are pre-integrated and optimized with patterns of expertise. Likewise, you will find smaller teams working more closely together on things like problem resolution – instead of requiring four to six specialists to separately obtain the data, interpret the data, identify the problem, and fix the problem, a smaller number of generalists can perform all of those steps. As part of this change, troubleshooting becomes more about looking at trending and looking for patterns in the data – especially those that derive from implications of shared infrastructure.

  • Everyone will do less double-checking to find out if everything is the same, and more work to make everything the same from the beginning

    Today, development teams spend a great amount of effort on trying to determine if all of the various development environments in a software development lifecycle have the same configuration. Internal IBM studies have shown that a high percentage of bugs found in production are actually bugs that had been either introduced or re-introduced through configuration changes in test environments that were not conveyed forward to production environments. There are many sources of these changes: operating system patches, middleware fix packs, or simply configuration changes applied to the middleware itself, such as transaction timeouts or JDBC pool sizes made from the IBM WebSphere Application Server console. At the heart of this problem lies the fact that the reason why these configurations drift apart over time is that each environment is a long-lived, hard-to-construct assembly of a lot of parts. Developers and administrators are loath to tear an environment down and replace it once it is built because the time and effort required in building an entire environment is so large. Instead, one of the design principles behind IBM PureApplication System is that you put more effort into specifying the templates behind your enterprise software configurations (for example, patterns) and less time into managing the instances once they are constructed. If the latest configuration information is all captured in a pattern, then it is simple to re-create a new instance of that pattern. This means that different environments are all built from the same pattern, and thus all start out from an absolutely identical place. (IBM PureApplication System can help with keeping the different instances of a virtual system identical as well through the capabilities of the Advanced Middleware Configuration tool that ships as part of IBM PureApplication System.)


Role changes

Another observation we have made is that certain roles will need to change due to the benefits of the automation provided in PureApplication System. The reduction in work described in this section enables your team to begin working through existing IT backlogs without having to increase IT budgets. This reduced effort needed for common tasks also enables your staff to re-train and obtain new skill sets needed to address new business opportunities.

  • Less work is needed to rack and stack servers

    One of the questions that clients ask when they first find out about IBM PureApplication System is “so who assembles it?” In the past, distributed systems were always purchased piecemeal and arrived in multiple boxes that someone had to be responsible for unpacking, and then racking, stacking, and cabling the servers together. The truly unique thing about PureApplication System is that it doesn’t arrive as a large stack of boxes. The entire rack ships as a single, pre-assembled, pre-cabled, pre-integrated, pre-tested system. IBM is responsible for unpacking the system in your datacenter, connecting it into your network and power, and then booting the system up, validating its functionality, and configuring it to recognize your network – all within four hours! And when you decide you want a server upgrade to add more CPU and memory, that is, likewise, all done by IBM in the space of about an hour – without your having to take an outage!

  • Less expertise is needed for managing storage

    Before IBM PureApplication System, you had to have an entire group dedicated to managing the storage area network (SAN) infrastructure that your compute hosts worked from. Besides setting up the physical parts of the SAN, someone had to be responsible for all of the SAN and logical unit number (LUN) planning and mapping to connect the SAN infrastructure to your hosts, and to perform the host and volume configuration, host mapping, storage pool management, and so on. Likewise, the once the infrastructure was set up, it had to be constantly cared for and managed to keep up with new driver levels, SAN software levels, and so on. In IBM PureApplication System, this is all done for you. The only storage tasks that anyone performs during normal operations are to decide on the appropriate volume size when a new VM is provisioned, to expand volume sizes when needed (for example, when a database is close to expanding beyond its originally available volume size), and to perform backup and restore operations.

  • Less work is needed in caring for your virtualization infrastructure

    Another major change with IBM PureApplication System from traditional ways of doing things is that you don’t have to have someone set up your virtualization infrastructure. If you were building a virtualized environment on your own, you would need to have someone responsible for installing hypervisors, installing the virtualization management infrastructure, connecting the individual hypervisors into the infrastructure, and then maintaining the infrastructure once it’s assembled. Again, this all works directly out of the box with IBM PureApplication System. The scope of the virtualization team is reduced so they can now manage more virtualized environments, and with the trend of IBM Pure Application System, the team can now take on other duties in the IT Area.

  • Less work is needed in network management

    Any modern distributed system is supported by a mass of network cabling. There is an enormous amount of planning and work that goes into setting up a LAN, with work going into connecting distributed host computers to a SAN, to each other, and to rack-mounted switches. Then, someone has to configure all of those physical networks, assigning IP addresses to servers, specifying how those map into VLANs, and so on. IBM PureApplication System either eliminates those tasks or reduces the amount of effort needed to perform those tasks. There is still some planning that has to happen to determine how you are going to set up the internal network in your PureApplication System, but once you make those decisions the implementation proceeds very quickly, and nearly everything you need to specify is done during the 4-hour installation window. Likewise, the care and feeding of the internal network is a much simpler operation, requiring far fewer man-hours than the management of a typical network.


Skill set changes

While the need for certain skill sets are lessened with the adoption IBM PureApplication System, others become more prominent, thereby changing some existing roles and adding some new ones:

  • As the lifetime of systems change, the types of administrative actions you perform also change

    As an example of what we mean about patterns being things where the definition is more important than the implementation, one change that we’ve found with clients that adopt the WebSphere Application Server patterns in IBM PureApplication System is that the lifetime of a WebSphere Application Server cell changes. This is a ramification of the best practice described in this article where we've seen a change in how environments are viewed — they are no longer long-lived, but are, instead, transient assets. Your WebSphere Application Server system administrators will get used to working on more, smaller cells with shorter lifetimes. In the old way of doing things, a WebSphere Application Server cell would generally be created to represent a development environment, and then that same cell would generally last in the same form until it was replaced when a major WebSphere Application Server upgrade was adopted for that project, usually in a time frame of 1-4 years. In some of the clients we are now observing, the average time frame for the lifetime of a cell has dropped down to a few months (as few as 3 or less in some cases). So, your WebSphere Application Server system administrators (and likewise for system administrators of all types of middleware) will spend less time modifying live systems in the GUI of their respective tools and more time writing scripts that will be executed on the live running systems that are pattern instances, and as part of creating new instances of those patterns.

  • You'll need people who are good at abstraction to create standard patterns content

    So what do the people who used to manage your virtualization infrastructure do instead? They do the very useful work that helps your business get things done better and faster. For example, remember the benefits mentioned earlier of keeping your different development and test environments in synchronization and keeping them up to date with the latest versions of OS patches, and so on. That kind of global planning work does require ongoing effort from experts in building and modifying hypervisor images. IBM PureApplication System comes with the Image Construction and Composition Tool (ICCT) from Tivoli that is designed to aid administrators with that kind of work. Likewise, you need to centralize other types of content such as standardized virtual system patterns and virtual application plugins. This kind of content creation requires people specifically skilled at abstraction to design and develop the minimum set of long-lived assets for your organization.

  • Everything happens faster, which requires more discipline and coordination in your Software Development Lifecycle (SDLC) processes

    In a business-as-usual environment without patterns, constructing a Development, System Integration Test, or User Acceptance Test environment can take weeks or months. With the pattern capability provided by PureApplication System, this entire process can be shortened to days or hours. That means that the amount of "wiggle room" in existing build and deployment processes goes away as any missteps become visible immediately, and also as the manual "desk checking" time that is often used to find and correct process problems is reduced. One place where this becomes very important is in application deployment automation. It does not help your organization's overall efficiency if the time it takes to deploy your middleware is reduced to a matter of a few hours, but then it takes days of trial-and-error manual work to deploy your application into that middleware and configure it appropriately. Thus, building automation to improve the efficiency and repeatability of this task is an important part of improving the efficiency of your overall software development lifecycle. Another aspect that we have found to be just as important is to improve the communications between the team working on building and deploying your patterns and your security team. Again, it does no good if a new environment can be deployed in hours if it takes days or weeks to process the paperwork to open the appropriate ports through your corporate firewalls to allow that new environment to be used.


Roles for PureApplication System

The preceding section described general changes to your organization that happen as a result of adopting PureApplication system. Next, we’ll define a new set of roles that are common to IT organizations that use PureApplication System, and look at how existing roles have been redefined, all stemming from those changes.

Be aware that these are simply roles and not job descriptions; it is valid to expect that in some cases a single person might carry out multiple roles, and that in other cases it might take an entire team to fulfill a single role in an organization. Also, the roles defined here relate specifically to management of workloads running on PureApplication System. Where clients will also maintain their traditional infrastructure, their existing roles will of course continue to play a part in that management. Therefore, some of these existing roles might only be of a consulting or secondary nature with regard to PureApplication System.

Data center operations

This team focuses on the system aspect of PureApplication System, not on the workloads that run on the system. They are responsible for the daily operation of the system, as well as the operation of other systems in the data center. The primary roles described here are directly responsible for interacting with the PureApplication System, while the secondary roles are usually more consultative in nature and might not directly interact with the system.

Primary roles:

  • PureApplication System Administrator

    The system administrator owns the system and is responsible for keeping the system up and functioning. This role determines the integration of PureApplication System with existing systems like external monitoring, reporting, security, and so on. He is responsible for enforcing adherence to the organization’s IT standards for this integration and will use automation, where possible, to limit human error. During the installation and setup phase, this role is responsible for working with the IBM engineers who complete the on-site setup, and will also receive the master passwords for the system that are created as part of the setup process. The system administrator then uses those security credentials to create other IDs on the system and assign those IDs to other roles.

  • Physical Cloud Administrator

    Also referred to as a Physical Cloud Architect, this role configures and manages the physical cloud assets in the PureApplication System. This includes creating new isolated clouds within the system (with the desired quality of service as needed for different internal or external groups using the system), managing shared services in the cloud as required by applications, creating IP groups with the VLAN assigned by network administrator, troubleshooting cloud infrastructure, monitoring the resource utilization on the different clouds, adjusting the resource assigned to those clouds based on the needs of the users of those clouds, and working with the different departments.

  • Network Administrator

    Network administrators are responsible for the network components within a WAN or LAN infrastructure. They might plan, design, and deploy networks, plus they might perform activities such as IP address assignment, IP address management, routing implementation, and switch and network server administration. From a PureApplication System point of view, responsibilities would include assigning VLANs for the different IP groups to create the necessary isolation, and assigning the ports for those VLANS on the top-of-rack switches for data network and for network management. Network administrators work with physical cloud administrators to provide the necessary VLANs and IP groups as needed to create clouds and ensure network compliance with the organization’s IT policies. During the initial setup phase of implementing PureApplication System, they will be consulted often in making decisions regarding what ports to use; however, during the day-to-day work of managing PureApplication system, they are consulted only on a periodic basis as the physical cloud administrators need to revisit the allocation of network resources.

  • Security Administrator

    Security administrators ensure that the system is secure, manage the LDAP configuration for user/group authentication, manage users/groups within the system, and provide the necessary authorization to the different functions/tasks of the system. They also make sure the system complies with the security policies of the organization. They ensure that corporate security policies are followed in the implementation of the workloads running in the system. As with network administrators, security administrators will be consulted often during the initial setup phase as initial policies are set in place and the initial connection to the corporate security infrastructure is set up, but will be active periodically as the day-to-day management begins.

Secondary roles:

  • Facilities Operations

    Facility operations managers are responsible for the physical maintenance and management of a data center. They are responsible for managing electrical load and capacity management, managing physical floor load capacity, and also overseeing heating and cooling to maintain optimum operating temperatures for computing equipment. With respect to IBM PureApplication System, they work with the IBM CTP on the initial planning, delivery, placement, and installation of the system, and physical connection to the power grid to ensure that all the facilities, HVAC, and power requirements are met.

  • Storage Administrator

    The storage administrator designs, plans, implements, administers, and provides support for SAN storage systems. Since PureApplication System does not currently use or connect to external SAN storage systems (except through NFS) and contains its own internally-managed SAN, this is primarily a consultative role.

  • Data Center Operations

    This group proactively monitors computing systems and the network infrastructure. They provide change management and problem management to manage and correct network issues. With PureApplication System, the data center operations team can monitor SNMP events sent to an external monitoring tool.

Application operations

This team is responsible for creating and maintaining environments for different application development groups using the racks to deploy and manage their workloads.

  • Application Cloud Administrator

    This is a new and emerging role that is specific to PureApplication System. This role within application operations creates and manages environment profiles and maintains the users that have rights to deploy and manage applications running on an Environment profile.

  • Middleware Administrator

    This is usually an existing role. This role manages middleware products and environments including performing new installations, upgrades, maintenance and tuning, monitoring, and capacity planning. This role also provides technical expertise during application deployments and assists in troubleshooting application and platform issues. This role is reduced in scope by PureApplication System since new installations and upgrades are handled through patterns.

Database operations

  • Physical Database Administrator

    A physical database administrator is responsible for the physical aspects of database administration. In a traditional environment, this would include tasks such as DBMS installation, configuration, patching, upgrades, backups, restores, refreshes, performance optimization, maintenance, and disaster recovery. This role changes when PureApplication System is considered. DBMS installation, configuration, and patching becomes a much simpler operation, especially in cases where IBM DB2 as a Service (DBaaS) can be used. Even in cases where a DB2 virtual system pattern is created, those tasks become simpler. Instead, for DBaaS, the Physical database administrator becomes responsible for the definition of customer-specific workload standards. Backup and restore is also simplified by the built-in support for these aspects that are part of Dbaas.

Finance and compliance

These secondary roles would not directly interact with the system, but would be receivers of information obtained from the data center operations team.

  • Business Manager

    This role is responsible for billing management and overall financial responsibility for the machines in the data center. In PureApplication System, this role would create charge-backs from usage reports, where needed.

  • Audit Manager

    In many organizations, especially financial organizations with fiduciary responsibility that are answerable to governmental authorities, there are often standard audits of access logs or system utilization that must be periodically run. The audit manager manages the audit data coming from the system and acts upon it as appropriate.

Content enablement

This team (often called the corporate engineering team) defines and controls the standards used by the organization for OS, middleware, database, security, and other aspects of system management. As described earlier, it is a best practice for reusable pattern content to be implemented by a centralized team; this team is the best place for those content creators. Thus, this team is responsible for creating or certifying shared resources (such as patterns, images, OS packages, security packages, and so on) that will be used content developers.

Primary roles:

  • Pattern Engineer

    A pattern engineer is responsible for adapting existing PureApplication System patterns to the needs of the customer or for defining new patterns. This is an important new role that defines all the patterns that will be used with PureApplication System, based on the needs of different application groups. This includes defining new virtual system patterns and script packages, looking at how to change existing patterns, and integrating the work of third parties into these systems. It also includes defining plugins for new types of virtual application patterns, where needed. Pattern engineers implement the best practices of pattern development by making the pattern shared across multiple similar environments, and creating the transient application information to be specified at deployment time. They make the decision of when to use an existing pattern for a given application need, or whether application needs require a new pattern. Consulting with the corporate security engineer, they will ensure that the corporate standards for OS, security, and middleware are included and satisfied in their patterns.

  • Pattern Developer

    Based on the design of the pattern, as defined by the pattern engineer, pattern developers are responsible for creating new virtual system patterns and script packages, modifying existing patterns, and integrating the work of third parties into these systems. It also includes creating plugins for new types of virtual application patterns, where needed. This role is also responsible for updating and maintaining these patterns and plugins throughout their lifecycles.

  • Asset Librarian

    This role manages the catalog of assets (images, plugins, script libraries, and patterns) across the organization's set of PureApplication Systems. The asset librarian is responsible for making sure the catalog is current, and that it contains the correct set of resources for the purposes (development, test, production) for which each PureApplication System is used. If the best practice on using a standardized version control system for long-lived assets is followed, then this role is responsible for keeping the PureApplication System catalog in sync with the proper versions of the assets held in the version control system.

  • Deployment Automation Developer

    This role is responsible for writing and maintaining automation for application installation and configuration and integrating this into the patterns. The person in this role may write custom automation, or may manage the integration using deployment automation tools such as IBM UrbanCode uDeploy. Since the tooling used for deployment automation needs to integrate closely with existing continuous integration processes, this role will need to work with the teams that manage continuous integration. Finally, they will need to collaborate with the application teams and also the Patterns Developer and Architect as they set up deployment automation that is compliant with corporate policies for deploying code to different types of middleware.

Secondary roles:

  • OS Engineer

    In IT environments that use standard (meaning non-PureApplication System) virtualization, this is a critical role. OS engineers decide upon and publish the base VMWare or other hypervisor images that are used by all application development (and other) teams for middleware installation and configuration. With PureApplication System, this role diminishes because the base images are already provided by IBM and the middleware is already pre-installed with configuration provided by scripts or by policies. Instead, this role becomes more of a planning and consultative role that involves understanding fix packs, security patches, and third-party agents that are installed by scripts that run in all virtual systems as part of a corporate "standard" installation, or that are added to virtual applications through the PDK. They provide a consulting role to pattern developers (below) to ensure standards are implemented as part of the pattern.

  • Database Engineer

    This role is responsible for setting corporate guidelines for database implementation and use. These guidelines can be implemented as scripts in virtual systems, or as workload standards in DBaaS. This role will often direct the work of the physical database administrator, who is responsible for implementation of those scripts or workload standards.

  • Middleware Engineer

    As with the other planner roles, middleware engineers are responsible for setting guidelines regarding which versions of middleware are current. They might also be responsible for planning middleware upgrades as well. With PureApplication System, this is primarily a consultative role carried out in concert with the application operations team.

  • Network Engineer

    A network engineer designs and implements corporate networks. This role must take into account bandwidth capacity, infrastructure, and security requirements. Network engineers can also be responsible for planning potential network expansion, which often involves network modeling, and traffic prediction and management. Because PureApplication System contains many network components already built in, this role with PureApplication System is specifically related to planning the connection between PureApplication System and the existing corporate network. The network engineer will often direct the work of network administrators.

  • Corporate Security Engineer

    This role determines security requirements, plans compliance with information security standards, and plans out and conducts system vulnerability analyses and risk assessments. In addition, this role plans security systems related to networking infrastructure (such as firewalls and related security and network devices), designs public key infrastructures, and guides the implementation of security systems. With respect to PureApplication System, this role could include determining the integration of PureApplication System with existing firewall systems, selecting security products for integration with PureApplication System, and validating the compliance of PureApplication System with existing corporate security standards.

  • Build Engineer

    This existing role is responsible for setting and maintaining up the build and continuous integration environments for the organization. They will need to work closely with the Deployment Automation Engineer to define the connections between the organization's build and deployment processes and the new environment deployment capabilities provided by PureApplication System.

Solution development

This team (which could in fact be multiple teams) is responsible for developing, testing, and maintaining applications for deployment either on PureApplication System or on other platforms for which PureApplication System is being used as a development platform.

Application development

  • Application Software Engineer

    This existing role is changed slightly by PureApplication System. Software engineers plan, design, and execute the topology and implementation of application systems. They are responsible for middleware selection and for overall application system design. With PureApplication System, the role changes to enable software engineers to start from a set of common pre-built patterns that describe template application topologies. Thus, an application engineer might be responsible for selecting patterns from a patterns catalog and deploying new instances into an environment provided to them through an Environment profile. This guarantees better repeatability between different environments (development, test, production). Engineers can then focus on the internal design of the application software for which they are responsible.

  • Application Security Engineer

    This role is responsible for the design and implementation of security solutions within a single application. This often includes addressing concerns such as login, single sign-on, authentication, and authorization within an application. As with the application engineer, this role is simplified by PureApplication System in that there is a greater potential of reuse of existing design solutions captured as repeatable patterns.

  • Application Developer

    The responsibilities of this existing role are not significantly changed by PureApplication System. One difference, though, is that when development and test systems are deployed to PureApplication System, developers have a consistent place to test their code. Another change worth noting is for organizations in which application developers use the WebSphere Application Server administration console (or other middleware user interface) for deployment, and for setting server configurations. Instead of using the console, all configurations should be specified as script packages or policies so that consistency can be maintained across all environments.

  • Application Tester

    This is another existing role that is little changed by PureApplication system, except that testers work within a test environment guaranteed to be consistent with development and production environments. One small change here is that once a test system has been described in PureApplication system, it need not remain running during times when active testing is not taking place. It can be "turned off" by stopping the corresponding pattern instance, and then easily and quickly "turned on" by restarting the pattern instance at any time. This enables much better overall system utilization and better resource allocation.

Database development

  • Database Application Developer

    This existing role is responsible for using database tools from their database vendors, and are responsible for creating applications-specific DDLs, queries, stored procedures, and other application information storage and retrieval artifacts. There is little change in this role with regard to PureApplication System.

  • Database Application Administrator

    This existing role is responsible for administering and tuning client-specific databases, updating existing databases to new DDLs, performing data migrations, and performance tuning for application-specific queries and stored procedures. There is little change to this role with PureApplication System.


Activity levels per role

Table 1 shows which of the above roles are high, medium, and low touch, in terms of how much of their time will be spent supporting PureApplication System. In this table:

  • High: Once every 1-7 days
  • Med: Once every 15-90 days
  • Low: Less than once every 90 days or when needed
Table 1. Table 1
RolePrimary or ConsultingNew role for PureApplication Touch level
Data center operations
PureApplication System AdminPrimaryNoHigh
Physical Cloud AdminPrimaryYesMedium
Security AdminConsuiltingNoLow
Network AdminConsuiltingNoMedium
Facilities OpsConsuiltingNoLow
Storage AdminConsuiltingNoLow
DataCenter Ops (NOC)ConsuiltingNoMedium
Application operations
Application Cloud AdminPrimaryYesMedium
Middleware AdminPrimaryNoHigh
Database operations
Physical Database AdminPrimaryNoHigh
Finance and compliance
Business ManagerPrimaryNoLow
Audit ManagerPrimaryNoLow
Content enablement
Pattern EngineerPrimaryYesHigh
OS EngineerConsultingNoLow
Network EngineerConsultingNoLow
Security EngineerConsultingNoLow
Database EngineerConsultingNoLow
Middleware EngineerConsultingNoMedium
Pattern DeveloperPrimaryYesHigh
Asset LibrarianPrimaryYesHigh
Deployment Automation DeveloperPrimaryYesHigh
Build EngineerConsultingNoMedium
Solution developers
Application Software EngineerPrimaryNoHigh
Application Security EngineerConsultingNoMedium
Application DeveloperPrimaryNoHigh
Application TesterPrimaryNoHigh
Database Application DeveloperPrimaryNoHigh
Database Application AdministratorPrimaryNoHigh

Suggested organizational structures

One of the key aspects of adopting a new technology like PureApplication System is that such a major change cannot be accepted by an organization all at once. It takes time to transition roles and responsibilities between parts of an organization, and it takes time to train people to take on new roles. What's more, with any new technology, there is an inevitable learning curve that an organization has to overcome in order to become productive with the new technology. To help you overcome this learning curve, a standard organizational effort that IT teams can put in place is a Center of Excellence (COE). IBM has a long track record of helping IT teams adopt new technology (beginning with Java™ through SOA) by introducing Centers of Excellence, and is continuing by helping clients establish COEs for IBM PureApplication System.


Structure of a PureApplication Center of Excellence

Early on in the adoption of PureApplication System, the members of your COE can take on most of the different new roles described in the previous sections. However, a critical principle and responsibility of a COE is to, in effect, "work itself out of a job," as opposed to becoming a department that grows ever larger over time. Instead, the COE would be focused on training and equipping other teams to take over many of the tasks associated with PureApplication System.

The COE is where new knowledge about PureApplication System is acquired in the organization and it is responsible for spreading it out to the other teams. For example, application development teams will need training in understanding what patterns are and how they affect their development, and also how to perform automated deployment using the workload console. Systems administrators on the operations team will need training in how to read the logs and graphs in the system console. IBM can help by providing initial individualized and large-group training for these roles, but the day-to-day support for this will need to come from the COE. Once the key work of setting up policies for managing and governing assets and training the various teams in what those policies are and how they are executed in everyday operations is complete, the COE can then begin to wind itself down to only its core content enablement aspect.

In general, we would also advocate that the COE be split into two subteams; an infrastructure subteam and a content subteam. This follows the overall split of PureApplication System into the System Console and Workload console, and also follows a natural division of labor that most organizations already follow.


Task division for COE subteams

The content team is responsible for managing and maintaining the patterns catalog. That includes obtaining patterns and new pattern versions from IBM, creating and maintaining script packages, creating customer-specific pattern versions, and maintaining all pattern versions. They are also involved in helping operations in maintaining existing pattern instances. They work almost exclusively in the workload console. The content team is also responsible for governance of the shared intangible assets (patterns, images and script packages).

The infrastructure subteam is responsible for configuration and management of the overall rack and its internal infrastructure. That includes both the physical cloud infrastructure elements and the virtual cloud infrastructure elements discussed earlier. They are responsible for monitoring the PureApplication System infrastructure, managing security policies, handling backups and restores, capacity management and management of the shared physical resources.

Given the best practices described above and in this companion article, the centralized content team should be responsible for building all virtual system patterns. Likewise, we would recommend that if any new virtual application pattern components are to be built using the IBM Patterns Development Kit, then this team should also be responsible for that development. Given this set of responsibilities, IBM's recommendation is that the content team should contain at least a small number of experts in each discipline (for example, middleware, MDM, BPM, and so on) who are responsible for building and maintaining the standard patterns for each technology. They will do so with input from the application development team, who will provide requirements for the new patterns. The content team will function best with help and guidance from IBM; this is especially true during the initial startup phase of the COE, where IBM can provide specific training in PureApplication System pattern development to the patterns team.


Moving to around-the-clock operations

In most cases, the COE will need to take on many of the operations roles until such time as the operations team is able to learn how to carry out those functions. Therefore, the COE will need to provide training for the operations team on all of the processes that happen day-to-day, such as deploying production instances, monitoring the pattern instances and infrastructure, applying maintenance, handling backup and restore, performing governance, and capacity management. As part of the transition plan, the COE will need to set up specific escalation procedures so that the operations team will know when to contact the COE for incident resolution. Likewise, the COE needs to set up asset governance policies for execution by the operations team. The COE also needs to define the changes to the ITIL (Information Technology Infrastructure Library) processes for the operations team to follow. (Changes to ITIL processes required by PureApplication System will be covered in a follow-on article.)

An initial step toward the new approach is to put procedures in place to ensure that transient assets are deprovisioned and returned at appropriate times. This helps to reinforce the best practice that environments are not long-lived. This will enable the use of a self-service model for the dev/test systems through which application development teams can deploy new pattern instances of standard patterns. They will be able to use these instances freely within the bounds of the policies set by the patterns team with regard to what can be changed, how application artifacts are managed and packaged, and how long instances can be kept in place without being used.

Likewise, when the patterns team develops a new version of a standard pattern, the operations team can then put a time limit on how long the previous version will be supported in dev/test. It is the responsibility of the application development team to provision the new version of the pattern and to automatically deploy application resources (EAR files, configuration files, and so on) onto the new version within that time limit of support.

A final step along this road is to automate these processes. Once the governance processes are established and automated so that they can be efficiently carried out by the applications development and operations teams, this then enables the COE infrastructure team to plan a graceful exit from the stage. Similarly, the patterns team can decrease in size over time as fewer new patterns are built or customized once the applications development teams move to adopting off-the-shelf patterns, or to reusing existing customized patterns.


Conclusion

This article built upon best practices and general organizational observations to provide a more detailed view of how organizations will change and evolve after adopting IBM PureApplication System. The next follow-on article will expand upon the discussion of roles provided here and offer details of the most common scenarios that fall into the areas of client responsibility described in the Introduction. We will likewise describe the major tasks that go into managing and operating PureApplication System within the datacenter that fall within those scenarios, and discuss how those relate to the organizational roles discussed here.


Acknowledgements

The authors thank the following for their contributions and reviews of this material: Ajay Apte, Senior Technical Staff Member, IBM PureApplication System; James Kochuba, Development, IBM PureApplication System; Mike Law, Development, IBM PureApplication System; Jose Ortiz, Senior Software Engineer, IBM PureApplication System; Terry Bleizeffer, User Experience Architect, IBM PureApplication System; Clarence Cudanes, Cloud Practice Manager, IBM Software Services for WebSphere; Son Huynh, Solution Cloud Executive IBM Cloud Labs. Special thanks to Daniel Berg, Senior Technical Staff Member, IBM Rational for helping us understand the importance of the roles involved in deployment automation.


Appendix: Glossary of terms

Compute node
Actual servers in the PureApplication System rack where the VMs run.
IP groups
Logical groupings of one or more IP addresses and networking information, such as DNS, subnet, VLAN, and so on. A virtual machine (VM) deployed into the PureApplication System infrastructure will be assigned its IP address.
Cloud group
Logical grouping of computing resources (compute nodes) to target your deployments in PureApplication System. It requires one or more compute nodes and one or more IP groups. A pattern is deployed to a cloud group (using an environment profile).
Environment profile
Policy for deploying patterns into cloud groups. These are policies that group related deployment configuration, such as virtual machine names, IP address assignment, and cloud groups, forming logical deployment environments. During deployment of the patterns, the deployer would specify an environment profile as the target of the deployment. This in turn lets PureApplication System know the cloud group and IP group to use for deployment.
Pattern
A pre-defined architecture of an application. For each component of the application, a patterns comes pre-installed with the OS, middleware, integrated across components, pre-configured and tuned, with built-in hooks to advanced services such as security, monitoring, caching, and so on.
Virtual system pattern
Provides an automated model for deploying middleware topology patterns. These enable clients to quickly deploy traditional workloads in a virtualized environment in a repeatable fashion. Products deployed using the virtual system patterns are managed using the existing management tools provided by those products. Virtual system patterns contain a collection of middleware parts that can be connected to build a topology for a particular type of deployment. The middleware parts that are used to build these patterns are known as virtual images. IBM provides many virtual images that contain IBM middleware products designed to run in virtual machine environments; it is also possible to include custom virtual images.
Virtual application pattern
Provides a highly automated, policy-based deployment model in which the client defines application components and policies that specify the needs of the application. The virtual application pattern is application-centric, whereas the virtual system pattern is middleware topology-centric. A virtual application pattern has a highly simplified administrative model, exposing fewer administrative functions than the virtual system pattern.
Deployment or instance
Created when the pattern is deployed, an instance contains the actual VMs that are running in the cloud. The deployed pattern would specify the environment profile to use for deployment.
Shared services
Provide patterns that can be deployed and shared by multiple virtual applications, virtual systems, and virtual appliances in the cloud. Examples are caching, proxy, and monitoring.
VM
Virtual machines created during the deployment of a pattern or shared service. A given pattern may have one or more VMs.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Cloud computing
ArticleID=937605
ArticleTitle=Organizational structure in PureApplication System operations
publish-date=11172013