Open source projects excel at creating high quality software within a social coding environment, which is why many IT managers are wondering what needs to be done to experience the same level of social coding success internally. Success tends to boil down to the people, the method and the tools organizations are using, and one of the new tools that is delivering ALM success is the concept of the software lifecycle integration bus for development.
Application Lifecycle Management (ALM) has always been something that sounds good in theory. It makes sense that enterprise-class organizations want to have a firm grasp on the practicalities of designing, developing, deploying, managing and decommissioning each application in their portfolio. That's the only way to assess risks, costs, ROI, and business value. But the factors that make ALM complex enough to be considered a discipline in its own right are some of the same ones that make comprehensive oversight and control almost impossible to achieve as things currently stand.
Why is ALM still unmanageable?
Dr. Mik Kersten, CEO of Tasktop Technologies, says the shining future of application lifecycle management for big business still hasn't materialized. "The industry's approach to looking at ALM hasn't worked. A decade ago, there was this promise of application lifecycle management. For some reason, the end-to-end connectivity and collaboration you get from a team of developers working on an open source project just doesn't happen at enterprise scales."
Several emerging elements in the software development field are probably to blame:
- The introduction of middleware ended the reign of single-source application vendors for enterprise and made multi-vendor solutions the norm
- As light work frameworks like SpringSource came into play, middleware got interesting and developers started taking over – wielding unprecedented levels of autonomy
- The proliferation of development tools (and the ability of developers to choose their own tools) greatly increased the potential for both individual increases in productivity and incidences of disconnect between developers
- The widespread adoption of Agile by project managers revved up the design/development/deployment cycle to previously unimaginable speeds
- The growing popularity of social coding, especially in open source, took collaboration to a new level
Understanding the disconnect in ALM
Enterprises know that having their data trapped in separate silos means they don't really have access to it for business analytics purposes. It turns out that a similar problem is holding back the realization of the ALM dream. There is a remarkable level of disconnect between the various tools developers are using in their ALM stack. The individual tools are reaching incredible levels of innovation and effectiveness, but each one is trapped in its own silo.
In fact, Kersten says he sees this issue all the time with his clients – including plenty of Fortune 50 companies. There are a huge number of manual integration steps that must occur for the developers' various tools to work together. This isn't just a problem with old-school elements like testing solutions being used alongside more recent tools. Even two completely modern social collaboration platforms like FaceBook and Google+ are often used at the enterprise level with no integration between the two – they reside in completely separate repositories that don't communicate with each other.
When the tools that should encourage productivity and problem solving via social coding don't work well together, people fall back to using email for collaboration. Kersten says this isn't how things are supposed to be. It's holding back enterprise software development. "Most of all, we want to enable flow. We need stakeholders to collaborate. We need social coding to turn into a social lifecycle."
What's the Solution to Pull Everything Together?
According to Kersten, we've actually seen a version of what a workable fix looks like before in a different setting. Infrastructure and specialists tend to arise over time to support new protocols. When SOA came into being, it wasn't long before enterprise buses followed. When middleware took its place at the heart of enterprise software, the need for an enterprise architect became apparent. The hero that rides in to save the day for ALM will be the Software Lifecycle Architect – an expert in everything having to do with both ALM and SLI (software lifecycle integration). The architecture itself will require the implementation of a software lifecycle bus.
All aboard the bus to enterprise ALM success
The SLB is "a new product category that enables the real-time and event-driven flow of information across the software delivery chain." It treats collaborative software development as a conversation in which everyone can participate without the need to pass messages through multiple channels. Social coding conversations facilitated across the bus can occur between any two tools or platforms. No more redundant data entry or manual transfers of relevant information between tools means no more missed opportunities. The silos are gone. Each tool is connected to every other tool via the bus. The SLB itself is actually an invisible layer. It merely pushes collaborative data for social tasks into the system each developer or stakeholder is already using. This means everyone can still use their favorite tools and adoption is likely to be high.
The concept is deceptively simple – a hallmark of most good ideas. The development and implementation will be a lot more involved. That's why enterprises will be counting on organizations like Tasktop to figure out the overall architecture as well as the technical details. Let's hope they can get it right, and get it right soon.
To learn more about what Kersten's team sees as the future of the SLB, read the highly informative whitepaper on Software Lifecycle Integration Architecture here.
How has social coding helped the software development process in your organization? Let us knowyour experience.