Every tool we use has its own built in micro-process. Every development methodology we implement has its own macro-process. Our best practices for development are enshrined in the tools we use, the processes we follow and the ways we integrate all these together. When we get this right we can optimize the development effectiveness of our teams; when we get this wrong we risk quality, content and timescales. We all know we could do a better job at integrating but we are prepared to accept the limitations forced upon us and we come to depend on this fragile state of imperfection. When it fails, and it invariably does, what is the true cost of that failure?
So Many Tools Today
We have so much technology infrastructure underpinning software development today that, for the most part, remains unseen. Have you ever wondered what it takes to hold it all together? Have you any idea of the costs involved when it fails?
When we look at the average development organization we usually find a heterogeneous collection of tools from a variety of vendors. Some are modern
Advertisement
state-of-the-art technologies and others are legendary tools that we invested in years ago and which contain vital historical data about our development history.
Usually we find that that there are, as a minimum, seven main tool types in use and that number of different tools averages around 10 to 15. An aerospace and defense contractor in Europe told me he had almost 800 tools and a bank in North America told me it had over 200. I don't think that these are extreme cases - I think these companies are just better at tracking what software is actually installed. It is an interesting task to actually try and assess the real number and variety tools in use at your organization and to discover the vast array of tools individual developers have installed that they use once in a while to assist them in their tasks.
The 7 tool types we almost always find as a minimum set are:
An issue and defect tracking tool - often a spreadsheet
A project management tool, though this too might just be spreadsheet
An IDE - Eclipse-based tools and tools from Microsoft are predominate
Version control, software change or configuration management
Build capabilities
Automated testing
Some kind of deployment technology
This simple set is not enough to manage the complexity of today's development methods. It is common to find many additional tools in use and, invariably, many instances of similar tools from different vendors doing the same jobs. In order to develop the complex applications needed for today's business community we need these tools to be closely linked together and to provide handoffs of information, status exchange and shared ownership of the process of development itself.
What's Wrong With Integrations
We know just how important the integration of these tools is from a recent survey conducted at the CM Crossroads ALM Expo. When we asked the participants how important it is for a tool to be able to integrate with existing tools, 96% of the respondents rated it important, very important or critical (see Figure 1).
Figure 1: How important is a tool's ability to integrate with your existing tools when you are making a tool purchase decision?
We know that getting seven simple tools to integrate is going to require potentially 21 integrations and that the number, and fragility, of those integrations rises exponentially as each new tool is added. The question really is: how fragile are these integrations and how big a problem is it?
In the ALM Expo survey we found out just what the participants' experience was, and it quite surprised everyone. Nearly one in three of the respondents had experienced outages of two or more days in development productivity as a result of a failed integration of two or more two tools in the their development infrastructure (see Figure 2). These failures frequently occur due to upgrading of tools, applying fixes or patches and, too often, when underlying technology like operating systems and databases change.
If we assume that development costs are around $100,000 per developer-year this means that a two day outage is going to have an individual cost of a $1,000 per day. If we have 250 developers, we are looking at a cost of $500,000 for a two day outage. This is just the wasted effort time. The true costs of integration failures are the cost of delays to the project, the quality issues that will occur if we don't push the date out, the risk introduced by taking shortcuts to make the original date and so on. We rely so much on all this technology hanging together and when it fails it causes serious impact financially and organizationally.
Figure 2: Have you experienced an outage due to a failed integration of development infrastructure tools?
What was even more interesting was the response to the question about how organizations avoided these outages. Again, one half responded that they employ full-time staff to support and maintain the integration of vendor software (see Figure 3). Indeed one customer, a very large Swiss banking corporation, actually employs a staff of 20 to design and build complex integrations between vendors tools. This is a huge additional expense burden on the development organization but, as the customer tells me, it cannot afford to have any outages in its development efforts and it requires a very high degree of integration and interoperability of the vendor tools in order to meet the exacting regulations that are imposed upon Swiss banks.
It would be interesting to run this survey again and see if there is any intersection between the companies that have dedicated teams maintaining and supporting the developing infrastructure and those that have minimal downtime. It would also be interesting to see if the creation of these infrastructure support teams was as a direct result of a catastrophic infrastructure failure.
Figure 3: How many staff do you employ to support and maintain integrations between vendors tools?
What Do We Want From Integrations?
This is really a serious state of affairs. With so much heavy reliance placed on the infrastructure, everything is a critical issue now. We need to develop some best practices for developing the integrations and ensuring the infrastructure meets out needs.
I believe the critical task of infrastructure is to support the development process from end-to-end. This places the emphasis much more on the process than on the feature and functions that the tools provide. If we think about it for a moment, all the application lifecycle management (ALM) toolsets are about implementing the process of development. Herein lies the main frustration with many out-of-the-box integrations: they implement a generic, usually inflexible, and often simplistic process. Today's development processes follow complex, interdependent practices and are in a constant state of improvement. If the tool has a rigid implementation of the process it is of little use.
The best practice for integrations needs to implement process first. Each development shop's process has been developed over a number of years and is keenly designed to meet the cost, quality and risk priorities of that organization. That organization has what we might call a "macro-process" that defines the overall process as it hands off from requirements to design to development to testing to deployment. Tool integration has to not only support that macro-process it has to be flexible enough adjust as the macro-process is evolved.
What each tool must then provide is a detailed process capability, a "micro-process" if you will, which further implements the organization's development methodology. Just like the macro-process the micro-process is also subject to improvement so not only must the tool's ability to be integrated be flexible but the tool itself must be process-flexible. In this way the business can continually improve its delivery methods and know that the tools will keep pace with that.
Note that nowhere do we see "feature and function" are as critical as the ability to support process in tool selection. The mantra of tool selection needs to be:
Process First: Tool Second
Some of today's ALM vendors have realized the truth that ALM is a process and this is why we are now beginning to see a new generation of process driven tools. This is a very important evolution in ALM as it empowers development communities to exploit the latest technology innovations and to do so without having to compromise their development best practices and processes.
As process become the central point in selecting tools we need to have a process-centric integration framework for these tools collaborate against. Proprietary frameworks are passé and only benefit the software vendor. Open Process Centric Interoperability will become the watch word for tool selection and is the critical step needed in bringing reliability and robustness to development infrastructures.
In the future, Humpty Dumpty will be part of the wall; the process and the infrastructure will be bound together as one. We won't need all the king's horses and all the king's men and all the vendors' support analysts to put Humpty together again. We'll just need a macro-process definition and a set of process-centric tools to implement the micro-processes.
About the Author
With 25 years of industry perspective Kevin has been framing and shaping technology direction both in the US and his native UK. He is currently Vice President, Market Development and Evangelist at Serena Software. He is a sought after speaker and spoke at 50 conferences last year in 11 countries.
