Disjointed tools have inundated the application lifecycle. At its roots, tool diversity is a good thing. Over the past few years, it has transformed the way software is built via Agile methods, open source tools and differentiating vendors. But it has also wreaked havoc on the decade-old promise of Application Lifecycle Management (ALM). We need a new kind of infrastructure to deliver on that promise in a world where developers get to choose the tools that make them most productive. The time has come for an integrated lifecycle bus that allows information to flow freely between developers, testers, business analysts and administrators. This infrastructure will enable us to connect the best offerings in ALM in order to create a Lean Software Lifecycle, and implement a build-measure-learn loop that connects business idea to app store, and back again. We need a set of common data models and architectural patterns. Most importantly, we need to establish the common artifact that will connect the lifecycle. We are calling the category of infrastructure that will enable this Software Lifecycle Integration (SLI).

When outlined on a whiteboard or diagram, the architecture of today’s ALM stack resembles a half-eaten bowl of spaghetti, with meatballs corresponding to the various tools selected by stakeholders. We have two choices, either find a way back to the homogenous and single vendor solution of the 1990s, or embrace heterogeneity and come up with an infrastructure that provides end-to-end collaboration and traceability across best-of-breed tools.

Not long ago, we witnessed a similar transformation of the app dev stack. Once the services, databases and app server space enabled heterogeneity, the middleware category materialized and the Enterprise Service Bus (ESB) emerged, along with the new title of “Enterprise Architect”. History doesn’t repeat, but it does rhyme. It’s now time to create the role of the Lifecycle Architect, and to define an architectural framework for connecting the software lifecycle. Just as the notion of services was key to enabling the ESB, and file and documents abstractions were to sharing data, we now need an abstraction to connect the software lifecycle and to create a Software Lifecycle Bus. That abstraction is the social task.

Today Tasktop is a kicking off an effort to bootstrap the SLI discipline, with a series of whitepapers discussing the technical architecture, common data model, and technical tools. We are proposing the Eclipse Mylyn m4 open source project as a home for collaborating on a de facto implementation of the SLI data model, which will leverage what has been learned from the adoption of Mylyn, integrations that build on it, and new efforts around the open standards of Linked Data and OSLC. Later this week we are also launching an SLI integration patterns catalog, based on existing input from our customers, and open for all to contribute to. By the end of the week, with input from key thought leaders present at the ALM Connect subconference of EclipseCon, we plan to release a first draft of the SLI manifesto. To learn more and to participate, see:

	Whitepaper: Building the Business Case for Software Lifecycle Integration
	Whitepaper: Software Lifecycle Integration Architecture
	Software Lifecycle Integration landing page
	Eclipse Mylyn m4 Project Proposal Draft
	SLI Patterns Catalog Wiki (to come)

Learn more about SLI

v0.5.0, March 25, 2013

Download the whitepaper

Overview

Software delivery is plagued by disjointed siloes of information spanning software stakeholders and suppliers. The tool diversity that is the norm of today’s Application Lifecycle Management (ALM) stack brought with it productivity benefits for stakeholders such as developers, who have influenced the selection of the tools that make them most productive. However, the stakeholder-specific selection of best-of-breed tools has also undermined the decade-old promise of ALM. The lifecycle stacks of today are more fragmented than they ever were.
Imagine an integrated fabric that allows information to flow freely and in real-time across the stakeholders, tool siloes and vendor boundaries that define software delivery. We call that vision Software Lifecycle Integration (SLI). When the application development stack became overly complex, the role of the Enterprise Architect became clear, and a new discipline and middleware tool category formed. Just as connecting the back-end services that power our organizations required the creation of an Enterprise Service Bus (ESB), connecting software delivery requires an Application Lifecycle Bus (ALB). In addition, for the SLI category to form, we need:

	A role to be responsible for it, the Lifecycle Architect
	A taxonomy of integration concepts, types and approaches
	A common data model for SLI
	A lifecycle bus architecture
	Integration patterns

The goal of this whitepaper is to provide an initial version of the above for the emerging Lifecycle Architect role, to define a set of architectural concepts than the Lifecycle Architect can use to plan SLI deployments, and to bootstrap the conversation evolving around the SLI discipline.

Lifecycle tool diversity

Software integration is not new. In the 1990s, when application development stacks became more complex by combining application servers, legacy systems and databases, often from different vendors, Enterprise Architecture and Middleware came of age. A decade later the Enterprise Service Bus (ESB) became a core part of the enterprise stack. These technologies focused on the integration of application runtimes and of application data. With today’s rise of the API Economy, we are now seeing a resurgence of both the need to connect application and behavior in the cloud.
On the application and data integration layer, we’re in good shape. The trouble lies on the Application Lifecycle Management (ALM) part of software delivery, which is not about getting the application to run, but about developing and evolving the application over time. In ALM, we have seen a decade of promises of a connected lifecycle, with many a great vision outlined but never a realization of ALM that has lined up to customers’ needs. Where we are today is that organizations who have more than 500 developers have ALM stacks that are connected by brittle, manual, and combinatorially exploding point-to-point connections between vendors’ tools. This approach has not scaled and has now become the bottleneck on ALM adoption. Worse yet, the end-to-end software delivery cycle is only as productive as it’s bottleneck, and while Agile, mobile, cloud and open source are transforming the way developers build and deploy software, little has been done to address what organizations now see as the main bottleneck on software delivery, the disconnection and communication impediments in the software lifecycle.

Accidental vs. fundamental diversity

The root cause of the disconnected lifecycle is tool diversity. If an organization could procure the ultimate ALM suite from a single vendor, and meet the needs of every stakeholder, there would be no need for SLI. However, tool diversity is now the norm, not the exception. Diversity is also the sign of a healthy ecosystem. We have witnessed this in the coming of age of Agile as well as the new breed of developer tools, where competition, low-cost and open source entrants, and innovative vendors abound. The result is that two types of lifecycle tool diversity exist:

• Accidental diversity: This includes all of the heterogeneity in the tool stack that does not support organizational needs. Tools inherited as a result of M&A activities, or independent selection of similarly functioned tools due to a lack of centralized governance, fall into this category. For example, an organization could have three bug trackers, one a 20 year old legacy tool created in house, another the new developer-favored issue tracker, and the third an open source issue tracker that resulted from an acquisition.
• Fundamental diversity: All heterogeneity that adds value to the lifecycle by adding to the productivity of software delivery. For example, an organization developing a Ruby on Rails app may be using Redmine, while Java developers within that organization are using JIRA, and .NET developers TFS.

Benefits of tool diversity

Lifecycle tool diversity allows organizations to assemble best-of-breed stacks that meet the varying needs of stakeholders in the lifecycle, and that align to platform demands. Key benefits of fundamental diversity include.

	Specialized tools: The various stakeholders of software delivery require different tools to be effective at their particular discipline. For example, developers need customizable tools integrated with their development environment. In contrast, business analysts may want browser-based tools with the latest user interface mockup capabilities.
	Right-sized tools: Some tools have become specialized to organizational size. For example, a new Agile planning tool may be great for a dozen teams, but a traditional PPM tool is often needed for planning across very large numbers of teams. Similarly, a cutting edge lifecycle tool may be suitable for new development projects done by a small set of teams while enterprise-scale lifecycle tools remain the corporate standard for core products.
	Platform affinity: Lifecycle tool vendors who provide a development platform often provide an ALM on-ramp onto that platform. For example, an PaaS platform can provide deployment automation functionality, while a mobile platform can provide app store integration. As such, an organization creating a hosted back end for a mobile client may end up with two sets of ALM tools, each optimized for the development platform experience.
	Vendor diversity: Different vendors specialize at different stages of the lifecycle, and target different development styles. For example, some vendors specialize in supporting cutting-edge Agile trends, while others focus on tried and proven features. An organization may choose to have both deployed if the goal is to prove out a new flavor of Agile in a part of the organization, especially across different horizons of R&D.
	Supplier diversity: As outsourcing and consumption of open source software increases, it becomes either impractical to expect software suppliers to use the same ALM tools as the sourcing organization. For example, open source projects tend to use open source ALM tools, while small suppliers tend to use lightweight issue trackers in place of the enterprise ALM tools needed for large scale software delivery.
	Support for legacy: The cost and disruption moving away from a legacy system, such as an older tool or in-house defect tracker, can be overly high to take on during a lifecycle modernization. Allowing the legacy system to interoperate with the new systems enables a more incremental migration path.

Costs of tool diversity

A core challenge of software delivery has been that, without a suitable integration layer, the business benefits of diversity are thwarted by the costs of a disconnected lifecycle. These costs boil down to undermining the promise of ALM itself, as the benefits of ALM tools can only be realized with a sufficiently connected tool chain. Key problems caused by a heterogeneous stack that lacks integration include:

	Lack of traceability: Due to information being siloed into disparate systems, it is impossible to get cross-system traceability. For example, business requirements are disconnected from user stories which a disconnected from source code. Once a support ticket is filed with a major defect affecting a particular line of source code, the affected requirement cannot be determined. The less traceability there is in software, the more expensive the software is to maintain.
	Lack of visibility: Reports, dashboards and planning tools only have visibility into the repositories that they were built on. For example, reports in an ALM tool fail to see defects tracked in the Quality Management tool and dashboards connected to a data warehouse are missing data from the lifecycle tools that do not provide a direct integration. Lack of visibility makes it impossible to effectively manage a software portfolio.
	Limited governance: Governance, workflows, or compliance processes cannot be implemented across tools. For example, a compliance workflow implemented in a centralized ALM tool is not enforced in a lightweight issue tracker used by a large portion of the organization’s developers. Without governance, software delivery cannot be adequately connected to other business processes.
	Manual processes: Without an integration layer, end users often need to enter data into two tools, reducing end user productivity and affecting data accuracy, and rendering automation impossible. For example, creating requirements links between one tool and another, or entering time sheets into a PPM tool while the Agile tool is intended to be the definitive record of time tracked at a finer level of granularity. The lack of automation has individual stakeholders wasting time on manual entry, and impedes the deployment of lean methodologies.

Signs of lifecycle failure

Without an adequate integration layer, the following anti-patterns occur in the software lifecycle. Each of these contributes to the costs listed above by preventing the end-to-end flow of information across the lifecycle stack.

	Manual processes: Duplicate data entry and any other manual entry becomes the bottleneck of the lifecycle. These include excessive status reporting meetings, or status updates via email and spreadsheets.
	Batch jobs: Attempts and connecting the lifecycle that periodically reconcile data models across tools, but result in numerous conflicts and make cross-silo collaboration impossible.
	Custom solutions: Integration provide by services vendors or internal teams that result in brittle, costly to maintain and upgrade with frequent releases of ALM tools, creating lock-in to old versions
	Point-to-point integrations: Integrating two systems directly, with no abstraction in between, results in a brittle system that does not scale, resulting in batch jobs, conflicts, and other workarounds.

In the following section, we will examine the architecture goals and principles of a connected application lifecycle.

Software integration architecture

This section provides an overview of the SLI architectural concepts, including goals, the role of the Lifecycle Architect, and the integration types and data model.

Goals of integration

The goal of SLI is to help organizations create a lifecycle that seamlessly connects all of the disciplines, stakeholders and suppliers involved in software delivery. This enables the benefits of diversity while mitigating the problems. The benefits of an integrated software lifecycle include:

	Insight: The ability to deploy metrics, reports, and lean methods across the lifecycle. For example, implementing a lean build-measure-learn loop, from idea to customer validation.
	Traceability: End-to-end and cross-system linking of lifecycle artifacts. For example, all code, tests, branches are linked to business requirement, regardless of system heterogeneity.
	Flexibility: The ability to deploy new lifecycle management systems, and to retain legacy systems while modernizing the stack. For example, if a new mobile platform is being adopted for a new application, the lifecycle tools specific to that platform can be used.
	Flow: Real-time flow of social and status information ensures stakeholders work within their system of choice while being connected to collaborators in adjacent parts of the lifecycle. For example, as soon as a tester comments on a defect, requesting more details on steps to reproduce, the support engineering sees the comment within their system.
	Governance: While end-users get to work in the systems that make them most productive, the organization needs cross-lifecycle governance and workflows to function across systems. For example, policies and workflows can be implemented to define the cross-repository status and record updates that a creation of a defect results in.

The role of the Lifecycle Architect

When the complexity of software applications and the enterprise systems that they depended on grew, middleware formed as that glue that could connect end users to systems and data. In this transition, the role of the Enterprise Architect (EA) emerged and became a key technical stakeholder in the delivery process. It’s now time to define the Software Lifecycle Architect role to own this role, and to coordinate the activity of mapping the business of process delivery onto the Software Lifecycle Architecture. This architect’s goal is to define the stakeholders, workflow model, feedback loop that spans the systems and stakeholders that make up the lifecycle.

Lifecycle integration types

SLI breaks down into the following four types of integration, delineating the different silo boundaries and layers within a typical software delivery organization. The applicability of integration types varies with the size and amount of software delivery being done by the organization. For example, a small organization should have little or no “within discipline” integration needs as developers should be using a single tool. But it may have a need for “cross lifecycle stage” integration if testers are using another tool, or “cross-organization” integration if testing is being outsourced.

Integration architectures

Since the software lifecycle is about connecting stakeholders, a distinction needs to be made between the tools used by practitioners and where the data is stored. This distinction originates from Geoffrey Moore’s discussion of Systems of Record vs. Systems of Engagement.

• System of Record (SoR), aka Repository: Encapsulates all back-end services and data storage, typically exposed via API. For example, the database and REST APIs of an Agile planning tool.
• System of Engagement (SoE), aka UI: End-user facing system that supports interaction and provides a user interface. For example the mobile client, browser-based UI, or desktop-based developer IDE.

Part of the challenge of SLI is that most of today’s lifecycle systems have a coupling between the SoR and SoE. In contrast, Microsoft Outlook is an SoE that’s decoupled from its SoRs via email protocols, such as Microsoft Exchange and IMAP.
All of the integration types listed above can be achieved by each of the following integration architecture types. However, each has a set of tradeoffs, and potentially tool-specific limitations. For example, an Integrated Development Environment (IDE) based integration connect developers to testers to provide “cross lifecycle stage” integration. However, it is limited to developers if testers do not use a federated SoE such as an IDE, but instead use an SoE specific to the testing SoR, such as the web UI or rich client of the testing tool.

These integration architectures are not mutually exclusive and can be applied in conjunction. For example, a federated User Interface integration can augment an integration bus to show cross-system artifacts. An integration bus can, and should, build on open standards where possible.

SLI data model

Independent of integration type, any non point-to-point integration must support a common data model for the purpose of querying and interchanging lifecycle artifacts. We decompose this model into two main types of artifacts. The focus of SLI is to provide a data model for connecting SoRs via “tasks”, their social communication streams, and contexts that link the relevant assets.

 

 

Two main types of relationships exist between these artifacts:

• Containment: Artifacts of one type can contain artifacts of another. Eg, tasks can contain subtasks, requirement definitions can be broken down hierarchically.
• Linking: Tasks can be linked to assets, and vice-versa. Eg, a source code commit links to a user story, a requirement links to all tests that cover it and code changes that implement it.

Software lifecycle bus

Integration is not a new problem. However, solving the problem for the software lifecycle imposes a new set of constraints. In addition to connecting data sources and schemas, the flow of communication must be integrated. The software lifecycle is a conversation, and as such, the primary concern for SLI is to connect conversations across siloes and to model this flow. To do this, we propose that in addition to other integration architectures being deployed a software lifecycle integration bus is a required part of the architecture needed to meet the integration goals of large-scale software delivery. This new kind of bus infrastructure for the software lifecycle is something we refer to as the Software Lifecycle Bus (SLB), a new product category that enables the real-time and event-driven flow of information across the software delivery chain. In this section we discuss the requirements of the bus, as well as deployment and implementation concerns such as storage topology and failure tolerance.

Bus requirements

In order to meet the goals of SLI, the lifecycle bus must meet the following requirements.

	Vendor neutrality: Capable of connecting to a tool from any vendor whose API supports the SLI data model.
	Real-time communication: Support activity streams (eg, comment threads), identity and real-time activity propagation across tools.
	Interoperability: Must support common query and data interchange formats (eg, OSLC, Mylyn).
	Invisibility: End-users do not need to change their work practice or technical tools for the bus to function.
	Manageability: Must run unattended with automated conflict resolution and error notification system.
	Extensibility: Must support addition of connection points, business rules, and transformation semantics.
	Openness: Must be query-able and expose its data model using open standards, and support transformations to other data formats.

Bus capabilities

The bus needs to support connecting the following capabilities between the tools that it connects.

Storage elements

Since the bus is not a new lifecycle SoR, it cannot act as the storage for lifecycle artifacts. Instead, it should only store state needed for data consistency, workflow transition transactions, and performance needed to query and flow data across the tools that it connects.

Bus operations

The lifecycle bus enables a broad range of operations to be implemented on the information flowing through it. Some of the common operations are listed below.

Failure tolerance

While not a new SoR, the lifecycle bus connects systems critical to software delivery, and as such becomes mission critical to software delivery. If the bus supports write operations, it must also ensure data consistency for those operatinos. As such, the following failure scenarios must be supported.

Extensibility

Since the lifecycle bus is intended to integrate unforeseen end-points and mapping scenarios, it needs multiple layers of extensibility.

Conclusion

In today’s software lifecycle, information is locked into stakeholder-specific repositories. Our inability to make information flow both within the organization and across organizational boundaries is preventing the realization of Lean Manufacturing methods in software delivery, and in establishing the infrastructure for a software supply chain. To achieve this, we need an integrated fabric that allows information to flow freely and in real-time across between stakeholders, across the tool silos and vendor boundaries that define the software lifecycle. Creating the Software Lifecycle Integration (SLI) discipline, architectural frameworks and technical tools will provide organizations with the lean methods that will scale software delivery, and pave the way for an integrated software ecosystem.

Appendix

Data model validation

We have used the following sources of information and architectures in creating the models described below.

	Open source Eclipse Mylyn implementation and ecosystem of extensions: significant portions of the architecture have been implemented in Mylyn and vetted by it’s user and vendor community, which now includes over 100 extensions and 2M monthly downloads.
	Open OSLC standards: These standards are compatible with the underpinnings SLI data model.
	Commercial implementations: the Tasktop Sync tool implements the lifecycle bus architecture described here, and the data model has been validated by large-scale customer deployments of Tasktop Sync, as well as a customer-driven data model working group.

Open standards & OSLC

We are still in the early days of ALM interoperability standard adoption. However, standardization efforts have been improving, with the leading efforts supporting key aspects of the SLI data model:

	W3C Linked Data: preferred format for artifact linking
	OSLC: REST format for queries, cross-repository linking with rich tooltips OSLC-Core: Implements core query and… OSLC-CM: Implements the Task model OSLC-RM: Implements the Requirement and Requirement Definition artifacts in the model OSLC-QM: Implements the Test and Test Plan artifacts in the model
	File-based interchange (eg, ReqIF): limited in the task data that can be exchanged, typically simple fields only.

Eclipse Mylyn

The original goal of the Eclipse Mylyn project was to redefine the developer experience around the collaborative and social workflow of task-focused collaboration, and insulate them from the overloaded of non-development related features in ALM tools. The goal of the newly proposed Mylyn m4 project is to leverage the proven interoperability of the existing Mylyn model and to create a new de facto SLI model and reference implementation.

Download the whitepaper

January 17th marks the 6th anniversary of Tasktop’s inception, and has given me an opportunity to think about the past 6 years, and the next. All technological revolutions require a new kind of infrastructure. This decade will mark the shift to the software economy, with traditional companies turning into software delivery organizations. The problem is that, outside of ISVs who have glued together their own ALM processes, we’re not all that efficient at building software.

The generation before ours mastered building cars, managing just-in-time inventories of parts, as well as complex supply chains. And yet we’re still seeing software collaboration across companies and departments being done via spreadsheets and email threads, today’s equivalent of carrier pigeons. While the rest of the ALM industry sorts out the new generation of systems of engagement to make developers, Agile project managers and other stakeholders happy, Tasktop’s mission is to create the infrastructure that glues together this new breed of tools, with tasks as the new currency of planning and collaboration.

When staring out the window at our new Vancouver HQ, I often fixate on the orchestrated flow of cargo ships routing containers–the abstraction that has come to define the shipping industry. Rob Elves, co-founder of Tasktop, joins me in the picture below, as we were reflecting on our journey of the past six years. We validated the need for a layer of infrastructure between the developer and the various ALM servers by shoehorning it into the Eclipse desktop client and giving it a single and collaborative UI called Mylyn. That paved the way for our first commercial product, called Tasktop Dev, whose success was not just in laying our commercial foundation and revenues that drove our growth, but in allowing us to learn what a mess software development outside of the IDE really is. In our mission to connect the world of software delivery, the next step became overwhelmingly clear. A new infrastructure for connecting the software siloes within the organization, and increasingly across the chain of software suppliers, is now the bottleneck. Even the cars that previous generations learned to build so well now depend on dozens of software suppliers working together. Without automating the interaction between these suppliers in a way that supports collaboration and lean delivery across organizations, innovation is being stifled.

As Neelan reported in the Tasktop Year in Review, 2012 was huge for us with with 250% growth since our last birthday. A portion of the year went to thinking about what shape this new task “container” has in the software lifecycle. But it’s now clear that the problem is not the container, as the Mylyn model is nearly expressive enough, and our work with IBM in OSLC and W3C Linked Data is a good start to defining things like common query APIs. It turns out that the biggest gap is the lack of infrastructure for shipping this information between people and tools, and supporting the many previous attempts by each vendor in defining their own APIs specific to their specialization in the software lifecycle.

In 2012, Sync became the lifecycle integration platform of choice for numerous Fortune 100 companies. We got to learn what it was like to be building infrastructure and digging canals between vendors while becoming a mission critical component of the stack, which resulted in Sync’s transition to an enterprise-scale lifecycle integration bus. We’re looking forward to scaling this new kind of collaborative infrastructure in 2013, and making your software lifecycle as orchestrated as the flow of container ships through Vancouver’s magnificent harbor.

Agile has come of age, gone mainstream and, as evidenced by recent releases from our partners, the ALM landscape has permanently changed. This fall we saw the release of TFS 2012, RTC 4.0, and last week HP’s Agile Manager (AgM). These tools provide large-scale software delivery organizations with the latest and greatest features for each of the software delivery roles that they support. Tasktop 2.5 release is a roll up of new Tasktop Sync and Dev functionality that we now provide in order to allow organizations to make the most of these tools when adopting them for heterogeneous ALM environments. We have worked very closely with each of our partners in order to ensure that Tasktop is able to provide it’s real-time connectivity and collaboration flow for stakeholders whose roles span individual tools.

Tasktop Sync now has full support for Rational Team Concert 4.0. Our partnership with IBM was expanded recently by way of IBM OEM’ing Tasktop Sync (called IBM RLIA Tasktop Edition) in order to support their customers’ integration needs. Tasktop Sync ensures that those deploying RTC into a heterogeneous environment get the benefits of RTC across the myriad of tools being used for end-to-end software delivery.

While Microsoft provides one of the most vertically-integrated ALM offerings, the reality of today’s software delivery is often multi-platform and multi-vendor. This means that some developers will be building the back-end with .NET and Azure with everything tracked in TFS, while the mobile ASP is being built by another team working in JIRA, and the whole lot is being QA’d and requirements managed by HP ALM/QC. Sync now supports TFS 2012, including the hosted version of TFS, which expands our support of cloud hosted integration end-points.

HP just released a brand new, cloud hosted Agile planning tool called Agile Manager. Tasktop Dev, OEM’d by HP as ALI Dev, has been extended to support Agile Manager, and can be seen showcased on stage at last week’s HP Discover conference (see Dave’s post for more on that). This means that developers get the first rate Eclipse and Visual Studio IDE experience for this new slick Agile project management tool.

In our role as the “Switzerland” of ALM, it has been exciting to see Tasktop work closely with each of these vendors, as well as our other partners, each of whom is defining a different angle on the tools that enable Agile software delivery at scale. As always, our goal is to create the task-focused infrastructure that supports real-time flow of information between users collaborating across this new breed of tools.

Get Tasktop Sync 2.5

Today the IBM Rational Lifecycle Integration Adapters Tasktop Edition appeared on the IBM price list. This OEM version of Tasktop Sync makes the technology broadly available to IBM clients using Rational Team Concert (RTC), who can now get all of the benefits of Tasktop Sync’s real-time and collaboration-centric ALM integration infrastructure. This helps IBM clients to successfully unify heterogeneous tooling environments with RTC capabilities.

Tasktop’s mission is to connect the world of software delivery by providing the cross-repository integration and infrastructure tools that weave together the numerous Agile, enterprise, and open source Application Lifecycle Management (ALM) tools present in today’s software delivery stack. To achieve this, Tasktop has been working very closely with the ALM community to help define the APIs and standards, such as Open Services for Lifecycle Collaboration (OSLC) and W3C Linked Data, which form the boundaries of the software value chain within your organization. Integration has become the main bottleneck to connecting the software lifecycle, and Tasktop has emerged as the “Switzerland of ALM”, with Sync becoming the equivalent of an Enterprise Service Bus for artifacts of the software delivery process.

We are thrilled to have this relationship with IBM to reduce the friction of getting the benefits of Tasktop Sync to the growing number of IBM Rational clients leveraging a rapidly evolving portfolio of enterprise Agile and ALM capabilities. With the Tasktop Sync infrastructure in place, RTC clients will be able to collaborate directly with other parts of the lifecycle, ranging from developers using lightweight issue trackers like JIRA and Bugzilla, to software development and testing suppliers using HP ALM or Quality Center. And the organization will get that critical unified traceability across the heterogeneous toolchain provided by RTC. Tasktop Sync is rapidly becoming the tool of choice for connecting software silos within the firewall and across the enterprise software supply chain.

The Tasktop and IBM relationship started during my PhD thesis, when Erich Gamma, a member of my thesis committee, one of the RTC architects, and I started to see how primary a role tasks (aka “work items”) had in connecting ALM artifacts. With tremendous effort going into creating the new systems of record for Agile and large-scale software delivery, which eventually led to RTC and the other modern ALM capabilities, we realized that Tasktop’s big opportunity was in using our common Mylyn-based model for weaving the various ALM systems of record together. That’s what developers see when they open up Tasktop Dev or Mylyn, and what the Sync bus is connecting when deployed in your ALM stack. Today we are officially connecting those dots by expanding our OEM partners to include IBM.

View the IBM product offering details, IBM product page or contact us to learn more.

In Total Quality Management, the 1-10-100 rule states that prevention is 10x cheaper than correction, and 100x cheaper than failure in the field. We usually apply this principle to our thinking around defects and as a driver for continuous delivery and feedback loops. However, in much of the Agile discourse these days, the traditional requirement gets left behind.

Development has been transformed, from the bottom up by open source and inexpensive tools like JIRA, and from the project management level down by the Agile movement. But in large-scale software delivery involving very complex products and supply chains, requirements are the tasks that connect strategy to shipping software. The trouble is that the tools that we use for requirements management are completely disconnected from the modern Agile delivery process.

Consider a requirement to add a web service API to an app. Sounds great when expressed in Microsoft Word with direction from the CIO. After being passed to development, SOAP technology is selected on the merit of being present in other parts of the product line. A few developers comment on the corresponding user story that SOAP is inefficient and could cause serious CPU overhead, but both the business analysts (BAs) and the Ops folks are well out of the loop as they never log into JIRA where the discussion is happening. The solution is deployed, passes basic scalability tests, then after going into production it becomes clear that the SOAP solution will not scale to support the projected user base without a massive new infrastructure investment. So three months after the requirement was defined, the business analyst gets to realize all of this, learns a new acronym (REST) and another round of implementation is scheduled for the upcoming sprints. That’s the 100x cost scenario that we see all too often. Had the BA seen some of the comments in JIRA, a lot of waste could have been prevented.

This problem was partly addressed a decade ago with the Rational Unified Process (RUP), which created a homogenous Application Lifecycle Management (ALM) stack from requirements right down to development. But that approach constrained developers to the point where the Agile and lightweight ALM tool rebellion transformed the landscape. We now know that an efficient application lifecycle is capable of leveraging best-of-breed tools, with stakeholders such as Developers, Business Analysts, Project Managers and Testers working in the individual tools that make them most productive. Until today, only a few brittle point-to-point integrations existed between requirements management tools and the rest of the ALM stack. With today’s release of Tasktop Sync with integrations for IBM Rational Requirements Composer (RRC), IBM RequisitePro (ReqPro), CA Product Vision, and improvements to our existing integrations for HP ALM and QC Requirements Module as well as Accept 360, requirements are now a first class citizen that can span the lifecycle.

While the new support for sync’ing requirements is the biggest part of the story of our ongoing quest to connect the world of software delivery, there are many more highlights to the Tasktop 2.4 release, including major new features for ALM integration administrators such as a web dashboard for monitoring and IBM ClearQuest support. To learn more see:

• Tasktop Sync 2.4 New & Noteworthy
• Tasktop Dev 2.4 New & Noteworthy
• New CA Agile Vision and Product Vision Connectors
• New RRC Connector
• New ReqPro Connector

Every now and then you have a conversation that changes your view of the world. I’ve now had a dozen of those with one person, Dave West, in his role as Forrester analyst, VP, and Research Director. The common thread in our dialogue has been the need for application lifecycle glue that connects the software lifecycle stakeholders within the organization, as well as across the multi-company and increasingly open source based software supply ecosystem. Both of us realized that it would be more effective to make this vision a reality than to discuss it endlessly. So today, I’m thrilled to announce that we’ll be doing just that, with Dave West joining Tasktop as Chief Product Officer.

The very rapid growth that our products have seen lately is indicative of the need to look beyond any single tool in the evolving ALM stack, and consider the flow of information between the people that define the disciplines of the software lifecycle. Tasktop got to where we are today by placing a manic focus on the needs of the individual software developer, who was getting completely overloaded with the disconnected morass of ALM tools that failed to connect to the source code that defines delivery. That forced us to create a new model of social tasks that emphasized autonomy, transparency and integration across the increasingly diverse tool chain. With Tasktop Sync, our Task Federation has migrated from supporting Agile delivery on the developer’s desktop to connecting the rest of the software lifecycle in order to bring about a “Lean ALM”.

Driving a change in the way that software is built takes like-minded people filled with passion and purpose. Dave’s mission is to help people build software just a little bit better, and with our shared values, we expect that goal to materialize very quickly. In his role as an analyst, Dave has heard the software delivery needs and gaps of countless software organizations that build the products and services that we all rely on day-to-day. In his role as Chief Product Officer, responsible for transforming that need into our product vision and roadmap, you can expect Dave to accelerate our pace of customer-centric innovation even further as we work with our partners and open source community to connect the software lifecycle.

Read more in Dave’s post and Neelan’s post.

EclipseCon 2012 was my favorite to date, and I’ve been attending since the prototype—beers and demos at Thirsty Bear during JavaOne 2002. What made it so interesting was finally getting all the Eclipse devs in the same space as key folks from Agile and ALM. Developers are the engine of the software economy. But that engine is becoming part of such a complex ecosystem of vendors and open source that to scale software delivery, we need to break down organizational and departmental silos. We need to move towards what Forrester analyst Dave West has coined a Lean ALM. And that’s what my keynote was all about. Connecting devs to project managers, to testers, and eventually to @DEVOPS_BORAT.

Some have objected to my statement that Linus Torvalds’ bigger contribution to our planet is going to be Git, not Linux. Yes, Linux is everywhere. But Linux was a creative imitation, whereas I was focusing on the true innovations that are moving us towards the social code graph, and that’s precisely where Git fits in. Also, early in the talk I mention that Eclipse has gone from 1.5M to 2.5M downloads between January 2011 and January 2012. That’s monthly downloads, and with Vietnam surpassing Germany, a clear sign of the times.

Watch the keynote here, and I look forward to hearing your feedback and ideas.

As organizations increasingly become software driven, the role of the application lifecycle is taking a new meaning. Connecting stakeholders in the software lifecycle ceases being a nice to have and any gap in connectivity quickly becomes the bottleneck of software delivery. The organizations are now noticing the friction of having developers do duplicate data entry between their issue tracker and Agile tool, or testers and business analysts queuing up weeks of defects and requirements before handing them off to developers. The application lifecycle is only as efficient as its weakest link, and if that link is manual and based on large batches and handoffs, frustration for the individuals and large-scale inefficiencies result.

With Tasktop Sync we created the first general way to connect software delivery stakeholders working in best-of-breed tools across the application lifecycle management (ALM) stack. As we’ve been rolling out Tasktop Sync over the past year to IT organizations around the world, we’ve noticed a number of things. Organizations, especially those who have been around for a while, are trying desperately to apply ALM Automation across the enterprise. To do this, these organizations are having to inventory their tool sets and identify the information flows and the workflows between stakeholders and between their tools, usually for the very first time.

Often acting as a cross between marriage counselor and coach, the Tasktop expert’s first activity in a deployment is to gather they key stakeholders from management, quality assurance, development, and business analysis in a room with as big a white board as possible. In this meeting, the organization will identify the important tools used by each stakeholder, how information needs to flow between these tools, what are the key workflows within each stakeholder silo, and what activities kick off workflows in other silos. The edges connecting the ALM repositories turn out to be various kinds of tasks that represent the lines of collaboration between the stakeholders, and that are then mapped between the various vendors’ tools with Tasktop Sync’s real-time ALM artifact synchronization solution.

In the forthcoming release of Tasktop Sync, we have formalized the lessons learned of the past year with a new authoring tool called Sync Studio. Our expertise is now captured in visual tools for cross-ALM system task and workflow mapping, ALM architecture design, monitoring tools to ease integration maintenance and alert notifications for project and system administrators. To help IT organizations scale Tasktop Sync deployments and better manage the growing number of ALM systems in a typical tool stack, Sync Studio provides a whole new set of ALM infrastructure management tools. Capabilities include:

		A Unified View across the ALM Stack: Sync Studio presents ALM architects and administrators with a comprehensive and “live” architectural view of current tools and processes, and the associated interdependencies and roadblocks that need to be addressed.
		Visual Mapping for ALM Administrators: Sync Studio provides automated mapping capabilities for ALM administrators to author and configure task, data and workflow connectivity and integration between ALM servers.
		Cross-repository Monitoring and Administration: Sync Studio helps maintain the health and performance of enterprise-wide ALM architectures through the regular monitoring of inter-tool functionality and centralized administration of changes, maintenance, trouble-shooting and alert notifications.
		End-to-end Traceability for the Lifecycle: through its Task Federation platform, Sync Studio provides complete ALM traceability that is available through the visual mapping and visibility capabilities now available in the tool.

Tasktop Sync is being announced today as part of our coordinated Tasktop 2.3 release. A notable feature from Sync the instantaneous task querying needed for Sync’s conflict resolution, is getting pushed down into Eclipse Mylyn for the benefit of our developer users as we continue to build out both the Tasktop commercial tools and the underlying Mylyn frameworks needed to support Task Federation, both on the server side with Tasktop Sync and on the developer’s desktop with Tasktop Dev and Mylyn.

Tasktop Sync 2.3

		Sync Studio: Visual Mapping, Monitoring, Validation and Notifications
		Sync Server: Scalability & failover support
		New connectors: Accept 360, ThoughtWorks Mingle, full RTC Schema support

Tasktop Dev 2.3

		New OEM Edition for HP Quality Center
		Mylyn 3.7, including instant Task List search
		New connectors: Gerrit code reivew
		See New & Noteworthy for more

Contact us for a demo of Sync Studio.

For the past few years I have served on the Eclipse Board of Directors as an elected representative. I’m running again this year in the sustaining member category to help represent ecosystem of organizations that have made Eclipse successful, and to continue to refine the constructive dynamic that we have created in marrying commercial and community interests.

2012 marks the start of the second decade of Eclipse’s existence. I’ve been a committer on Eclipse for the past decade and have watched as an IBM initiative created a platform that now dominates the tooling space for professional developers outside working outside the VS/.NET stack. The leadership and innovation of Eclipse have created the modern pluggable IDE, innovated the code editing and navigation experience, fostered modern modeling technologies, and led the way in connecting the developer to the Agile, ALM and social coding movements. With the recent announcement of the VS 11 beta we’re reminded again that innovation can be cyclical. The first release of Eclipse from a dacade ago, visible above with its monochrome UI and toolbars, looks strikingly similar to latest version of VS 11 just announced (image from the Visual Studio blog).

While the strength of Microsoft is packaging a seamless end-to-end developer experience on a monolithic stack, the strength of Eclipse comes from the innovation driven by the large number of vendors leveraging Eclipse for gluing together the developer experience on heterogeneous stacks. For this next year of Eclipse’s evolution, both adapting the way that we build that tool stack in the social coding context, and improving ways to support our ecosystem of both community and vendor contributions, will be my priority if elected.

See my full vision statement on the Eclipse Board Elections page.