Bridging the Gap Between Development and Operations

Many IT organizations have built a wall between application development and the infrastructure operations team. This relationship (or lack thereof) leads to difficulties in managing to service level objectives and commitments. Adopting the perspective that the application is a layer of the overall infrastructure for distributed systems and understanding the handoffs that need to be made between application development and infrastructure operations can lead to improvements in the management of “holistic” services and the achievement of service level goals.

Business needs drive the requirements for new applications. The application contains the logic necessary for supporting business processes. However, the application alone is not the system or business “service”, but a component of the service. All architectural components that comprise the business service along with the customer’s service level needs must be considered to support and maintain the service as a whole. This includes the application software, operating system software and network and server hardware. The propensity to design and develop applications without factoring in all the layers of the infrastructure or supportability requirements makes service level commitments impossible to achieve.

The Disconnect

Organizational Challenges: Application development (AD) organizations are often separate functional entities from the infrastructure organization or the operational support team. Large organizations have a tendency to run infrastructure as shared, centralized services while AD teams are housed in federated organizations that report directly to the business units they support. Even small- to mid-sized organizations have developed true “turf” segmentation between AD and IT operations. As a result, these two functions just don’t talk to each other enough.

The complexity of more highly distributable environments like J2EE makes the need for communication between these two groups at the very beginning of the application development process extremely important. The lack of coordination across these organizations leads to the development of applications that do not play well within the current infrastructure environment parameters.

Priority Differences: AD organizations face the challenge of having to deliver business value to the customer as quickly and cost effectively as possible. Their goal is to assure productivity and quality in the software development process and interoperability in the systems they produce. In doing so they are focused on developing application architectures and processes that assist them in building reusable, flexible services that are easily integrated in a quick and efficient manner to deliver value to the customer.

IT operations organizations, on the other hand, are tasked to maximize availability, capacity, security and continuity of the infrastructure while minimizing the cost. As a result, their focus is to assure the infrastructure is standardized and optimized for total cost of ownership; availability and capacity can be assured through the ability to monitor and manage the architectural components of the environment; and procedures are in place to recover rapidly from failures. These differing goals preclude the design of a complete, supportable business service—the end-to-end perspective that must be considered when attempting to adhere to agreed upon service levels with customers.

Bridging the Gap

Designing and managing business services from a holistic perspective requires coordination and collaboration between AD and IT operations.

Steps in achieving this goal include:

Architecting for supportability: Organizations that do not have an enterprise architecture (EA) role or group should look to institute this function to assist in overseeing the holistic view of the business service from the application layer through the infrastructure layers. Organizations that have an existing EA function should assure that this group works to promote cost-effective time-to-value, reuse, interoperability, as well as manageability of business services. Since underlying technologies such as storage and network components and middleware are leveraged across multiple business services, it is important that this organization have a cross-business service view of the utilization of these resources to make the appropriate architectural recommendations.