Agile Sponsors
Featured Whitepapers
- Learn Ways to Keep Schedules and Costs in Line With Requirements Change Management
- Java Deployments in an Enterprise Environment
- Challenges & Characteristics of Enterprise Continuous Integration
- Build Release Plans That Deliver Customer Value!
- Improving Traceability and Auditability Across the Development Lifecycle
|
| Why The Industry Is Readying Itself For Radical Change
The first sign of trouble is the unusually long time it takes for your IDE to start one morning. Maybe you can't access the trouble tickets any more or the team members cannot build their applications or run the automated test suite. If we look at development today, we can still find the roots of our young industry in almost everything we do. We still design, code and test (though not always in that order anymore). We still approve, build and deploy (but are more managed, reported and audited than ever before). And we still optimize, automate and document at every opportunity (and the risks of failure aremore extreme than ever). What drives us to do this and the methods and technologies we employ to achieve these goals are in a state of rapid transition. Two years ago extreme development methods were fringe tactics in IT and now they are mainstream. Three years ago we looked for tools to address our technology issues and today we look to process improvement first. Four years ago outsourcing and offshoring were ways to get cheap labor and today they are seen as critical resources in development infrastructure. The list of forces shaping IT today is almost endless but here are just some of them ... collaboration, reuse, business alignment, competitive pressures, {sidebar id=1} agile methods, Service Oriented Architectures (SOA), regulatory compliance, process reengineering, outsourcing, off-shoring, platform neutrality, Open Source Software (OSS), vendor consolidation, standards, Service Level Agreements (SLA's), do more with less, Web 2.0, and grid computing. See The Signs Like many new dawns we don't know it's there until someone gives it a label. In a recent analyst report the expression "ALM 2.0" was used to describe this event. The report describes ALM 2.0 as a platform for development where those activities are coordinated and managed. The report makes it clear that ALM 2.0 is about the development process much more than it is about the collection of tools that support ALM. If we look around we can see that this is beginning to happen. Perhaps the single most requested improvement to the development process today is technology to facilitate the necessary collaboration amongst IT practitioners. This not only extends from person-to-person in the various development silos, modeling, engineering, QA, and so on, but end-to-end from the business analyst and requirements engineer through all phases of the lifecycle to the build and release engineers and the deployment and packaging teams. Without end-to-end traceability IT will continue to deliver applications that diverge along the lifecycle from the original requirements. The QA analyst needs to be able to access the original requirement as much as the software developer does. The tools, the user interfaces these practitioners use, must facilitate collaboration across the silos, throughout the lifecycle and it must be bi-directional. I see two critical changes in almost every IT department today in response to the need for an ALM 2.0's goal of being a platform for coordination: serious and sustained efforts around process improvement often coupled with a documented methodology (ITIL, CMMI, etc) and process automation in form of advanced workflow technologies. Collaboration, or rather the lack of it, is frequently the first symptom of underlying problems in any development process. "No one told me" is probably the most commonly stated reason for failures in the execution of projects. Collaboration tools need to do more than facilitate communication. They must do it according to best practices defined by the organization and must include automated notifications which are time-, event- and exception-based, publish and subscribe models for attaching to collaborative communication threads. And they must be able to adapt flexibly to the needs of the business as processes are improved. A collaboration-centric infrastructure is essential to ALM 2.0. Macro And Micro Collaboration is the external expression of the underlying process of development. The end-to-end process of development should be automated as far as is possible. The trouble with this is that, far too frequently, the process of development is contained within the boundaries of a tool where the tool dictates the actual process steps. In ALM 2.0, it is necessary for a new generation of process-centric tools to emerge. These tools will provide adaptable process automation in support of the businesses best practices for that part of the lifecycle it supports. Additionally, these tools need to be able to support multiple parallel processes that can be interleaved and intertwined aligned with the businesses development methodology. These tools need to support legacy waterfall approaches to development as well as they support agile and RAD methods. We call this the micro-process layer where the detailed tasks of application development are managed by individual, role-specific tools. Tools that offer only one rigid interpretation of the way a particular part of the lifecycle is to be executed will not survive in ALM 2.0. As we string these tools together to support our overall development process, or macro-process, we need a technology layer that can bring all these tools together. Of course there are several vendor proprietary integration layers that offer this capability but these proprietary solutions are designed to aid the vendors much more than the consumers of the technology. ALM 2.0 needs open integration frameworks that are both vendor and platform neutral so that the consumer can bring together whatever tools they choose into a coherent technology stack that meets their development needs. Role-specific Solutions A lot of emphasis is given to reuse in the world of application development today. As we develop applications we are constantly on the lookout for opportunities to reuse and repurpose extant technology. Indeed, as we develop new SOA-based applications one of the surprising benefits is the discovery of just how much of our business logic can be exploited repeatedly to solve business problems. On the other side of that coin though is the discovery that some features are used little if at all. This same truth applies to the tools we use to develop both the composite applications and the web services they consume. As we look for tools to support our development of applications in an ALM 2.0 world we will be searching for tools that follow the reuse paradigm. Frequently, today's tools comprise of hundreds of features a few of which are used constantly and a few of which are perhaps used hardly at all. ALM 2.0 tools will expose functionality, as Web Services, so that the consumer can combine these features along with features from other tools to create novel and consumer-specific solutions that have only the features they need, or wish to expose, to the end user application development community. ALM 2.0 tools will need to provide role specific interfaces that speak in the dialect of the user role and that can be personalized to particular end user requirements. ALM 2.0 Is Here As we look around the vendor community it is clear that some of them are beginning to see the signs themselves. If you are looking for vendors who "get" ALM 2.0, here are my suggestions as to the features you must look for:
About the Author
Set as favorite
Bookmark
Email this
Hits: 8644 Comments (0)
|
Show/hide comment form
| < Prev | Next > |
|---|
Agile Marketplace - Announcements and Special Offers
Webcast: Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!
Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial
Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper
PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now