Shared information and processes yield a better outcome
As enterprise IT has evolved and services have become more complex, the idea of sharing information and processes across the organization has become increasingly appealing. Basically, businesses can get better results by linking teams and technologies instead of keeping them segregated.
This shouldn't come as a surprise to anyone familiar with the emergence of Service-Oriented Architectures (SOA) or ITIL v.3 best practices. In both cases, the focus is on services and service management—not the technology silos or organizational groups responsible for managing these services. As an organization begins sharing information and solutions, applying them in different ways, the result is a reduction in the time, energy, and costs required to pursue any given goal.
This idea is most commonly applied to technical domains inside IT operations (and the IBM Tivoli service management portfolio is a great way to pursue it). There is just as much value, however, in applying the same idea across IT—linking IT operations with IT development and thus improving collaboration.
Organizations that develop custom software in-house have historically kept development teams segregated from operations teams—but today's application-driven services, that span both development and operations, demand a more integrated and collaborative approach. If the goal is to render the highest-quality services via software, the complete lifecycle of that software must be taken into account, from concept to launch to retirement.
Linking IT operations and development for concept-to-retirement app management
(Open Services for Lifecycle Collaboration) (link resides outside of ibm.com) , launched by IBM in 2009. OSLC focuses on optimizing application lifecycle management via new links that connect information and tools across domains.Perhaps the best-known initiative focusing on lifecycle integration is OSLC
One excellent example of how OSLC can create added value: integrating IT development and IT operations. Through OSLC, both operations and development teams can use the tools already familiar to them to accomplish new tasks, such as creating trouble tickets for the other team and accessing information previously only available in one domain. Instead of operations and development functioning as separate worlds, they can collaborate—jointly striving to create better software for more business value.
To achieve this, OSLC first creates the big picture, including the required abstract concepts, then fosters development of the specific technologies needed to make those concepts a reality (such as determining specifications for resources, protocols, and interfaces).
One of the key concepts of the OSLC to date is Linked Lifecycle Data. The premise here is that data should be an asset held in common repositories accessible across different lifecycle management solution groups, such as change management, requirements management, quality management, and others. The more these federated assets are shared, the better the business outcome is likely to be.
One way to understand this is to interpret OSLC concepts as an expression of Internet principles—and implemented in part via Internet technologies. Consider HTTP, for instance. This is a basic, relatively simple protocol for the exchange of data, supported by specific browser implementations and augmented over time as needed; ranging from security to new graphic formats to platform-specific features and functions.
Linked Lifecycle Data, as the OSLC conceives it, is defined and pursued in a similar fashion. All implementations are treated equally (just as HTTP treats all browsers equally); there is a technology-neutral, loose coupling between data and tool implementation. The design philosophy is also minimalistic, supporting resource exchanges as necessary, yet remaining lightweight. Over time, just as with HTTP, more value can be added to support emerging requirements. And, of course, OSLC standards are open—never owned and controlled by a particular company.
IBM is pursuing OSLC concepts by linking its Rational and Tivoli portfolios
Recently, IBM has made impressive strides in implementing OSLC concepts based on Linked Lifecycle Data. Specifically, IBM's Rational software development portfolio and IBM's Tivoli service management portfolio are being further integrated to yield new business value by improving collaboration between operations and development teams. The entire lifecycle of applications, from initial development forward, can in this way be addressed; application-driven services will become easier, simpler, and less expensive to manage while yielding better performance and higher customer satisfaction.
One recent example is the integration of IBM Rational Team Concert (RTC)—a complete, lean development environment—with IBM Tivoli Service Request Manager (TSRM)—a leading service desk solution. These two solutions represent key domains within IT development and IT operations respectively. And their integration turns a spotlight on IBM's remarkable value proposition in end-to-end application lifecycle management.
To understand how, consider the way application problems are commonly managed in many organizations today. Because there is no direct link between service desks and software development groups, it's operationally awkward to pass reported bugs or other issues from users (who experience them) to developers (who verify and resolve them).
The typical manual approaches used by organizations are relatively slow and, in some cases, poorly documented. Time is wasted communicating between teams as trouble tickets that began in operations are eventually duplicated in a second issue management system. Information can be lost or transposed during this duplication process, thus reducing the odds that the problem will be fully understood, documented, and properly fixed.
Fortunately, as IBM offers leading solutions in both categories, it's a relatively easy matter for IBM to bridge this gap. And OSLC's Linked Lifecycle Data concepts and implementations play an important part in making this a reality.
Specifically, IBM has linked TSRM and RTC using OSLC technologies as a liaison. Imagine that a serious problem is identified by the user community for a new application recently deployed to production. The users report this problem to the service desk, which uses TSRM as their ticketing system. Thanks to the OSLC-driven integration with RTC, the service desk team can direct the issue to the appropriate software development team by creating a ticket (defect) inside RTC (the development change management solution).
Additionally, the service desk team still monitors and manages the defect in the familiar TSRM interface, instead of having to master a new technology such as the RTC interface. When and if users ask for updates—"How long will it be until that bug is fixed?"—the service desk can quickly determine the answers and pass them along.
Much the same argument can be made from the other perspective—that of the development team using RTC. Because development's change management solution is directly integrated with TSRM, the development teams get new business insight on the impact of software issues as they currently manifest in production environments. Instead of a theoretical awareness that a particular bug might be creating problems, development will be able to see for themselves the exact number and nature of the service desk trouble tickets for which that bug is responsible.
This improved visibility will help the development team triage the issue, prioritizing development activities to better align with the organization's business requirements. Higher-priority problems will be solved more quickly, while lower-priority problems can be safely delayed.