Configuration Management Best Practices: Practical Methods that Work in the Real World

Configuration Management Best Practices: Practical Methods that Work in the Real World

Configuration Management Best Practices: Practical Methods that Work in the Real World

Configuration Management Best Practices: Practical Methods that Work in the Real World

eBook

$20.49  $27.19 Save 25% Current price is $20.49, Original price is $27.19. You Save 25%.

Available on Compatible NOOK Devices and the free NOOK Apps.
WANT A NOOK?  Explore Now

Related collections and offers


Overview

Successfully Implement High-Value Configuration Management Processes in Any Development Environment

 

As IT systems have grown increasingly complex and mission-critical, effective configuration management (CM) has become critical to an organization’s success. Using CM best practices, IT professionals can systematically manage change, avoiding unexpected problems introduced by changes to hardware, software, or networks. Now, today’s best CM practices have been gathered in one indispensable resource showing you how to implement them throughout any agile or traditional development organization.

 

Configuration Management Best Practices is practical, easy to understand and apply, and fully reflects the day-to-day realities faced by practitioners. Bob Aiello and Leslie Sachs thoroughly address all six “pillars” of CM: source code management, build engineering, environment configuration, change control, release engineering, and deployment. They demonstrate how to implement CM in ways that support software and systems development, meet compliance rules such as SOX and SAS-70, anticipate emerging standards such as IEEE/ISO 12207, and integrate with modern frameworks such as ITIL, COBIT, and CMMI. Coverage includes

 

  • Using CM to meet business objectives, contractual requirements, and compliance rules
  • Enhancing quality and productivity through lean processes and “just-in-time” process improvement
  • Getting off to a good start in organizations without effective CM
  • Implementing a Core CM Best Practices Framework that supports the entire development lifecycle
  • Mastering the “people” side of CM: rightsizing processes, overcoming resistance, and understanding
    workplace psychology
  • Architecting applications to take full advantage of CM best practices
  • Establishing effective IT controls and compliance
  • Managing tradeoffs and costs and avoiding expensive pitfalls

 Configuration Management Best Practices is the essential resource for everyone concerned with CM: from CTOs and CIOs to development, QA, and project managers and software engineers to analysts, testers, and compliance professionals.

 


Product Details

ISBN-13: 9780321699954
Publisher: Pearson Education
Publication date: 08/10/2010
Sold by: Barnes & Noble
Format: eBook
Pages: 272
File size: 1 MB

About the Author

Bob Aiello is the editor-in-chief for CM Crossroads and a consultant specializing in software process improvement, including software configuration and release management. Mr. Aiello has more than 25 years of experience as a technical manager in several top NYC financial services firms where he had companywide responsibility for CM, often providing hands-on technical support for enterprise source code management tools, SOX/Cobit compliance, build engineering, continuous integration, and automated application deployment. Mr. Aiello is the vice chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) management board. He is a longstanding member of the steering committee of the NYC Software Process Improvement Network (CitySPIN), where he has served as the chair of the CM SIG. Mr. Aiello holds a master’s degree in industrial psychology from NYU and a bachelor’s degree in computer science and math from Hofstra University.

 

Leslie Sachs is the COO of Yellow Spider, Inc., which specializes in providing CM-related consulting services that are aligned with the practices described in this book. Ms. Sachs also writes about applying personality to technology endeavors in her column titled Personality Matters. A New York State Certified School Psychologist with more than 20 years of experience, Ms. Sachs has worked in a variety of clinical and business settings where she has provided many effective interventions designed to improve the social and educational functioning of both individuals and groups. Ms. Sachs has a Masters of Science degree in school and community psychology from Pace University and interned in Bellevue Hospital’s famed Psychiatric Center in NYC. A firm believer in the uniqueness of every individual, she has recently done advanced training with Mel Levine’s All Kinds of Minds Institute.

 

Read an Excerpt

Configuration management (CM) plays a critical role in any technology development effort. I have been involved with implementing and supporting CM for over 25 years and much of what I am about to discuss comes directly from my own personal experience. I have implemented and supported each of these CM practices, often with the agreement that I could be woken in the middle of the night if my processes/automation did not work as expected. As an instructor, I have taught industry strength CM tools to over 900+ technology professionals (again with the offer that they got my home phone number upon successfully completing my class). My colleagues and students have consistently indicated that my passion and love for this discipline has always been abundantly clear. It is my view that configuration management consists of six functional areas:

  1. Source Code Management
  2. Build Engineering
  3. Environment Configuration
  4. Change Control
  5. Release Engineering
  6. Deployment

I have searched for, but never found, any single book (or even a series of books) that covered all of these functional areas. Most CM books are either too narrowly focused on one key area (e.g., building code with Ant) or so “ivory tower” that they did not give me enough information on how to really implement these functions in a practical real world environment. It’s nice to point out the need to “maintain control of all configuration items”, but unless you tell me exactly how to do that in a practical and realistic way, the advice is not truly utilizable. It is my intent both to cast a wide net on the CM practices that you need to understand and also to provide enough detail so that you know not only “what” each CM function entails, but, just as importantly “how” to implement each of the CM functions. I expect that my readers will hold me to that commitment (see the URL of the supporting website below).

The Traditional Definition of Configuration Management

Configuration management or in this context, software configuration management (SCM) has a traditional definition of consisting of four specific functions. They are:

  1. Configuration identification
  2. Change control
  3. Status accounting
  4. Configuration audit

These functions have long been described in industry standards and frameworks and obviously viewed as essential to any valid configuration management effort. While I agree completely that these functions are correct and essential, I find their terminology to be difficult for many technology professionals to understand and appreciate. In this book, I will discuss the traditional CM functions, and I will also suggest a framework for understanding and implementing configuration management in a way that I believe will reflect current industry practices. Specifically, I will show the relationship between the four classic functions and the six functions of source code management, build engineering, environment configuration, change control, release engineering, and deployment that I believe more closely reflect the way that CM is actually done on a day to day basis. This is an important focus of my efforts to make configuration management best practices more approachable and practical for technology professionals to enjoy as part of their own process improvement efforts.

Terminology and CM

Configuration Management, like many other disciplines, suffers from the use of confusing terminology. I am not going to solve that problem in this book, but I will endeavor to at least not make the situation worse. The acronym SCM has been used to refer to both Source Code Management and, more recently, Software Configuration Management. One of my most knowledgeable colleagues has prevailed upon me to not make the situation worse, so I will only use the SCM acronym to refer to the broader Software Configuration Management, which is a specialization of Configuration Management (as opposed to hardware configuration management discussed in Chapter 8). Similarly, the acronym CI is used to refer to both Configuration Items and Continuous Integration. CM terminology can indeed be quite confusing. I can’t do much about the confusion caused by this dual use of CI as an acronym, as it is pervasive, but I will do what I can be as clear as possible. Whenever possible, I will endeavor to use the definitions the IEEE’s SEVOCAB: Software and Systems Engineering Vocabulary, which at the time of this writing could be found at http://www.computer.org/sevocab.

Why I Love CM

I love CM because it is a creative and exciting endeavor that can significantly add value by improving quality and productivity in any technology project. Not only will I discuss what I have learned, but I will also be relating the combined experience of thousands of CM experts who have kindly shared their own expertise and best practices with me over the years that I have been engaged in this work. I owe each of these fine colleagues a debt of gratitude for all that they have shared with me. I have written and published many articles on configuration management and thoroughly enjoyed the feedback that I have received (especially when those supplying it disagreed with me and offered other practical approaches to solving thorny CM related problems). I anticipate that this book will also generate considerable interaction with my colleagues especially through the supporting http://www.cmbestpractices.com website that I have created Please visit this website for up-to-date information on the topics that we discuss in this book as well as to give me feedback about your own experiences with implementing configuration management.

Why I Wrote This Book

I have written this book to share my expertise and experience with implementing all aspects of CM in realistic business, engineering and government environments. I hope that you will find this information to be practical, comprehensive and helpful in implementing CM in a variety of real world situations.

Some topics in CM are evolving so quickly that writing a book on them would be a daunting task indeed. For example, as I write this chapter, my “day-job” is to implement IBM’s latest Application Lifecycle Management (ALM) solution that includes a brand new Source Code Management and automated workflow solution. Therefore, for this book, I will discuss how to select a CM tool in only general terms, but restrict tool specific comments to my support website so that the information can be kept current and accurate. I also hope that you will hold me accountable for the accuracy of every word that I write because I have very strong personal views that CM is essential on a moral, ethical and theological basis. While CM is not my “religion”, doing honest and high quality work is certainly part of my religious belief system. I also view spreading CM best practices as being a model for good corporate citizenship. I have been very active in the virtual community that develops and supports configuration management as well as other aspects of application development. On any given day you can see technology professionals providing each other with substantial assistance without regard for whether or not they work for competing organizations. The community is truly culturally diverse, multilingual, and universal in its respect for and acceptance of others. I am proud to be part of this work and wish my efforts to promote CM best practices to be part of a wider movement to promote effective IT controls, responsible business leadership, and good corporate citizenship resulting in greater services and value for everyone who shares this increasingly tiny world that we live in. To say this in another way, I believe that every government agency, financial services firm (including banks, hedge funds and insurance firms) along with firms that are in the medical, pharmaceutical, and defense (and every other) industry should be required to implement proper IT controls to protect the public who rely upon their services as well as shareholder value. I wrote this book, in part, to help transition this effort from being a burden to instead being a journey in improving productivity and quality. It is my belief that implementing IT controls, including CM best practices, in a pragmatic way should result in higher profitability for the members of the firms, their shareholders, as well as the public who rely upon their services.

Who Should Read This Book

Technology Professionals including development managers, system architects, developers, systems engineers, hardware engineers, quality assurance, quality engineering, operations engineers and technology project managers will all benefit from the information in this book. CTOs, IT auditors and also corporate managers will especially enjoy the sections on establishing IT controls and compliance. Whether you are an Agile enthusiast or working with a classic waterfall lifecycle, this book will help you get your job done better. CM is all about good corporate citizenship. The news media love to report instances of corporate greed and incompetence among those who have a responsibility for providing and maintaining technology for the public good. CM best practices help insure that the global economy runs smoothly, ATMs work correctly, air traffic control systems remain online, and so on. If you want your technology development efforts to be more efficient and to yield higher quality products then this book is for you.

How to Read This Book

You should at least skim the Introduction as this section will give you an overview of the CM functions as well as their overall linkages. You should also feel free to skip to the area that you need help with next. I have endeavored to write each chapter so that it can be read and used separately. In practice, this has often been how I implemented CM. For example, I have often skipped directly to solving the most urgent problems (as indicated by the customer) without being rigid about the order of implementing CM functions. That said, there are some dependencies and I will do my best to describe them as well.

How This Book Is Organized

This book is organized into fourteen chapters divided into four parts. Part I, “The Core CM Best Practices Framework,” consists of six chapters covering source code management, build engineering, change control, environment configuration, release engineering and deployment. Part II, covers Architecture and Hardware CM, while Part III covers the essential people issues that you need to know in order to effectively implement CM Best Practices. Part IV covers Compliance and the Standards (e.g. IEEE) and Frameworks (e.g. ITIL, Cobit, CMMI) needed to establish effective IT Controls. What follows in the next section is a short description of each chapter.

Part I – The Core CM Best Practices Framework

Six chapters make up the Core CM Best Practices Framework.

Chapter 1: Source Code Management

Source code management is an essential starting point for any configuration management function. In this chapter, we discuss the requirements for an effective source code management effort as well as some of the core concepts. In source code management you make sure that you know where all of the artifacts needed by your application are located and that they are all properly identified and can be managed effectively. If we were baking a pie, then Source Code Management would help you ensure that you have all of the correct ingredients on hand and in their proper amounts.

Chapter 2: Build Engineering

Build engineering includes the compilation of all of the configuration items that go into a release. Your build engineering practices need to be efficient, reliable, and repeatable. Build engineering also includes procedures for building in the essential version IDs that are required for configuration identification. Build engineering involves mixing the batter and baking the pie itself.

Chapter 3: Environment Configuration

Environment configuration involves handling the compile and runtime changes necessary for the promotion of code from development to QA to production. It also includes the configuration and management of the requirements. Environment configuration ensures that you have the shelf ready to show off the great pie that you baked.

Chapter 4: Change Control

There are seven functions in change control, including evaluating requests for change, gatekeeping (e.g., promotion), configuration control, emergency change control, process changes, advising on the downstream impact of a potential change, and senior management oversite of change control. Change control decides when the pie is baked and ready to be taken from the oven and sent to the happy person who will enjoy the pie.

Chapter 5: Release Management

Release management involves packaging the configuration items into components that can be reliably promoted and deployed as needed. Release management is effectively putting your pie into the nice box with the open window so that others can see and appreciate the fine work that you have done.

Chapter 6: Deployment

Deployment should be a narrowly defined function of promoting the pre-packaged release to QA or production as needed. This is effectively putting your pie on the truck to be delivered to your consumers (make sure that you get my home address correct for delivery).

This completes the first half of the book covering what I view as being the essential core CM competencies necessary for any CM function. I am really getting hungry now so I have to stop using a pie as a metaphor for CM. The rest of the chapters make up the eight supporting functions that are also important for the implementation of an effective CM effort.

Part II – Architecture and Hardware CM

Architecture and hardware also are candidates for CM.

Chapter 7: Architecting Your Application for CM

This is an often overlooked aspect of configuration management and involves recognizing the interrelationship between application architecture and configuration management. The essential nature of CM is the same whether you are implementing it on a mainframe or your favorite handheld device. But the actual procedures will vary significantly based upon the architecture of your application. So implementing CM on a WINTEL platform may be very different than on a Unix/Linux platform using Java SOA or C++. This chapter is about understanding that relationship.

Chapter 8: Hardware Configuration Management

I need to write a whole book on hardware configuration management. There just isn’t enough recognition of its value and importance in the CM field. I have been frequently asked to write about hardware CM. This chapter begins what I am sure will be a longer journey.

Part III – The People Side of CM

You can't afford to ignore the people side of any business or organizational endeavor. CM is no different.

Chapter 9: Rightsizing Your Processes

My whole career has been focused on implementing process improvement. I have learned that too much process is just as bad as not enough. This chapter is about finding the right balance and implementing just enough process to get the job done.

Chapter 10: Overcoming Resistance to Change

Having a great process does not help anyone if you can’t get your team to accept the process and actually start working in a new and better way. This chapter is about overcoming resistance to change and getting the team to accept and enjoy the new way of doing things.

Chapter 11: Personality and CM: A Psychologist Looks at the Workplace

Leslie Sachs takes the lead in this chapter as she describes the essential people skills that you need to be effective in implementing CM best practices. I get scared when I read Leslie’s work, because she seems to always be eavesdropping on my conversations. Read this chapter if working with people is important to you.

Chapter 12: Learning from Mistakes that I Have Made

I have made lots of mistakes in my career. I have achieved a lot, yet I have also failed to achieve as much as I had hoped. But I have learned a lot from my own mistakes, and this chapter is my effort to share some of my personal improvement efforts to learn from my own mistakes and short comings. This chapter could have been its own book or perhaps the size of a small encyclopedia.

Part IV – Compliance, Standards, and Frameworks

The book ends with the issues involved in establishing IT controls, complying regulations, and the use of industry standards and frameworks.

Chapter 13: Establishing IT Controls and Compliance

Establishing IT controls and compliance is one of my own favorite topics. I like to focus on using these efforts to improve quality and productivity while you are also getting ready to pass your audit. IT controls and compliance is a really critical topic for many organizations and I expect that if you need to meet industry regulations then you will find this information to be extremely valuable.

Chapter 14: Industry Standards and Frameworks

I strongly advocate the use of industry standards and frameworks, but I also believe that much of what has been previously written is difficult to understand and even more difficult to implement. I believe that those of us involved with creating industry standards and frameworks need to write more practical material on how to actually implement standards and frameworks in a realistic and pragmatic way. My focus, in this chapter, is on describing my own personal journey with implementing process improvement using the guidance described in Standards and Frameworks along with the essential skills of tailoring, harmonization and operationalizing the published guidance. This might be the most important chapter in the book and I hope that you will give me your feedback on your efforts to embrace and implement industry standards and frameworks.

Overall, I think that you want to focus on the first half of the book to get the core CM Best Practices and then read the second half of the book in whatever order you choose to cover the topics that you have an immediate need for implementing within your organization.

Acknowledgements

There are a lot of people who have helped me write this book. First, the Aiello family editing team has been amazing. We are very much like a mom and pop candy store except that we write technical journals. My assistant editors have included my sons Shmuel and Dovid (also our webmaster), Massimo, whose ability to see things differently, helped me to perceive concepts in new and different ways (not to mention provided his fresh baked pizza) and Esther whose creativity helped us in so many ways. My youngest princess, Devora, whose hugs and cuddling (not to mention backrubs) always kept me focused on getting the work done. Finally, Leslie, my lifelong partner, who proved that we could be colleagues on multiple levels.

There are many colleagues who I should acknowledge for sharing their expertise and experience. Leading the list would certainly be my colleagues on the IEEE CM Planning working group, starting with our Chairperson, Chuck Walrad and the members of the working group who have taught me so much about CM (and tolerated my diatribes about how we need to write more clearly) including Diego Pamio, Alastair Walker, Darrel Strom, Ranata Johnson and Mike Smith. I have also learned a great deal about Standards from all of my colleagues and mentors on the S2ESC Board including James Moore, Carl Singer, and David Schulz. Equally, helpful were my numerous colleagues on CM Crossroads, including Steve Berczuk, Mario Moreira, Ben Weatherall and, of course Patrick Egan with whom I have worked with on the CM Journal and CM Crossroads for so many years. The folks at Addison Wesley were amazing starting with my development editor Chris Zahn along with Chris Guizikowski and Raina Chrobak. Early in my career I was privileged to work with Dr. Marianne Bays (who believed me when I suggested that Software Engineering and Industrial Psychology were a good mix). There are many more colleagues deserving of my appreciation and I hope that you will come to my website (

http://www.cmbestpractices.com) to enjoy their articles and contributions.

Bob Aiello
Bob.Aiello@ieee.org
http://www.linkedin.com/in/BobAiello

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at Bob.Aiello@ieee.org or link with him at http://www.linkedin.com/in/bobaiello

Leslie Sachs is the COO of Yellow Spider, Inc. A New York State Certified School Psychologist with over 20 years of experience, Ms. Sachs has worked in a variety of clinical and business settings where she has provided many effective interventions designed to improve the social and educational functioning of both individuals and groups. Ms. Sachs has an M.S. in School Psychology from Pace University and interned in Bellevue's Psychiatric Center in NYC. A firm believer in the uniqueness of every individual, she has recently done advanced training with Mel Levine's "All Kinds of Minds" Institute. She may be reached at LeslieASachs@gmail.com or link with her at http://www.linkedin.com/in/lesliesachs

Table of Contents

Preface     xxi

Introduction     xxxiii

PART I THE CORE CM BEST PRACTICES FRAMEWORK     1

Chapter 1 Source Code Management     3

Terminology and Source Code Management     5

Goals of Source Code Management     5

Principles of Source Code Management     6

1.1 Why Is Source Code Management Important?     6

1.2 Where Do I Start?     7

1.3 Source Code Management Core Concepts     9

1.3.1 Creating Baselines and Time Machines     9

1.3.2 Reserved Versus Unreserved Checkouts     10

1.3.3 Sandboxes and Workspaces     11

1.3.4 Variant Management (Branching)     11

1.3.5 Copybranches Versus Deltas     12

1.3.6 How to Handle Bugfixes     12

1.3.7 Streams     14

1.3.8 Merging     15

1.3.9 Changesets     16

1.4 Defect and Requirements Tracking     16

1.5 Managing the Globally Distributed Development Team     17

1.6 Tools Selection     19

1.6.1 Open Source Versus Commercial     21

1.6.2 Product Maturity and Vendor Commitment     21

1.6.3 Extensibility and Open API     22

1.6.4 Don’t Overengineer Your Source Code Management     22

1.7 Recognizing the Cost of Quality (and Total Cost of Ownership)     23

1.7.1 Building Your Source Code Management Budget     24

1.8 Training      24

1.8.1 The “Bob Method” for Training     24

1.9 Defining the Usage Model     25

1.10 Time to Implement and Risks to Success     26

1.11 Establishing Your Support Process     26

1.12 Advanced Features and Empowering Users     27

Conclusion     27

Chapter 2 Build Engineering     29

Goals of Build Engineering     30

Principles of Build Engineering     30

2.1 Why Is Build Engineering Important?     31

2.2 Where Do I Start?     32

2.3 Build Engineering Core Concepts     32

2.3.1 Version IDs or Branding Your Executables     32

2.3.2 Immutable Version IDs     33

2.3.3 Stamping In a Version Label or Tag     33

2.3.4 Managing Compile Dependencies     33

2.3.5 The Independent Build     34

2.4 Core Considerations for Scaling the Build Function     34

2.4.1 Selling the Independent Build     35

2.4.2 Overengineering the Build     35

2.4.3 Testing Your Own Integrity     36

2.4.4 Reporting to Development Can Be a Conflict of Interest     37

2.4.5 Organizational Choices     37

2.5 Build Tools Evaluation and Selection     38

2.5.1 Apache Ant Enters the Build Scene     38

2.5.2 Of Mavens and Other Experts     38

2.5.3 Maven Versus Ant     39

2.5.4 Using Ant for Complex Builds     39

2.5.5 Continuous Integration     40

2.5.6 CI Servers     40

2.5.7 Integrated Development Environments     40

2.5.8 Static Code Analysis     41

2.5.9 Build Frameworks     41

2.5.10 Selecting Your Build Tools     41

2.5.11 Conducting the Bakeoff and Reaching Consensus     42

2.6 Cost of Quality and Training     42

2.7 Making a Good Build Better     42

2.7.1 “Bob-Proofing” Your Build     43

2.7.2 Test-Driven Builds     43

2.7.3 Trust, But Verify     43

2.7.4 The Cockpit of a Plane     44

2.8 The Role of the Build Engineer     44

2.8.1 Know What You Build     45

2.8.2 Partner with Developers     46

2.8.3 Drafting a Rookie     46

2.9 Architecture Is Fundamental     46

2.10 Establishing a Build Process     47

2.10.1 Establishing Organizational Standards     47

2.11 Continuous Integration Versus the Nightly Build     47

2.12 The Future of Build Engineering     48

Conclusion     48

Chapter 3 Environment Configuration     49

Goals of Environment Configuration Control     50

Principles of Environment Configuration Control     51

3.1 Why Is Environment Configuration Important?     51

3.2 Where Do I Start?     51

3.3 Supporting Code Promotion     52

3.4 Managing the Configuration     52

3.4.1 Which Database Are You Using?     53

3.4.2 Did That Trade Go Through?     53

3.4.3 How About a Few Tokens?     54

3.4.4 Centralizing the Environment Variable Assignment     55

3.5 Practical Approaches to Establishing a CMDB     55

3.5.1 Identify and Then Control     56

3.5.2 Understanding the Environment Configuration     56

3.6 Change Control Depends on Environment Configuration     56

3.7 Minimize the Number of Controls Required     57

3.8 Managing Environments     57

3.9 The Future of Environment Configuration     57

Conclusion     58

Chapter 4 Change Control     59

Goals of Change Control     60

Principles of Change Control     60

4.1 Why Is Change Control Important?     61

4.2 Where Do I Start?     61

4.3 The Seven Types of Change Control     61

4.3.1 A Priori     62

4.3.2 Gatekeeping     62

4.3.3 Configuration Control     62

4.3.4 Change Advisory Board     63

4.3.5 Emergency Change Control     64

4.3.6 Process Engineering     64

4.3.7 Senior Management Oversight     64

4.4 Creating a Change Control Function     65

4.5 Examples of Change Control in Action     65

4.5.1 The 29-Minute Change Control Meeting     66

4.5.2 Change Control at the Investment Bank     66

4.5.3 Change Control at the Trading Firm     67

4.5.4 Forging Approvals     69

4.6 Don’t Forget the Risk     69

4.7 Driving the CM Process Through Change Control     69

4.8 Entry/Exit Criteria     70

4.9 After-Action Review     71

4.10 Make Sure That You Evaluate Yourself     71

Conclusion     71

Chapter 5 Release Management     73

Goals of Release Management     74

Principles of Release Management     74

5.1 Why Is Release Management Important?     75

5.2 Where Do I Start?     75

5.3 Release Management Concepts and Practices     76

5.3.1 Packaging Strategies That Work     76

5.3.2 Package Version Identification     76

5.3.3 Sending a Release Map with the Release     77

5.3.4 What Does Immutable Mean?     77

5.4 The Ergonomics of Release Management     77

5.4.1 Avoiding Human Error     78

5.4.2 Understanding the Technology     78

5.4.3 Tools from Build Engineering     79

5.4.4 Avoiding Human Error     79

5.4.5 My Own Three-Step Process     79

5.4.6 Too Many Moving Parts     80

5.5 Release Management as Coordination     80

5.5.1 Communicating the Status of a Release     80

5.5.2 Don’t Forget the Release Calendar     80

5.5.3 RM and Configuration Control     81

5.6 Requirements Tracking     81

5.7 Taking Release Management to the Next Level     81

5.7.1 Using Cryptography to Sign Your Code     82

5.7.2 Operating Systems Support for Release Management     82

5.7.3 Improving Your RM Process      2

Conclusion     83

Chapter 6 Deployment     85

Goals of Deployment     86

Principles of Deployment     86

6.1 Why Is Deployment Important?     87

6.2 Where Do I Start?     87

6.3 Practices and Examples     87

6.3.1 Staging Is Key     87

6.3.2 Scripting the Release Process Itself     89

6.3.3 Frameworks for Deployment     89

6.3.4 What If Bob Makes a Mistake?     89

6.3.5 More on the Depot     90

6.3.6 Auditing Your Release     90

6.4 Conducting a Configuration Audit     91

6.5 Don’t Forget the Smoke Test     92

6.6 Little Things Matter a Lot     92

6.7 Communications Planning     92

6.7.1 Announcing Outages and Completed Deployments     93

6.8 Deployment Should Be Delegated     93

6.9 Trust But Verify     93

6.10 Improving the Deployment Process     93

Conclusion     94

PART II ARCHITECTURE AND HARDWARE CM     95

Chapter 7 Architecting Your Application for CM     97

Goals of Architecting Your Application for CM     98

7.1 Why Is Architecture Important?     99

7.2 Where Do I Start?     99

7.3 How CM Facilitates Good Architecture     99

7.4 What Architects Can Learn From Testers     99

7.4.1 Testing as a Service to the Developers     100

7.5 Configuration Management—Driven Development (CMDD)     101

7.6 Coping with the Changing Architecture     101

7.7 Using Source Code Management to Facilitate Architecture     102

7.8 Training Is Essential     102

7.9 Source Code Management as a Service     103

7.10 Build Engineering as a Service     103

Conclusion     103

Chapter 8 Hardware Configuration Management     105

Goals of Hardware CM     106

8.1 Why Is Hardware CM Important?     106

8.2 Where Do I Start?     107

8.3 When You Can’t Version Control a Circuit Chip     107

8.3.1 A Configuration Item by Any Other Name     107

8.3.2 Version Control for Design Specifications     108

8.4 Don’t Forget the Interfaces     108

8.5 Understanding Dependencies     108

8.6 Traceability     108

8.7 Deploying Changes to the Firmware     109

8.8 The Future of Hardware CM     109

Conclusion     109

PART III THE PEOPLE SIDE OF CM     111

Chapter 9 Rightsizing Your Processes     113

Goals of Rightsizing Your CM Processes     114

9.1 Why Is Rightsizing Your Processes Important?     115

9.2 Where Do I Start?     115

9.3 Verbose Processes Just Get in the Way     116

9.4 SPINs and Promoting the CMM     117

9.5 Disappearing Verbose Processes     117

9.5.1 Agile Processes Just Work     118

9.5.2 Open Unified Process     118

9.5.3 Getting Lean     119

9.5.4 An Extremely Brief Description That I Hope Motivates You to Take a Closer Look at Lean Software Development     119

9.6 The Danger of Having Too Little Process     120

9.7 Just-in-Time Process Improvement     120

9.8 Don’t Overengineer Your CM     120

9.9 Don’t Forget the Technology     121

9.10 Testing Your Own Processes     121

9.11 Process Consultation     122

9.11.1 Transparency That Is Genuine     122

9.12 Create a Structure for Sustainability     122

Conclusion     123

Chapter 10 Overcoming Resistance to Change     125

Goals of Overcoming Resistance to Change     126

10.1 Why Is Overcoming Resistance to Change Important?     127

10.2 Where Do I Start?     127

10.3 Matching Process to Culture     127

10.4 Mixing Psychology and Computer Programming     129

10.5 Process Improvement from Within     129

10.6 Picking Your Battles     131

10.7 Fostering Teamwork     131

10.8 Why Good Developers Oppose Process Improvement     132

10.9 Procedural Justice     132

10.10 Input from Everyone     132

10.11 Showing Leadership     133

10.12 Process Improvement People May Be the Problem     133

10.13 Combining Process and Technology Training     134

10.14 Listening to the Rhythm     135

10.15 Processes Need to Be Tested     136

10.16 Baby Steps and Process Improvement     136

10.17 Selling Process Improvement     137

10.18 What’s in It for Me?     137

10.19 Process Improvement as a Service     137

10.20 Guerrilla Tactics for Process Improvement     138

Conclusion     139

Chapter 11 Personality and CM: A Psychologist Looks at the Workplace     141

Goals of Understanding Personality: What’s in It for Me?     142

11.1 Personality Primer for CM Professionals     144

11.2 What Do CM Experts Need to Consider in Terms of Personality?     146

11.2.1 Communication Styles     147

11.2.2 Do Men and Women Use and Interpret Language Differently?     147

11.2.3 Effective Consultation     148

11.2.4 Verifying the Message     148

11.2.5 Information Processing Preferences     149

11.2.6 Birth Order at Work     150

11.2.7 Firstborns as Leaders     150

11.2.8 The Middle-Born Compromiser     151

11.2.9 The Youngest as Initiator     151

11.2.10 The Only Child     151

11.2.11 Being Yourself     152

11.3 Applying Psychology to the Workplace     152

11.3.1 Effective Teamwork Begins at Home     153

11.3.2 Volleyball or Effective Collaboration     153

11.3.3 Embedding Build Engineers and Testers in the Development Team     153

11.3.4 Blackbox Versus Whitebox Versus Graybox     154

11.3.5 Group Dynamics That Can Damage the Organization     154

11.3.6 Where CM and QA Fit In     154

11.4 Family Dynamics!     155

11.4.1 Indecisiveness     155

11.5 Workplace Culture and Personality     156

11.5.1 Personality and Structure     156

11.5.2 We Already Invented All the Good Ideas     157

11.5.3 Loose Cannons Who Don’t Want to Comply      157

11.5.4 Enforcing Process, While Still Keeping the Train Moving     158

11.5.5 Formulas for Success     158

11.5.6 Caveats     159

Conclusion     159

Chapter 12 Learning From Mistakes That I Have Made     161

Goals of Learning from Mistakes     162

12.1 Why Is It Important to Learn from Our Mistakes?     162

12.2 Where Do I Get Started?     162

12.3 Understanding Our Mistakes     163

12.4 The Mistakes I Have Made     163

12.4.1 Missing the Big Picture     163

12.4.2 Writing Release Automation Can Be Challenging .    164

12.4.3 Thinking That a Good Process Will Carry Itself     165

12.4.4 Failing to Gain Consensus     165

12.4.5 Failing to Show Leadership for CM     165

12.4.6 Becoming Part of the Problem     165

12.4.7 Forgetting to Ask for Help     166

12.5 Turning a Mistake into a Lesson Learned     166

12.5.1 Clarifying What I Need to Get the Job Done     166

12.5.2 Getting the Training That I Need     167

12.6 Common Mistakes That I Have Seen Others Make     167

12.6.1 Ivory Tower     167

12.6.2 Failing to Get Technical and Hands-On     167

12.6.3 Not Being Honest and Open     168

Conclusion     168

PART IV COMPLIANCE, STANDARDS, AND FRAMEWORKS     169

Chapter 13 Establishing IT Controls and Compliance     171

Goals of Establishing IT Controls and Compliance     172

13.1 Why Are IT Controls and Compliance Important?     173

13.2 How Do I Get Started?     173

13.3 Understanding IT Controls and Compliance     174

13.3.1 Sarbanes-Oxley Act of 2002     174

13.3.2 Management Assessment of Internal Controls     174

13.3.3 Committee of Sponsoring Organizations     175

13.3.4 Cobit as a Framework for IT Controls     176

13.3.5 What Does It Mean to Attest to And Report on the Assessment Made by the Management?     176

13.3.6 Health Insurance Portability and Accountability Act of 1996     177

13.3.7 When the GAO Comes Knocking     177

13.3.8 Results of the Audit     178

13.3.9 GAO Reports on NARA’s Configuration Management Practices     179

13.3.10 ERA Configuration Management Plan     179

13.3.11 Areas for Improvement     180

13.3.12 Understanding the Results of the Audit     180

13.3.13 Office of the Comptroller of the Currency     181

13.4 Essential Compliance Requirements     181

13.4.1 Providing Traceability of Requirements to Releases     182

13.4.2 Production Separation of Controls     182

13.5 The Moral Argument for Supporting CM Best Practices     182

13.6 Improving Quality and Productivity Through Compliance     183

13.7 Conducting a CM Assessment     183

13.7.1 Assessment First Steps     184

13.7.2 Listen First Regardless of How Bad the Situation Appears     184

Conclusion     185

Chapter 14 Industry Standards and Frameworks     187

Goals of Using Industry Standards and Frameworks     188

14.1 Why Are Standards and Frameworks Important?     188

14.2 How Do I Get Started?     189

14.3 Terminology Required     189

14.3.1 Configuration Item     189

14.3.2 Configuration Identification     190

14.3.3 Configuration Control     190

14.3.4 Interface Control     190

14.3.5 Configuration Status Accounting     191

14.3.6 Configuration Audit     191

14.3.7 Subcontractor/Vendor Control     192

14.3.8 Conformance Versus Noncompliance     192

14.4 Applying These Terms to the Standards and Frameworks     193

14.5 Industry Standards     193

14.5.1 IEEE 828–Standard for Software Configuration Management Plans     193

14.5.2 ISO 10007–Quality Management Systems–Guidelines for Configuration Management     195

14.5.3 ANSI/ITAA EIA-649-A–National Consensus Standard for Configuration Management     196

14.5.4 ISO/IEC/IEEE 12207 and 15288     196

14.6 Industry Frameworks     196

14.6.1 ISACA Cobit     197

14.6.2 CMM/CMMI     207

14.6.3 itSMF’s ITIL Framework     208

14.6.4 SWEBOK     214

14.6.5 Open Unified Process (OpenUP)     215

14.6.6 Agile/SCRUM     216

Conclusion     217

Index     219

 

Preface

Configuration management (CM) plays a critical role in any technology development effort. I have been involved with implementing and supporting CM for over 25 years and much of what I am about to discuss comes directly from my own personal experience. I have implemented and supported each of these CM practices, often with the agreement that I could be woken in the middle of the night if my processes/automation did not work as expected. As an instructor, I have taught industry strength CM tools to over 900+ technology professionals (again with the offer that they got my home phone number upon successfully completing my class). My colleagues and students have consistently indicated that my passion and love for this discipline has always been abundantly clear. It is my view that configuration management consists of six functional areas:

  1. Source Code Management
  2. Build Engineering
  3. Environment Configuration
  4. Change Control
  5. Release Engineering
  6. Deployment

I have searched for, but never found, any single book (or even a series of books) that covered all of these functional areas. Most CM books are either too narrowly focused on one key area (e.g., building code with Ant) or so “ivory tower” that they did not give me enough information on how to really implement these functions in a practical real world environment. It’s nice to point out the need to “maintain control of all configuration items”, but unless you tell me exactly how to do that in a practical and realistic way, the advice is not truly utilizable. It is my intent both to cast a wide net on the CM practices that you need to understand and also to provide enough detail so that you know not only “what” each CM function entails, but, just as importantly “how” to implement each of the CM functions. I expect that my readers will hold me to that commitment (see the URL of the supporting website below).

The Traditional Definition of Configuration Management

Configuration management or in this context, software configuration management (SCM) has a traditional definition of consisting of four specific functions. They are:

  1. Configuration identification
  2. Change control
  3. Status accounting
  4. Configuration audit

These functions have long been described in industry standards and frameworks and obviously viewed as essential to any valid configuration management effort. While I agree completely that these functions are correct and essential, I find their terminology to be difficult for many technology professionals to understand and appreciate. In this book, I will discuss the traditional CM functions, and I will also suggest a framework for understanding and implementing configuration management in a way that I believe will reflect current industry practices. Specifically, I will show the relationship between the four classic functions and the six functions of source code management, build engineering, environment configuration, change control, release engineering, and deployment that I believe more closely reflect the way that CM is actually done on a day to day basis. This is an important focus of my efforts to make configuration management best practices more approachable and practical for technology professionals to enjoy as part of their own process improvement efforts.

Terminology and CM

Configuration Management, like many other disciplines, suffers from the use of confusing terminology. I am not going to solve that problem in this book, but I will endeavor to at least not make the situation worse. The acronym SCM has been used to refer to both Source Code Management and, more recently, Software Configuration Management. One of my most knowledgeable colleagues has prevailed upon me to not make the situation worse, so I will only use the SCM acronym to refer to the broader Software Configuration Management, which is a specialization of Configuration Management (as opposed to hardware configuration management discussed in Chapter 8). Similarly, the acronym CI is used to refer to both Configuration Items and Continuous Integration. CM terminology can indeed be quite confusing. I can’t do much about the confusion caused by this dual use of CI as an acronym, as it is pervasive, but I will do what I can be as clear as possible. Whenever possible, I will endeavor to use the definitions the IEEE’s SEVOCAB: Software and Systems Engineering Vocabulary, which at the time of this writing could be found at http://www.computer.org/sevocab.

Why I Love CM

I love CM because it is a creative and exciting endeavor that can significantly add value by improving quality and productivity in any technology project. Not only will I discuss what I have learned, but I will also be relating the combined experience of thousands of CM experts who have kindly shared their own expertise and best practices with me over the years that I have been engaged in this work. I owe each of these fine colleagues a debt of gratitude for all that they have shared with me. I have written and published many articles on configuration management and thoroughly enjoyed the feedback that I have received (especially when those supplying it disagreed with me and offered other practical approaches to solving thorny CM related problems). I anticipate that this book will also generate considerable interaction with my colleagues especially through the supporting http://www.cmbestpractices.com website that I have created Please visit this website for up-to-date information on the topics that we discuss in this book as well as to give me feedback about your own experiences with implementing configuration management.

Why I Wrote This Book

I have written this book to share my expertise and experience with implementing all aspects of CM in realistic business, engineering and government environments. I hope that you will find this information to be practical, comprehensive and helpful in implementing CM in a variety of real world situations.

Some topics in CM are evolving so quickly that writing a book on them would be a daunting task indeed. For example, as I write this chapter, my “day-job” is to implement IBM’s latest Application Lifecycle Management (ALM) solution that includes a brand new Source Code Management and automated workflow solution. Therefore, for this book, I will discuss how to select a CM tool in only general terms, but restrict tool specific comments to my support website so that the information can be kept current and accurate. I also hope that you will hold me accountable for the accuracy of every word that I write because I have very strong personal views that CM is essential on a moral, ethical and theological basis. While CM is not my “religion”, doing honest and high quality work is certainly part of my religious belief system. I also view spreading CM best practices as being a model for good corporate citizenship. I have been very active in the virtual community that develops and supports configuration management as well as other aspects of application development. On any given day you can see technology professionals providing each other with substantial assistance without regard for whether or not they work for competing organizations. The community is truly culturally diverse, multilingual, and universal in its respect for and acceptance of others. I am proud to be part of this work and wish my efforts to promote CM best practices to be part of a wider movement to promote effective IT controls, responsible business leadership, and good corporate citizenship resulting in greater services and value for everyone who shares this increasingly tiny world that we live in. To say this in another way, I believe that every government agency, financial services firm (including banks, hedge funds and insurance firms) along with firms that are in the medical, pharmaceutical, and defense (and every other) industry should be required to implement proper IT controls to protect the public who rely upon their services as well as shareholder value. I wrote this book, in part, to help transition this effort from being a burden to instead being a journey in improving productivity and quality. It is my belief that implementing IT controls, including CM best practices, in a pragmatic way should result in higher profitability for the members of the firms, their shareholders, as well as the public who rely upon their services.

Who Should Read This Book

Technology Professionals including development managers, system architects, developers, systems engineers, hardware engineers, quality assurance, quality engineering, operations engineers and technology project managers will all benefit from the information in this book. CTOs, IT auditors and also corporate managers will especially enjoy the sections on establishing IT controls and compliance. Whether you are an Agile enthusiast or working with a classic waterfall lifecycle, this book will help you get your job done better. CM is all about good corporate citizenship. The news media love to report instances of corporate greed and incompetence among those who have a responsibility for providing and maintaining technology for the public good. CM best practices help insure that the global economy runs smoothly, ATMs work correctly, air traffic control systems remain online, and so on. If you want your technology development efforts to be more efficient and to yield higher quality products then this book is for you.

How to Read This Book

You should at least skim the Introduction as this section will give you an overview of the CM functions as well as their overall linkages. You should also feel free to skip to the area that you need help with next. I have endeavored to write each chapter so that it can be read and used separately. In practice, this has often been how I implemented CM. For example, I have often skipped directly to solving the most urgent problems (as indicated by the customer) without being rigid about the order of implementing CM functions. That said, there are some dependencies and I will do my best to describe them as well.

How This Book Is Organized

This book is organized into fourteen chapters divided into four parts. Part I, “The Core CM Best Practices Framework,” consists of six chapters covering source code management, build engineering, change control, environment configuration, release engineering and deployment. Part II, covers Architecture and Hardware CM, while Part III covers the essential people issues that you need to know in order to effectively implement CM Best Practices. Part IV covers Compliance and the Standards (e.g. IEEE) and Frameworks (e.g. ITIL, Cobit, CMMI) needed to establish effective IT Controls. What follows in the next section is a short description of each chapter.

Part I – The Core CM Best Practices Framework

Six chapters make up the Core CM Best Practices Framework.

Chapter 1: Source Code Management

Source code management is an essential starting point for any configuration management function. In this chapter, we discuss the requirements for an effective source code management effort as well as some of the core concepts. In source code management you make sure that you know where all of the artifacts needed by your application are located and that they are all properly identified and can be managed effectively. If we were baking a pie, then Source Code Management would help you ensure that you have all of the correct ingredients on hand and in their proper amounts.

Chapter 2: Build Engineering

Build engineering includes the compilation of all of the configuration items that go into a release. Your build engineering practices need to be efficient, reliable, and repeatable. Build engineering also includes procedures for building in the essential version IDs that are required for configuration identification. Build engineering involves mixing the batter and baking the pie itself.

Chapter 3: Environment Configuration

Environment configuration involves handling the compile and runtime changes necessary for the promotion of code from development to QA to production. It also includes the configuration and management of the requirements. Environment configuration ensures that you have the shelf ready to show off the great pie that you baked.

Chapter 4: Change Control

There are seven functions in change control, including evaluating requests for change, gatekeeping (e.g., promotion), configuration control, emergency change control, process changes, advising on the downstream impact of a potential change, and senior management oversite of change control. Change control decides when the pie is baked and ready to be taken from the oven and sent to the happy person who will enjoy the pie.

Chapter 5: Release Management

Release management involves packaging the configuration items into components that can be reliably promoted and deployed as needed. Release management is effectively putting your pie into the nice box with the open window so that others can see and appreciate the fine work that you have done.

Chapter 6: Deployment

Deployment should be a narrowly defined function of promoting the pre-packaged release to QA or production as needed. This is effectively putting your pie on the truck to be delivered to your consumers (make sure that you get my home address correct for delivery).

This completes the first half of the book covering what I view as being the essential core CM competencies necessary for any CM function. I am really getting hungry now so I have to stop using a pie as a metaphor for CM. The rest of the chapters make up the eight supporting functions that are also important for the implementation of an effective CM effort.

Part II – Architecture and Hardware CM

Architecture and hardware also are candidates for CM.

Chapter 7: Architecting Your Application for CM

This is an often overlooked aspect of configuration management and involves recognizing the interrelationship between application architecture and configuration management. The essential nature of CM is the same whether you are implementing it on a mainframe or your favorite handheld device. But the actual procedures will vary significantly based upon the architecture of your application. So implementing CM on a WINTEL platform may be very different than on a Unix/Linux platform using Java SOA or C++. This chapter is about understanding that relationship.

Chapter 8: Hardware Configuration Management

I need to write a whole book on hardware configuration management. There just isn’t enough recognition of its value and importance in the CM field. I have been frequently asked to write about hardware CM. This chapter begins what I am sure will be a longer journey.

Part III – The People Side of CM

You can't afford to ignore the people side of any business or organizational endeavor. CM is no different.

Chapter 9: Rightsizing Your Processes

My whole career has been focused on implementing process improvement. I have learned that too much process is just as bad as not enough. This chapter is about finding the right balance and implementing just enough process to get the job done.

Chapter 10: Overcoming Resistance to Change

Having a great process does not help anyone if you can’t get your team to accept the process and actually start working in a new and better way. This chapter is about overcoming resistance to change and getting the team to accept and enjoy the new way of doing things.

Chapter 11: Personality and CM: A Psychologist Looks at the Workplace

Leslie Sachs takes the lead in this chapter as she describes the essential people skills that you need to be effective in implementing CM best practices. I get scared when I read Leslie’s work, because she seems to always be eavesdropping on my conversations. Read this chapter if working with people is important to you.

Chapter 12: Learning from Mistakes that I Have Made

I have made lots of mistakes in my career. I have achieved a lot, yet I have also failed to achieve as much as I had hoped. But I have learned a lot from my own mistakes, and this chapter is my effort to share some of my personal improvement efforts to learn from my own mistakes and short comings. This chapter could have been its own book or perhaps the size of a small encyclopedia.

Part IV – Compliance, Standards, and Frameworks

The book ends with the issues involved in establishing IT controls, complying regulations, and the use of industry standards and frameworks.

Chapter 13: Establishing IT Controls and Compliance

Establishing IT controls and compliance is one of my own favorite topics. I like to focus on using these efforts to improve quality and productivity while you are also getting ready to pass your audit. IT controls and compliance is a really critical topic for many organizations and I expect that if you need to meet industry regulations then you will find this information to be extremely valuable.

Chapter 14: Industry Standards and Frameworks

I strongly advocate the use of industry standards and frameworks, but I also believe that much of what has been previously written is difficult to understand and even more difficult to implement. I believe that those of us involved with creating industry standards and frameworks need to write more practical material on how to actually implement standards and frameworks in a realistic and pragmatic way. My focus, in this chapter, is on describing my own personal journey with implementing process improvement using the guidance described in Standards and Frameworks along with the essential skills of tailoring, harmonization and operationalizing the published guidance. This might be the most important chapter in the book and I hope that you will give me your feedback on your efforts to embrace and implement industry standards and frameworks.

Overall, I think that you want to focus on the first half of the book to get the core CM Best Practices and then read the second half of the book in whatever order you choose to cover the topics that you have an immediate need for implementing within your organization.

Acknowledgements

There are a lot of people who have helped me write this book. First, the Aiello family editing team has been amazing. We are very much like a mom and pop candy store except that we write technical journals. My assistant editors have included my sons Shmuel and Dovid (also our webmaster), Massimo, whose ability to see things differently, helped me to perceive concepts in new and different ways (not to mention provided his fresh baked pizza) and Esther whose creativity helped us in so many ways. My youngest princess, Devora, whose hugs and cuddling (not to mention backrubs) always kept me focused on getting the work done. Finally, Leslie, my lifelong partner, who proved that we could be colleagues on multiple levels.

There are many colleagues who I should acknowledge for sharing their expertise and experience. Leading the list would certainly be my colleagues on the IEEE CM Planning working group, starting with our Chairperson, Chuck Walrad and the members of the working group who have taught me so much about CM (and tolerated my diatribes about how we need to write more clearly) including Diego Pamio, Alastair Walker, Darrel Strom, Ranata Johnson and Mike Smith. I have also learned a great deal about Standards from all of my colleagues and mentors on the S2ESC Board including James Moore, Carl Singer, and David Schulz. Equally, helpful were my numerous colleagues on CM Crossroads, including Steve Berczuk, Mario Moreira, Ben Weatherall and, of course Patrick Egan with whom I have worked with on the CM Journal and CM Crossroads for so many years. The folks at Addison Wesley were amazing starting with my development editor Chris Zahn along with Chris Guizikowski and Raina Chrobak. Early in my career I was privileged to work with Dr. Marianne Bays (who believed me when I suggested that Software Engineering and Industrial Psychology were a good mix). There are many more colleagues deserving of my appreciation and I hope that you will come to my website (

http://www.cmbestpractices.com) to enjoy their articles and contributions.

Bob Aiello
Bob.Aiello@ieee.org
http://www.linkedin.com/in/BobAiello

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at Bob.Aiello@ieee.org or link with him at http://www.linkedin.com/in/bobaiello

Leslie Sachs is the COO of Yellow Spider, Inc. A New York State Certified School Psychologist with over 20 years of experience, Ms. Sachs has worked in a variety of clinical and business settings where she has provided many effective interventions designed to improve the social and educational functioning of both individuals and groups. Ms. Sachs has an M.S. in School Psychology from Pace University and interned in Bellevue's Psychiatric Center in NYC. A firm believer in the uniqueness of every individual, she has recently done advanced training with Mel Levine's 'All Kinds of Minds' Institute. She may be reached at LeslieASachs@gmail.com or link with her at http://www.linkedin.com/in/lesliesachs

From the B&N Reads Blog

Customer Reviews