We've groused repeatedly about the gaps in the software development lifecycle, or more specifically, that communication and coordination have been haphazard at best when it comes to developing software.
Aside from the usual excuses of budgets, time schedules, or politics, the crux of the problem is not only the crevice that divides software development from the business, but the numerous functional silos that divide the software development organization itself.
Software developers have typically looked down at QA specialists as failed or would-be developers; software engineers look down on developers as journeyman at best, cowboys at worst; while enterprise architects wonder why nobody wants to speak to them.
Not only do you have functional silos and jealousies, but the kinds of metadata, artifacts, and rhythms vary all over the map as you proceed to different stages of the software lifecycle. Architecture deals with relatively abstract artifacts that have longer lifecycles, compared to code and test assets that are highly volatile. And depending on the nature of the business, requirements may be set in code or continually ephemeral. No wonder that the software delivery lifecycle has often resembled a game of telephone tag.
A decade ago, Rational pioneered the vision that tools covering different stages of software development belonged together. But it took a decade for the market that Rational created to actually get named – Application Lifecycle Management (ALM). And it took even longer for vendors that play in this space to figure out how the tooling should fit together.
What's interesting is that, unlike other more thoroughly productized market segments, there has been a wide diversity among ALM providers on where the logical touch points are for weaving what should be an integrated process.
- IBM/Rational has focused on links between change management, defect management, and project portfolio management
- Borland’s initial thrust has been establishing bi-directional flows from requirements to change management and testing, respectively
- Serena and MKS have crafted common repositories grafting source code control and change management with requirements
- Compuware attempts to federate all lifecycle activities as functions of requirements, from project management and source code changes to test and debugging
But what about going upstream, where you define enterprise architecture and apply it to specific systems? That's where Telelogic has placed its emphasis, initially tying requirements as inputs to enterprise architecture or vice versa.
It has now extended that capability to its UML modeler and Java code generation tool through integration with the same repository. What would be interesting would be generation of BPMN, the modeling notation for business process modeling, that several years ago joined UML in the OMG modeling language family. For now, Telelogic's Tau can generate UML from BPMN notation, but nothing more direct than that.
In looking at the different approaches by which vendors integrate their various ALM tooling, it's not just a matter of connecting the dots. The dots that are connected represent different visions of where the most logical intersections in the software delivery lifecycle occur. Should the lifecycle be driven by enterprise architecture, or should we drive it as a function of requirements or testing? Or should we skip the developer stuff altogether and just generate byte code from a BPMN or UML model?
It's an issue where the opportunity to play God might be all too tempting. The reality is, just as there is no such thing as a single grand unified software development process methodology, there is no single silver bullet when it comes to integrating the tools that are used for automating portions of the application lifecycle.
This article originally appeared in onStrategies.
Copyright © 2007, onStrategies.com
Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.