|
Neuma Technology Inc. provides the world's most advanced
solution to manage the automation of the software development lifecycle.
|
|||
More white papers:Find out more ... |
Neuma White Paper:CM: THE NEXT GENERATION Enterprise CMWhen I think of Enterprise CM, three things come to mind: 1. Tools (and processes) that expand CM from a software team to a product team capability, 2. Processes (and standards) that help keep CM consistent across the enterprise, and 3. Infrastructure (and management) that pushes CM technology into the rest of the organization. Enterprise CM is not a simple feature, process or edict. It the establishment of tools, processes and infrastructure so that management can confidently reap the benefits of CM and ALM across the enterprise. Think beyond ALM, think beyond Software, think beyond development, and think beyond products.
Enterprise CM Tools Enterprise tools need to go beyond CM to ALM, and beyond. A product doesn't start or end in the development team. It starts with a concept and/or contract and/or business case. It moves into establishing a set of requirements which can be evaluated sufficiently to reach a contractual agreement to deliver a series of product releases, it involves project management, architectural design, test suites, documentation, verification tracking, customer delivery, deployment, customer feedback and support, change requests, change management, configuration management, build and release management, organization charts, maintenance, retirement and/or disposal, and more. Enterprise CM must support the entire team, and customers as well. If the CM tools are specific to a slice of the product team, the product team really doesn't have much of a chance to gel into a team. If a developer can't understand the urgency of a customer, or if project management tasks don't line up with requirements, you end up with separate projects within a project: Customer support, Project Management, Requirements Definition, Build Management, Programmers. When the tool easily melds these functions into a consistent end-to-end capability, with point-and-click navigation across functions and through traceability links, with easy to use interfaces, dashboards and guidance, it makes a big case for transforming the separate team functions into a single team function. A number of commercial tools have endeavored to provide comprehensive end-to-end tools. Some have had more success than others. Some have created multiple departments for Administration, Customization, Glue Management and Multiple Site Operation. Others have succeeded in giving us end-to-end tools without few, if any of these additional groups. It's not an easy problem to solve. Multiple attempts have been created over time to create "backplanes" or portable tool environments to pull things together. Perhaps Eclipse has has the most success here, but there have been plenty of failures along the way, each contributing to the oveerall body of knowledge. Open Source tools tend to be good. There are great merge tools, editors, documentation tools, graphics tools, and so forth. But I think, at least for now, the concept of Enterprise CM tools is beyond the scope of Open Source. One of the key reasons here is that a successful Enterprise CM tool suite must be built on a common database, with a common process engine, and a consistent user interface. Things like Multiple Site Operation, Administration, Customization, must be shared - not different for each function. Open Source Enterprise CM will come when a commercial vendor turns over its tools to the community. Not just any vendor, not just any tool. I think we have a ways to go before this happens. Enterprise CM Processes and Standards One of the big problems is that organizations often dictate a tool to be used across the enterprise. If they pick the right tool, great. But the vast majority of the time the wrong tool is mandated, resulting in budget crunches, resource crunches and capability shortfalls. Establishing an enterprise-wide tool requires understanding the CM/ALM process across the Enterprise, and then selecting tools that can be used to support an overall process and framework. This requires expertise and experience. One project is not the same as another. An Agile project which is delivering a constant stream of releases to stay ahead of the competition is much different than an infrastructure project which is occasionly upgrading repository technology. A development team of 3 or 4 is much different than one of 300 to 400. Yet these variations exist in any large corporation. Initial CM standards, trying to cope with the various project attributes, were very generic in nature, adding insufficient process guidance for any project. However, with time and experience, these CM standards are improving. The process needs to be complete, but architected in such a way that the project variations can be supported within an overall framework. Supporting Agile and Traditional development models really isn't that different. If you think so, take a look at the artifacts that are needed and that have to be produced. It's the packaging of the project management that makes the difference. Unfortunately, a lot of the key players make the mistake that says a release process that occurs every two years doesn't have to be as efficient as one that occurs every month. In other words, the goals aren't as lofty. Continuous integration works quite well in a traditional model, as does frequent customer evaluation and involvement. Yes, design is different - analysis gives way to production prototyping, but there is a mix of both in either model. The CM process must cater to supporting the same elements in both models. The tools must re-inforce this support. It's the use of the process and tools that can be adjusted to fit the model, that is, as long as the process and tools have been defined in such a way as to support both. So process has to be carefully architected, with non-negotiable elements, but with the capability of weaving together these elements to support each project's unique requirements. Perhaps a number of pre-canned variations can be established as part of the process architecture to help minimize the amount of weaving required. Just as important though is the selection of tools. You can't take an Open Source tool and impose it on Ares V development, at least not with the state of current Open Source tools. But the same goes for most commercial tools as well, with only a few exceptions in my opinion. Tools must be process centric, but even more than that, they must be easily customized. It must be possible to extend the tools to support the particular functions of each project. But customization and extension is not sufficient if they require too much effort. And it must be possible to evolve process and tool customization over long periods of time, because needs will change constantly. Enterprise Process and Tools across the organization will give a great benefit if users can move from project to project without having to undergo significant training in these tools and processes. Beyond SCM Well let's start out by looking at Hardware versus Software development. One uses PDM/PLM tools, while the other uses CM/ALM tools. Don't try to impose one set of tools on the other's discipline - it won't work. Why? Primarily because the tools have been designed to meet the needs of a particular discipline. This is changing though. If you haven't found one yet, it won't be long before you see CM tools that can address both Software and Hardware, turning two teams into one. The requirement here is that tool vendors understand both Hardware and Software processes and their corresponding requirements. This is not too difficult, but if the tools weren't built with this level of support flexibilty in mind, they'll not be easy to change. But because Software is such an important part of Hardware today, this is going to happen - it might just take a bit of time. OK. So let's move a bit further from SCM. What about the other CM, also known as Asset Management. Again, the CM technology base is the same - tracking configurations, baselines, changes. But the end-user interface is quite different. The CM happens differently. So again it comes down to understanding requirements and having tools flexible enough to adapt to the requirements and to support the processes. There are different processes involved, different problems to be dealt with, and niche pieces of technology that can help. For example, hardware and software that can report on its configuration is a big help to Asset Management. It helps to identify changes made to a configuration from the configuration itself, sort of like identifying changes to a workspace that were made completely apart from the SCM tool. RFID technology will help here. And change authorization procedures and technology will also help. Add a few of these technologies into a CM tool, change the user interface focus and/or role functions, and you have an Asset Management tool that will also support development CM. So far we've stayed more or less within the realm of recognized CM of one sort or another. Now let's go whole hog across the organization. How are our financial spreadsheets evolving? Who's tracking changes to processes and procedures? How are we tracking human resources: requirements, offers, hiring, etc? What does all of this have to do with CM? Well, mature Enterprise CM contains a lot of intelligence that can be applied to other parts of the organization. Think of the organization as the product - how is it changing? Think of finances as measurement of a corporation's success. How do we put business cases and requirements in place to ensure this success? How do we track adherence to these requirements? What about the legal department? Not only are there a lot of similarities to software version control, but requirements, information access, and traceability are basic needs shared here as well as with traditional CM. In fact, in the past year or so, the Institute of Configuration Management has expanded its domain from development to the full set of business processes. There are dozens of business processes that can benefit from the disciplines of CM. And all of these have components such as document management, problems/issues/requests, project management and so forth. This gives Enterprise CM a whole new scope! Maybe we're not ready to move there yet. But remember, if you have a successful, flexible CM backbone, you're already molding business processes. As users identify the benefits of a fully integrated data and process environment with effective role-based user interfaces, they're likely to identify other parts of the organization that could benefit. If the tools and processes can be adapted to these areas, there will be a lot less re-inventing and a lot more team synergy. Summing Up Agile Joe Farah is the President and CEO of Neuma Technology . Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe by email at farah@neuma.com |