The Reuse Environment A Promise Unfulfilled A TenStep White Paper

Transcription

1 The Reuse Environment A Promise A TenStep White Paper Contact us at info@tenstep.com TenStep, Inc St. Davids Square Kennesaw, GA

2 Of all the revolutions that promised to speed business application development over the past thirty years, the one that made the most intuitive sense was the object-oriented (OO), or reuse, paradigm. How could this not make sense? You could build an entire solution by assembling a set of pre-built components that your company had already developed, or from free (or cheap) component libraries. Development time would be faster and cheaper. The solution would also be of higher quality, since the components had already been tested in other applications. It s a great idea! Then why isn t your company doing it? Why isn t every company doing it? It Takes a Holistic Approach to be Successful First of all, I know that many companies have successfully implemented a reuse development model. Many others started to move down that path, but abandoned the effort somewhere along the way. Others were never sure where to begin. The biggest barrier to success is that it is very hard work to implement a reuse environment. Technology is almost the least of the problems. The switch to reuse development has to be seen in the context of a culture change initiative. In other words, it requires people to fundamentally change how they do their jobs. Implementing culture change is rarely easy and requires a holistic approach. Sure, the development staff needs to be trained and the appropriate tools need to be purchased. But what are the other incentives and barriers to culture change? Is there an incentive for developers to build components for reuse, even though it may take longer and be more expensive? Remember that the value of reuse is being able to reuse the components the second and third time, not the first time. Are project managers and functional managers compensated on how much reuse they are able to employ in their solutions? Are developers rewarded for reusing components in their solution? Is there a central body that took ownership of reusable components so that they could be available and leveraged by other groups? Did I tell you that it would also cost money to make the reuse environment a reality? Unfortunately, the value obtained long-term with reuse requires cost and effort in the short-term. Many companies felt that if they trained people and had the right tools in place that the environment and culture would blossom on its own. This is not going to happen. Management Commitment is Key I previously worked on a project to set up the initial infrastructure to implement a reuse environment for an entire development organization. We set up processes, roles and responsibilities. We decided on training and tools. We successfully completed a couple pilot projects. We set up a prototype component repository. Unfortunately, when we put forward a proposal for future funding, it was turned down. Other needs always have a higher priority. We did not have the management commitment and focus to succeed. You need it all. If your development organization has any size at all, you need executive commitment and sponsorship for at least three years to establish the infrastructure and to develop a reuse culture. In a reuse culture, the first step in solving any problem big or small, is to ask yourself has this problem been solved before? The

3 individual then knows where to go to see if the problems or a similar one was solved previously, and is able to apply that solution to their current situation. Is it too Late to Start? It s not too late to start. For instance, Web development lends itself to reuse. But if you are going to try, be smart. First of all recognize that all cultural change lives and dies in middle management. Use the management hierarchy to force change and hold people accountable. But also make sure the organization has the appropriate people, process and technology infrastructure aligned to ensure success. Reuse Methodology An environment and culture that promotes reuse can offer tremendous value to your company. When you first heard the term, I think most readers assumed that we are talking about code reuse. In fact, that is usually the logical place to start. We are used to developing application using component libraries. Code reuse was also accomplished years ago through the use of subroutines. However, code reuse is only part of the reuse culture. There are many parts of the development lifecycle where reuse could come into play. One overall point to remember is that there are two basic aspects of the reuse culture. First in almost every activity you do, you first think about whether there may be something already available that you can use. If you cannot use it entirely, can you at least use something else as a starting point. Secondly, for every piece of work that you do from scratch (there will still be a lot), always ask yourself whether this work is something that someone else may be able to reuse later. Of course, if you ask those questions today, they don t do nearly as much good, because you do not have an infrastructure in place to handle the reusable components, even if you find them. However, that is the whole purpose of putting the environment in place. Project Planning Always start with the basic question has this problem been solved before? If not, ask whether something similar has been solved before. If so, then you may have a starting point to use going forward. Just to prove a point, I worked previously for a large company that had at least three distinct manufacturing packages. Could one package have worked for all of three sets of needs? Perhaps, but no one was asking the reuse question back then. When the project is being planned, look for anything that can be reused,. This includes the Project Definition document, workplans from similar projects, work estimates, project management procedures, etc. Analysis Here you want to see whether requirements can be reused from a similar project. You should also check for requirements for different solutions from the same department. Looking further ahead, determine whether design and code components exist for common sets of requirements. If a component exists that may represent 80% of the business need, you can also ask whether the business process itself can be modified to reflect the component logic. Design

4 In the Design Phase, wee whether any design models can be reused for your application. In many cases, for instance, online process definitions, screen layouts, report designs and technical architectures can be reused from other projects that were successful, even if the solution itself is different. As an example, many of you know the difficulty in designing an application that needs to exist behind a firewall (or multiple firewalls). If a second unrelated application also needed to exist behind the firewall, I am sure you would recommend they adopt your design and your techniques, rather than build another infrastructure from scratch. Also look for opportunities to reuse testing plans, testing scripts, etc. Construct This is where most developers probably start their reuse search. If you were able to reuse elements of other peoples analysis and design, chances are there are reusable business logic code components that you can utilize as well. Even if there were no reuse opportunities identified previously, this is the time to search the reuse library to see what is there that would save you time and effort. There are always opportunities to reuse vendor class libraries and functions. However, the biggest value comes from reusing business process logic. Testing If you use pre-built components, you should not have to independently unit test tem. They should be able to be hooked in directly during the integration test. Testing scripts are usually very tedious to create and implement. Look for any and every opportunity to reuse previous examples as your starting point. The Basics for Creating a Reuse Environment A significant amount of effort and cost is wasted when documents and objects are built without leveraging similar objects that already exist. Most developers understand the value of reuse and typically try to reuse objects when possible. However, most companies cannot fully implement a reuse environment and a reuse culture because they do not have the required infrastructure. This required infrastructure needs to support and reinforce the goal of reuse. Because this concept can involve major changes in how people do their job, it must include components that deal with technology, processes, and people. Key Deliverables The goal of establishing a reuse environment is to enable reuse of development objects that will reduce the cycle time of delivering solutions, and increase the overall quality. It may also be possible to reduce overall development costs, but this is not a given, since there is some cost associated with building and supporting a reuse environment. Before you start, you need to understand that there are many areas that must be addressed, including: Processes, procedures, and leading practices for accomplishing reuse. Training curriculum and courses required on how to build for reuse, both for developers and for support roles. Implementation of new roles and responsibilities that support reuse. Incentives to encourage individuals to build and use reusable objects.

5 A measurement process that tracks reuse and compliance to reuse processes. A repository tool for storing and managing reusable objects. The tool must include a catalog, which defines the objects and supports searches. Types of Objects that can be Reused Before we get too much further, let s discuss the types of objects that can be reused. I think that most developers immediately jump to the conclusion that we are talking about reusing programming code. In fact, we are. However, there is much more than code that can be reused in a true reuse environment. Think of all the objects in your environment in one of two categories. Structured objects related to the development process. Structured data is defined as data of fixed length or pre-determined content and form. Examples include programming code, entire class libraries, data models, etc. Basically, these objects can be easily stored and interpreted with the proper tools. Unstructured objects are those that do not necessarily follow any fixed format or pattern. They are not as easy to catalog and store, although many tools and databases today handle them pretty well. Unstructured data comes in varying length, content and form. Examples include documents, graphs, audio clips and video images. Benefits and Barriers to Establishing a Reuse Environment The Benefits I think most developers assume that the major benefits to reusing code is that applications will be faster and less expensive to build. Actually they are right and wrong. First, there should be no question that applications can be assembled from reusable objects faster than they can be built from scratch. There is no question that faster development time is a major benefit. The second major benefit is improved quality. This results from the use of pre-tested objects. Reusable objects are more stable, deliver more predictable results, and are less prone to errors in production. It should be obvious that faster delivery times will also result in less expensive solutions. This is true on a project by project basis. For instance, each project will use less development time and money, there is less testing required because you are using components that have been tested already. However, there are increased costs for the entire organization because of the new processes and tools required to support the reuse environment. In fact, it is these overall environmental costs that typically do not get funded that spell the doom of most reuse efforts. The Barriers In theory, there is no reason why a reuse program cannot be developed and executed successfully at any company. In reality, there are many barriers to overcome. In general, new programs can be implemented most easily when they merely attempt to structure or optimize the natural tendencies that people perform anyway. Building and using reusable components is not one of these natural processes.

6 There are many potential barriers, but they all fall into the category of not implementing a complete reuse program, and not successfully tackling the issues associated with people, process and technology. For instance, the program will fail if people are not properly trained, if people do not have the right incentives, if the reuse program is not funded over the longterm, if management commitment is reduced, if a poor repository tool is purchased, etc. Where to Start Reuse can work in every environment and on every project. However, there is a cost to building and implementing the reuse objects and the entire reuse environment, so it make sense to maximize the initial value you are receiving for the dollars you are investing. It probably doesn t make sense to build an elaborate reuse strategy for COBOL, for instance. Not only is the technology declining, but the payback for maintenance and enhancement activities does not appear to be high. The place to start your reuse environment includes: Unstructured project data, including all major project and project management deliverables. This includes workplans, Project Definitions, reusable templates, project key learnings, etc. Structured models from development and database tools, principally including those from the analysis and design phases. Testing plans and testing scripts from the testing tools that you utilize. Source code, including common libraries and utilities, and custom code that is written for a particular function, but can be reused by other project teams. What it Takes to be Successful Most companies have the capability to create a reuse environment. First you must have an appreciation for the challenges, and be prepared to overcome them The effort must be viewed as a major change initiative, not as the implementation of a new technology. It must be implemented holistically. The processes and tools will be the easy part. Changing people s work habits will be much tougher. Reuse must be a part of everyone s job. You must be prepared for at least two years of investment in building infrastructure and capability, before we will begin to see the payoffs in the subsequent years. Your company must be prepared to fund the centralized support that the reuse program will require on an ongoing basis. Start off with some early successes and build from there. You cannot go from no reuse to total reuse in a short timeframe. The deployment strategy should focus on areas where you have high probabilities for success, and then build from there. You Need Sound Processes and Training to Facilitate Reuse of Development Components Think about this problem in broad organizational terms, not just as developers sharing code within a team. If you are asked to develop a solution for your customer, you may well be building components that could be used on other solutions that might arise later - in other departments and locations. How do you know if the

7 component can be reused? Should you build the component in a way that will allow it to be reused by others, even if that means it will take longer to develop for your particular application? Once you create the component, and it is used in multiple applications, how does it get changed if there is a problem found or an enhancement needed? Creating a reuse environment requires a balanced focus on people, processes and technology. You need to consider reuse processes, training, roles and responsibilities, incentives, metrics and a repository. Processes and Procedures The need for reuse processes arises because of the logistical difficulty in managing components that can be shared by many developers in many applications. Let s assume for a minute that there is a particular group that manages the reusable component library. There are two broad sets of processes that need to be defined. First, you need to understand how a component is identified as being reusable and how it is elevated to the reuse library. Second, and most important are the processes associated with managing the components in the library. Component Identification and Submission If you developed a component that you thought had wider reuse applicability, what would you do to let the rest of the organization know? In most organizations, there is not a process in place to make this happen. You can share components on your team, but wider reuse is difficult. You need to have processes in place that allow people to volunteer certain components they are building as candidates for broader reuse. The request needs to be evaluated to see if the component does, in fact, have wider use opportunities. Once that determination is made, the business rules need to be defined precisely, the component built and tested rigorously, and documented clearly. This work may be done by the original developer, or by a team that develops and supports the library of reusable components. Ongoing Component Management Once you identify, build and document a reusable component, you have something that people can reuse. However, the component then must be supported, just as a normal developed application needs to be supported until it is retired. This component management is not as difficult if a component never changes. However, it becomes more complex is the component needs to be modified because of a necessary enhancement, or because an error was found. Another reason for a change is if a component is close to what a new application needs, but not exactly. You may create a new, related component, or modify the first one to allow it to be reused more generally. When that happens, you need to keep track of component versions. The people that are currently using the component need to be notified that the component is changing, and they must decide if they want to continue using the older version, or make the change to a newer version. If everyone using the old component can migrate to a newer version, then the older component can be retired. Other specific processes need to be established in the following areas: Testing and quality processes to ensure the components are tested

8 rigorously and do not break the host application. Communication processes need to be in place to keep developers informed of the components available for reuse. Error and enhancement reporting processes so that the appropriate people make decisions on when and how component changes occur. Training is Also Required Another aspect of building a reuse environment is that there are specific techniques and skillsets required to build components for reuse. You obviously cannot cut and paste sections of code and expect that they will be reusable by other applications. There are programming paradigms that need to be understood and followed in terms of encapsulating the code, building the proper parameters, etc. Most developers probably think they write pretty solid and stable code. But how many developers actually have the skills to develop non-trivial encapsulated components that can be used by independent developers all over the company without breaking or providing inconsistent results. Although many developers better understand object-oriented concepts today, most cannot program at the rigor necessary. (Exceptions of course to those people that build and deploy packaged software for a living.) Different computer languages have different ways to accomplish reuse some of which are more difficult that others. The developers building the reusable components must have the right level of training and mentoring to ensure that the components are reliable, understandable and stable. A Reuse Environment May Require New Roles and New Incentives Roles and Responsibilities Roles that are defined within the context of a reuse environment will change based on the size of the organization. If your IT staff consists of ten people, formal reuse roles are not necessary. If you are trying to establish the environment in a Fortune 500 company, they are definitely required. Depending on the number of components being managed, these positions may or may not be full-time. Reuse Manager - The Reuse Manager is responsible for the entire reuse environment. Like any major initiative, if someone is not primarily in charge, the work will not get done. This person may initially be a project manager assigned to a project that establishes the basic environment processes, training, tools, etc. When the environment goes live, this person may then transition to a role as reuse champion, and makes sure that there is an ongoing emphasis and focus to make the effort successful. Reuse Librarian - This person manages and runs the reuse library. They communicate what is available in the library, and are responsible for categorizing the components in a way that they can be easily found by developers. This becomes especially important when the organization is sharing hundreds (or thousands) of components in the reuse library. The Librarian also makes sure that the components are documented adequately and tracks the usage of components (if the library tool does not do that automatically). Tracking usage is important because if a components is changed (because of an enhancement of bug-fix), the

9 applications that use the old component may need to be modified. Reuse Engineers - These are the people that can write and support the reusable components. They must be skilled in object-oriented techniques, and understand how to build components that may be used by many applications around the company. Draft components may be submitted by the regular development staff, but the Reuse Engineers make the necessary modifications to make it a true, bulletproof, high-quality OO component. Other Roles - Depending on your implementation strategy, you may also have instructors and coaches that assist people in using components, reuse business owners that are responsible for understanding and validating that a component accurately reflects business, and perhaps a Reuse Committee that prioritizes the work of the Reuse Engineers. Incentives Major organization initiatives rarely work if they are not accompanied by the proper incentives. Project managers need to want to look for opportunities to reuse. Developers must feel motivated to look for what components of their solution might already exist, rather than develop everything from scratch. Business clients must understand that if a component is available that meets 80% of their needs, it might be the way to go. To build the right incentives, you need to consider what the natural motivation will be, and what additional push people need to have to think of reuse opportunities first. One obvious place to start is to make this a part of the yearly objectives and compensation process for the organization. Developers may have objectives around submitting code components as candidates for reuse. They should also have objectives around their ability to use components that are already in the Reuse Library. In the pressure to meet deadlines, these reuse opportunities may not naturally be a part of the developer s mindset. In general, all cultural change initiatives, like establishing a reuse environment, live and die in middle managers. The CIO may want the program to succeed, but it is the middle-level functional and project managers that will make it successful. If the company managers make this a focus, talk about it often, make sure people have related objectives and hold developers accountable for reuse, the program has a chance of success. If reuse is the last thing on their minds, then the program will fail. Therefore, all of the management levels in the organization need to have the success of this program as one of their yearly objectives. If the program flounders or fails, they need to be personally dinged accordingly. Tools and Metrics are Needed to Complete the Reuse Environment There can be a tremendous benefit to establishing an environment and culture where reuse is supported and encouraged. However, there are many barriers to setting this up. You need to establish good reuse processes and train the staff to look for and build for reuse. You also need people in new roles to support the environment, and everyone needs the right incentives. The last things that you need are a good metrics program and the right tools. Metrics

10 We usually think that most of the activities that we do on a daily basis provide value to the company. But how many of us could do a good job of quantifying the value that we provide. It is a lot easier to see what we cost. Many companies that have tried to implement a reuse environment in the past were not able to keep organizational focus and continuity for the time needed to really make the program a success. One of the major reasons that they are not able to keep a long-term focus is that they are not able to track the value to the organization. They may have been able to justify the reuse program based on the ability to deliver solutions better, faster and cheaper. However, they did not do a good job of actually quantifying the benefits. The costs are easy to find and understand. The reuse program must capture the value as well. Examples of reuse metrics include: Effort and cost savings This is the big one. It requires developers to estimate the cost and effort associated with building the functionality, versus the cost and effort of using a reusable component. Chances are that developers will not provide the information you need unless they have the proper incentives. Cycle time savings Similar to the last metric. Ask how long would it have taken to code and test the functionality from scratch, versus using the reusable component. Quality of the components Count the errors that were found in the reuse components. Also survey the developers that use the components for their opinion on overall quality (ease of use, stable, reliable, etc.). Number of components reused Count and track the numbers. How often the components have been reused Count and track the numbers. The value metrics are, by their nature, relatively imprecise. For instance, if a Developer reused a component, it may have taken them five hours to understand and fully utilize it in their solution. They may estimate that it would have taken them forty hours to code and test the functionality from scratch. Although the implication is that there was value provided, it is impossible to know precisely. The reuse team should capture as many metrics that show the reuse value, and supplement these numbers with anecdotal evidence such as success stories and testimonials. Tools When a reuse environment is small, it is possible to capture the components on directory folders and provide descriptions in test documents. However, if the program is successful, you may end up managing hundreds of reusable components. At that level you will need the proper repository tools. There are tools on the market that allow you to index and link to the component libraries, or actually store the components within the tool itself. The repository tool also allows you to classify and index the components so that they can be easily found by developers. As the environment gets more sophisticated, you are going to want to formally reuse more and more types of information. For instance, you can now fairly easily build document libraries that allow you to store Project

11 Definitions, best practices, Communication Plans, project management procedures, etc., so that they can be reused on other projects. If your company is large enough, you might also easily find value in using analysis tools, design tools and testing tools. Look for opportunities to save and reuse business requirements, design models and testing scripts. For example, your Finance Department might have projects going on every year. Although Finance is a broad area, you may find that some of the business requirements from one project are also applicable on other projects. In the same way test data and testing scripts from one application may be able to be reused on another, similar application. However, to really be effectively reused, the material must first be entered and made available in some type of tool. Setting up a reuse environment does not have to be a daunting task. We have done it before. About TenStep Contact us for more information. info@tenstep.com TenStep, Inc. ( is headquartered in Atlanta, Georgia (USA), and specializes in developing, consulting and training in business methodologies. The company s flagship product is the TenStep Project Management Process, which has been licensed to thousands of companies and individuals around the world. In addition, TenStep has training, consulting and business methodology products covering Project Management Offices, portfolio management, software development and application support. The TenStep process is translated into 14 languages, allowing it to be utilized by organizations in most parts of the world. TenStep meets the needs of local businesses with a network of offices in the USA and around the world. Our training classes include: Project Management (advanced and basic) Preparing for the PMP Exam Earned Value Management Setting up and Running Project Management Offices Setting up and Running Portfolios Gathering Business Requirements Many, many more Our consulting services include: Project management deployment and customization Project Quickstarts Setting up PMOs Project management coaching, auditing documentation review Managing your projects Many more About the Author:

12 Tom Mochal, PMP is the president of TenStep, Inc. ( a methodology development, consulting and training company. He is also the head of The TenStep Group, a network of TenStep offices supporting the TenStep process in numerous languages and countries around the world. Mochal is author of a book on managing people called "Lessons in People Management" and a companion book on project management called "Lesson in Project Management. Mochal also authored all of the TenStep methodology products. Mochal recently won the Distinguished Contribution Award from the Project Management Institute for his work spreading knowledge of project management around the world. Mochal is a speaker, lecturer, instructor and consultant to companies and organizations around the world. He is a member of the Atlanta, Georgia (USA) chapter of the Project Management Institute (PMI), the American Management Association (AMA), the American Society for the Advancement of Project Management (asapm ), and is a partner in The Management Mentors, a group dedicated to building knowledge in project management, IT management and leadership/personal development. Contact us at info@tenstep.com TenStep, Inc St. Davids Square Kennesaw, GA