Talking with an old colleague about software project measurements and software project management dashboards, I was reminded strongly of my very first professional software development project almost twenty years ago.
It seems that if you work in the software development industry for any length of time, you find yourself solving the same sort of problem over and over again. In fact, the whole premise behind the idea of analysis and design patterns requires that you do. A key skill is the ability to abstract lessons learnt solving a problem in one context and apply them to a similar problem in a different context.
My very first project was a management system for an oil-fired, electricity generation station in the UK. Each of three servers was connected to a massive turbine by hundreds of i/o devices. These devices monitored all sorts of temperatures, pressures, revolutions per second, switch positions and indicator levels. Each server collected, processed and presented this raw ‘real-time’ information in different forms on workstation screens in an operations room. The three turbine servers also pumped information into a database on another central server for post-event analysis, maintenance and operations planning, efficiency level monitoring, cost predictions, and all sorts of other engineering and business analysis.
In comparison, most software development projects will have ‘management’ servers such as a:
- Configuration management server with version-controlled files, requirements, tasks and change requests
- Requirement Management server with hierarchies of different types of requirements
- Test Management server with its own view of requirements plus test definitions, schedules and results.
- Other repositories in addition or instead of those above
These servers are constantly collecting, updating, retrieving and deleting data about software development projects. Like the power station monitoring system, each software development server presents both ‘raw’ and processed information to users interested in what is happening in one project or across a set of projects at the current time. Also, like the power station monitoring system, there is a often some sort of management server collecting data from these various operational servers for more sophisticated management reporting, dashboarding, and time and event based analysis.
We could go on and on about the similarities between the software management servers and the power station system, comparing things like:
- deciding the appropriate sample rate for an input,
- the use of color-coded displays to communicate exceptions and grab the attention of users,
- deciding on push or pull data collection/extraction,
- examining rate of change as well as the current value of an input
- etc, etc
However, the initial thing that grabbed my attention was the obvious big conceptual difference between the two architectures. The difference is the cross-functional nature of the servers in the power station system in comparison to the generally single function nature of the software development servers. The servers in power station system collected data about all aspects of one and only one turbine. There was not one server for temperatures in all three turbines, another for pressures, another for speed, etc. In other words, the servers in the power station system were cross-functional. The servers in a typical software development enviornment are typically dedicted to a single function.
The obvious benefits of cross-functional servers are:
- Localized impact of failure:If one of the turbine
servers fail, two turbines can continue operating but if a key
software development server fails numerous projects are likely to
be negatively impacted. Imagine the impact on the active
development projects across an enterprise if the central
enterprise-wide configuration management service goes down for a
few hours, or a centralised requiremetns management service grinds
to a halt.
- Better scalability:If we need to add another turbine to
the power station, all we need to do is simply add another server
to monitor it. Adding another project to our software development
servers requires creating a new ‘project’ in each
server and linking those new projects together through various
integration points. There is often a practical limit to the number
of projects a single server can service and therefore a finite
limit to the scalability of a so-called enterprise server. Where
servers support a single project, additional projects are supported
by the straight-forward addition of additional servers.
- Better encapsulation of items being monitored:In some
ways, the power station servers were very object-oriented. Each
server presented an encapsulated view of the turbine it was monitor
to the operators and the engineering database server. It took a
number of years to install the turbine servers because it required
each turbine to arrive at its scheduled refurbishment. As a result,
we installed slightly different versions of the server for each
turbine but this did not cause a problem because the interface
between them and the users and the engineering database server was
the still the same.
- Better easier security:Each team of turbine operators
accesses its own server and has no need to access the others.
Members of a software development project need user accounts on all
the software development servers. Each server requires the
appropriate user roles to be added for the project team and this is
often compounded by different security models for each server.
Since the servers are centralised and used by many different types
and scale of project, the security roles and privileges can become
complex, or, as is often the case, over-simplistic and restrictive
because the centralised admin team does not have the bandwidth to
manage a more complex environment.
The idea of cross-functional software development servers appeals to me because we want to encourage collaboration across disciplines in agile, cross-functional teams. In my opinion, each discipline using a different user interface to access their data in a different server discourages this. This is probably why during my five years at Borland, StarTeam was my personal favorite server-based product because it does span more than one discipline. More recently, Microsoft's Team Foundation System (TFS) also seems to be a move in this direction.
An old colleague, Phil Bradley, used to talk about cross-functional servers as a ‘Project in a Box’. As I understood it, his vision was of a project manager walking into a new project area with a Unix server containing all the software he/she needed to run that software development project. Power it up, enter details of the team, their roles, configure the key characteristics of the project, and you were up and running. Even better if, once running, the server could also automatically locate the project management ‘warehouse’ server and start to communicating measurements to it for higher-level analysis and project portfolio management.
Obviously, there would be certain logistic problems caused by the use of physical servers but with server virtualization most of the problems with physical boxes no longer exist … and maybe the idea of cross-functional servers for software development projects is not as difficult as it might once have sounded.