Tasktop Technologies' new open initiative, Software Lifecycle Integration (SLI), aims to make integration a core focus in software development and management, rather than a post-production afterthought. At EclipseCon Boston 2013, Tasktop proposed a new Eclipse Mylyn m4 open source project to support SLI, as well as introduced a common data model and technical architecture.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"SLI describes the growing need by companies to integrate not only their applications, but also the tools that are used to build these applications," said Dave West, chief product officer for Tasktop Technologies and former Forrester Research vice president and research director. In this Q&A, West discusses how automating the integration of businesses analysis, project management, development, testing and operations and to connect inside and outside the company creates development practices that facilitate a seamless flow from idea to implementation.
How does SLI play out in real life?
Dave West: Perhaps the best way of describing SLI is to provide an example of a customer I recently spent time with. This customer is a classical IT organization. There are a project management office (PMO), business analysts (BAs), development, QA and operations. At all levels, employees are using different tools and practices.
They have adopted Agile, but the change has run aground outside of development. Increasingly, they are building Web 2.0 applications that [comprise] services, and they have an outsourced testing group that focuses on platform testing. It is a mess. The PMO has a plan that is always out of date. Development is doing a great job, but is always surprising operations, testing and the BAs with different software than was planned for. And management is finding it harder and harder to make decisions.
SLI is about connecting each of these groups, enabling work to flow seamlessly between departments, collaboration to be enabled and the PMO to report on the real status of the project. By automating the integration of the process of software delivery, you build an organization that can manage the increasingly complex world of modern application development.
What are the boundaries of software integration? Meaning, why might it be about more than integrating software?
I have been very disappointed with the reality of ALM deployments.
Dave West, chief product officer, Tasktop
West: Software integration is obviously the practice of integrating software, but it is much more complex than simply defining it as the technology necessary to enable integration. It means a fundamental change to the process, practices and manufacturing approach of that software. Building software for systems of engagement or systems of record means that your customers or the services you consume are first-class citizens. You need to build an approach that is modular and open to not only the software, but also the process of building and maintaining it.
The old, closed systems for software delivery should be replaced with Agile: open, connected approaches for software. Building for software integration requires [what I call] SLI to be a part of an organization's software development kit bag. SLI is a set of practices and technology that allows practices, processes and tools to be integrated.
Speaking of an organization's software kit bag, how does Software Lifecycle Integration fit into application lifecycle management (ALM)?
West: Definitions of ALM vary. Assuming you are taking the standard definition from Wikipedia, SLI enables ALM in the world of heterogeneous tools and disconnected processes. ALM assumes integration, but the reality is that integration is difficult and needs to be focused.
You could say that SLI puts the L in ALM by integrating the tools and practices that comprise the lifecycle. While I have always preached the need for ALM, I have been very disappointed with the reality of ALM deployments.
ALM idealized the idea of providing a holistic application of business management to the practice of software delivery by integrating the disciplines of requirements, development, test, management and deployment. But in reality, ALM was a means for a large vendor to drive sales of its tool. ALM for a long time meant 'buy one tool and replace every other tool.' But for many organizations, the reality of software development is that there will always be a large number of tools. Add to that the complexity of assembling services in the context of a software ecosystem, and you cannot even control the tools in use in the development of your application. Outsourced testing and development adds yet another dimension of complexity. Thus, SLI enables ALM to be successful by integrating those tools and drives the integration of the practices being used. By automating the integration of the tools, tough questions about the process need to be asked. Answering those questions ultimately improves the flow of work in your software delivery organization.
How does a software delivery group go about SLI?
West: If you think about SLI as a recipe, then there is some prep work before embarking on SLI. This includes thinking of software delivery as a key business process and getting some objectives and ownership of that process. I think it is ironic that application development was crucial in the automation of many business processes, but the process of software development itself was never really automated.
Once an organization has a clear understanding of its software delivery business process's focus and ownership, they need to describe it in terms of a process and data model. I am not proposing that an organization should spend months drawing lots of process models and data models, but spending an afternoon in a room with a few key stakeholders, exposing the data model and high-level process model, adds value. Once the model is described, look for opportunities that would be easy to improve. For example, connecting development and testing to replace the defect spreadsheet might be a great place to start.
Once the list of improvement areas is created, you then have to make some decisions about how to initiate the integration. Unless you have an ALM architect, this is a great opportunity to involve the integration architect or EA [enterprise architecture] group. The ALM architecture should describe the integration strategies and tools [that were] integrated with and how external groups, such as outsourced testing or open source development, fit into this process. Once the architecture is complete, it is a simple project to implement the integration strategy. One thing to be mindful of is ensuring that integration benefits are clearly measured and reported upon. This information should feed back into the process-enabling analysis of the engineering manufacturing process.
What is the business case for SLI?
West: When thinking about SLI, I tend to focus on two main business drivers: operational efficiency and risk mitigation. Improved flow, collaboration and transparency aid operational efficiency, and better risk management is served by improved traceability, reporting and analytics. SLI provides a firm foundation for enabling software-driven business innovation by allowing teams to work with partners and their business sponsors in a smooth and Agile way.
But there are also simple improvements made by automating integration. For example, replacing a manual spreadsheet that takes the team eight hours to create will have direct savings of the teams' cost multiplied by eight. These simple examples of cost savings provide a great baseline for the overall value of SLI.