LATEST ARTICLES

Does DevOps Need Agile?

+
-
0
Does DevOps Need Agile?

Does DevOps Need Agile?

I have always taken the position that Agile cannot survive without automated build, package and deployment or what we have come to refer to as DevOps. But DevOps itself works just fine in any software methodology (including waterfall). In a recent meeting in Berlin, I was tasked with the job of considering how DevOps could benefit from Agile principles and practices. No doubt that on a practical basis my work in DevOps almost always focuses on iterative development, grooming backlogs, user stories and embracing Agile principles and practices. But I would love to steal your ideas to do my homework. What do you feel are the real benefits of implementing DevOps in an agile context?

Bob
bob.aiello@ieee.org

How to prevent global system outages

+
-
0
How to prevent global system outages

How to prevent global system outages
By Bob Aiello

The recent global outage caused by a Windows update has raised questions of whether or not we are just too dependent upon software for mission critical operations including airlines, banking systems and hospitals. Many folks talked about returning to paper pads and pens instead of relying upon complex software systems that can break with one faulty software update.

I have often written that we really do know how to reliably build, package and deploy code. While updating software is a very technical endeavor, the weak link in the chain may have more to do with organizational culture, management, leadership and a true commitment to quality than any gap in our technical processes. I was once asked during an interview if I was confident enough in my skills that I would manage the updates to a life support system that my loved one depended upon. Of course, my immediate response was “sure I can do that”. And this seemingly innocuous interview question has haunted me ever since. I have had loved ones dependent upon life support systems and somebody handles the updates to that system. Did they know what they were doing? Could I have done a better job and what if I made a mistake and the system went down?

CM Best Practices including effective source code management, automated build engineering, environment management, change control and automated release and deployment engineering are just the start. Code reviews and continuous testing are also fundamental best practices which many organizations do well. The cool kids at school have advanced our discipline with continuous delivery and deployment along with strategies such as blue/green deploys including that poor canary in the coal mine. We do know how to reliably release software but then why do we have so many serious global incidents from security breaches to global outages?

In many ways, I think that the problem is not in our technical processes but rather in how we run our organizations starting with who is in charge and making the decisions. Too often, folks with positional power do not listen to the technology experts who actually understand the complexities of the work that we do. I have held leadership positions in large organizations where I tried my best to be a positive influence. I have worked to be an industry thought leader including my role in the IEEE with efforts to create international standards in configuration management, DevOps and more recently SRE. High level managers can suffer from not having enough knowledge of technical details required to make the best decisions. Of course, it is essential to be a leader who enables the smart people around you to provide their expert guidance and knowledge. Too often organizational culture silences dissenting views, losing an important perspective from people who have deep technical knowledge. Deming said it best when he declared that we need to “drive out fear.” Many organizations also lack a true commitment to quality, instead focusing on short term profits.

I still believe firmly that we can create and update complex systems in a completely reliable and secure way. We need to focus on enabling organizations where the culture has an absolute commitment to quality and a culture where anyone feels empowered to pull the red cord stopping the assembly line. What say you? What do you feel that we need to do in order to improve our quality and reliability? (You can comment back on the original LinkedIn post here.

IEEE SRE Standards Working group

+
-
0
IEEE SRE Standards Working group

Are you interested in being a part of the future of Site Reliability Engineering (SRE)? Look no further than the IEEE P2675 DevOps working group! We are beginning work on an SRE standard and are seeking individuals to join this exciting project. 

The working group will review industry definitions and views on what SRE means, and especially how it is implemented in highly regulated industries including banking, finance, medical, pharmaceutical, engineering, automotive, aerospace and defense. We will consider what SRE really has to do with reliability, availability, and related terms, and how an SRE standard would align with other industry standards including the ISO 32675 DevOps standard, The IEEE 828 Configuration Management standard, along with many other IEEE/ISO/EIA industry standards.
https://www.iso.org/standard/83670.htm

Should SRE really refer to Systems/Site/Services Reliability Engineering?

SRE thought leaders emphasize the importance of automating tasks often performed manually by operations engineers, and we know that SRE engineers spend a considerable amount of time writing code to identify and address issues before they impact end users. 

If you are excited about the SRE topic and would like to join the award-winning IEEE P2675 DevOps working group, please contact Bob Aiello directly at bob.aiello@ieee.org. Let’s shape the future of SRE together! 

Personality Matters—CM Excellence

+
-
0
Personality Matters—CM Excellence

Personality Matters—CM Excellence
By Leslie Sachs

Excellence in Configuration Management conjures up images of efficient processes with fully automated procedures to build, package and deploy applications resulting in happy users enjoying new features on a regular basis. The fact is that continuous integration servers and great tools alone do not make CM excellence. The most important resources are the technology professionals on our team and the leader who helps guide the team towards excellence. That doesn’t mean that everyone is (or can be) a top performer, even if you are blessed with working on a high performance cross-functional team. What it does mean is that understanding the factors that lead to excellence will enable you to assess and improve your own performance. A good place to start is to consider the traits commonly associated with effective leadership and successful results. This article will help you understand what psychologists have learned regarding some of the essential qualities found among top leaders and others who consistently achieve excellence!

Software Process Improvement (SPI) is all about identifying potential areas of improvement. Achieving excellence depends upon your ability to identify and improve upon your own behavior and effectiveness. It is well-known that we are each born with specific personality traits and innate dispositional tendencies. However, it is an equally well-established fact that we can significantly modify this endowment if we understand our own natural tendencies and then develop complementary behaviors that will help us achieve success!

Let’s start by considering some of the personality traits that help predict effective leadership. One of the first studies on effective leadership was conducted by psychologist Ralph M. Stogdill [1]. This early study identified a group of traits including intelligence, alertness, insight, responsibility, initiative, persistence, self-confidence, and sociability. It is certainly not surprising that these specific traits are valuable for successful leaders and achieving excellence. Being intelligent speaks for itself and of being alert (for new opportunities) and having insight into the deeper meaning of each situation and opportunity. Although general intelligence was for a long time considered static, more recent research suggests that it is possible to bolster one’s genetic inheritance. Certainly, one can consciously strive to develop the behavioral patterns, such as attentiveness to detail and novelty and thoughtful analysis of options, closely associated with intelligence.

You might want to ask yourself whether or not you are responsible, take initiative and show persistence when faced with difficult challenges. Displaying self-confidence and operating amiably within a social structure is essential as well. Do you appreciate why these characteristics are essential for leadership and achieving success and look for opportunities to incorporate these qualities into your personality? To improve your leadership profile, you must also actively demonstrate that you know how to apply these valuable traits to solve real workplace dilemmas. Upon reflection, you can certainly see why CM excellence would come from CM professionals who are intelligent, alert and insightful. Being responsible, showing initiative and being persistent along with having self-confidence and being a social being are all clearly desirable personality traits which lead to behaviors that result in CM excellence.

Stogdill conducted a second survey in which he identified ten traits which are essential for effective leadership. This expanded cluster includes drive for responsibility, persistence in pursuit of goals, risk-taking and problem-solving capabilities, self-confidence, and a drive for taking initiative. In addition to these, Stogdill also discovered that people’s ability to manage stress (such as frustration and delay) as well as their accountability for the consequences of their actions are both integral to leadership success. After all, intelligence, insight, and sharp analytic skills are not very useful if a manager is too stressed out to prioritize efficiently or authorize appropriate team members to implement essential programs Finally, you need to be able to influence other people’s behavior and to handle social interactions. [2] Other noted psychologists have also studied leadership traits and many have identified similar traits.

Jurgen Appelo lists 50 team virtues [3] which, not surprisingly, also correspond to many of the traits identified in Stogdill’s studies and I discussed many of these same traits in the book that I coauthored with Bob Aiello [4]. You need to consider each of these traits and understand why they are essential to leadership and achieving success. Keep in mind that while people are born with natural tendencies, each of us is capable of stretching beyond them if we understand our own personality and identify which behaviors are most likely to lead to the changes we desire. So if you want to achieve greater success, consider reflecting upon your own behaviors and comparing your style with those traits that have been associated repeatedly with good leaders and CM excellence. For example, being proactive in solving problems and having the self-confidence to take appropriate risks can help you achieve success. Remember also that being social means that you involve and interact with your entire team- full team participation maximizes the power of each member’s strengths while minimizing the impact of individual weaknesses.

Configuration Management excellence depends upon the skilled resources who handle the complex IT demands on a day-to-day basis. The most successful professionals are able to take stock of their personality and consider the traits that experts regard as essential for effective leadership. If you can develop this self-awareness, you can achieve success by developing the behaviors that result in strong leadership and excellence in all you do!

References:
[1] Yukl, Gary, Leadership in Organizations, Prentice Hall, 1981, p. 237
[2] Northouse, Peter G., Introduction to Leadership Concepts and Practice Second Edition, SAGE Publications, Inc 2012, p. 17
[3] Appelo, Jurgen, Management 3.0 – Leading Agile Developers, Developing Agile Leaders. Addison-Wesley, 2011, p. 93
[4] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010

Behaviorally Speaking—CM, ALM & DevOps Strategies

+
-
0
Behaviorally Speaking—CM, ALM & DevOps Strategies

Behaviorally Speaking—CM, ALM & DevOps Strategies
by Bob Aiello

Configuration Management (CM), Application lifecycle management (ALM) and DevOps are not easy to implement. In our consulting practice, we develop and implement strategies to support CM, ALM and DevOps in many organizations and the truth is that we are not always satisfied with the results (and sometimes neither is the management who brought us in). We have also been very successful, and largely because we came up with a strategy that made sense for the organization where we were implementing these practices. Coming up the right approach is not always easy and we’ve learned a few lessons along the way that we’d would like to share with you in this article.

What is CM?
The Definition of CM is a topic that has triggered many an enthusiastic debate in the old CM Crossroads forums and groups. (Make sure that you jump in and participate right here by registering for an account!) Traditional CM experts will typically answer that CM is:

Configuration Identification
Status Accounting
Change Control
Configuration Audit

This is certainly true, but it can be very difficult to come up with a strategy to implement these practices in a large multi-platform organization. I have presented my own framework for understanding CM in terms of six core functions that I believe more closely represent the way in which CM is actually practiced on a day-to-day basis. [1]

The six functions are:
Source Code Management
Build Engineering
Environment Management
Change Management
Release Management
Deployment

We have many years of experience implementing each of these six functions in large enterprise-wide environments. The first thing that I always focus on is making CM compelling. You need to start by demonstrating how CM can help your organization (especially your development team) create the software (or what CM gurus call configuration items). Don’t expect everyone to just automatically accept (and believe in) the benefits of good CM. But over time, we have seen many folks come to the conclusion that CM practices make sense. Application Lifecycle Management (ALM) may be a little harder to fully grasp. The key to understanding ALM is to first understand the classic CM function called Status Accounting.

Status Accounting
Status Accounting involves following the evolution of a configuration item throughout its lifecycle. The terminology is a little confusing and you are certainly not accounting in the sense of counting rows of numbers. Instead, you are tracking the status of the configuration items that are being created during the development lifecycle. This sounds great now, but then how do you go about doing status accounting? On a practical basis this is exactly what ALM is all about.

Application Lifecycle Management (ALM)
The ALM is essentially the software or systems lifecycle used to create each of your configuration items. This means that CM is (and always) was a full lifecycle endeavor. So another aspect of your strategy has to be to realize that CM and ALM are focused on the entire lifecycle. So then what exactly makes ALM different than the CM function of Status Accounting? In practice, ALM has a very wide scope from tracking requirements to design, test planning, development, all the way to deployment (and even tracking and retiring configuration items that should no longer be in use). Obviously, CM touches many of the same points as requirements, test cases and design documents all need to be under version control as well. ALM also places a strong focus on tools and tools integration.

ALM Tools
Recently, a colleague of mine chanted the common view that the process is much more important than the tools. I used to believe this, but ALM has taught me that tools do matter a great deal and your strategy needs to include a robust tools selection process (e.g. bake off). ALM’s wide focus[2] means that you need to have the right tools (and process) in place to support every aspect of your software and systems development effort. In practice, this has meant implementing requirements tracking tools with integration to test case management systems. There are two essential reasons for this. The first is that requirements should map to test cases (you want to verify and validate your requirements – don’t you?) and the second reason is that incomplete requirements can be supported by well documented test cases. ALM tools need to focus on integrations to provide a complete and robust full lifecycle solution. One benefit of this approach is enhanced IT Governance and Compliance.

 

IT Governance and Compliance
IT Governance is all about providing the essential information that management needs to make the right decisions. These practices are an essential ingredient is seeing the management can make the best decisions with the input of information that is accurate and relevant. There are a number of organizations that provide information on implementing IT Governance including ISACA. Your strategy should include using industry standards and frameworks for guidance. This leads directly to Compliance which usually refers to complying with regulatory requirements. CM and ALM are essential for supporting both IT Governance and Compliance.

Agile and Lean for CM/ALM Strategy
One of the best strategies that I have implemented was using Agile and Lean practices to iteratively develop CM & ALM processes. For example, one ALM solution that I implemented recently has a complex workflow automation template that can be tailored to the individual needs of the team and project. There was no viable choice but to approach this effort in an iterative way. So I actually setup a separate project in the tool to track changes to the workflow automation template itself. I used the ALM tool to develop and implement the ALM tool! Make sure that you realize that implementing CM and ALM is an effort that requires industry best practices in alignment with your organization and culture.

DevOps consists of principles and practices that help improve communication and collaboration between teams that all too often have very different goals and objectives. While the principles are consistent across all projects, the practices may indeed vary from one situation to another. Read more about DevOps here.

Conclusion
CM, ALM and DevOps are essential for the success of any software or systems development effort. There are many lessons learned and effective strategies for success. Obviously, there are also risks that need to be addressed. The best strategy that I have found is to use the same principles that work for your development effort to guide and management the implementation of your CM and ALM functions. This is an excellent strategy that will help facilitate your success and the success of all of your efforts. Make sure that you drop me a line and share your strategies for CM, ALM and DevOps!

[1] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010.
[2] Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional

Behaviorally Speaking – CM and Traceability

+
-
0
Behaviorally Speaking – CM and Traceability

Behaviorally Speaking – CM and Traceability
by Bob Aiello

Software and systems development can often be a very complex endeavor so it is no wonder that sometimes important details can get lost in the process. My own work involves implementing CM tools and processes across many technology platforms including mainframes, Linux/Unix, and Windows. I may be implementing an enterprise Application Lifecycle Management (ALM) solution one day and supporting an open source version control system (VCS) the next. It can be difficult to remember all of the details of the implementation and yet that is precisely what I need to do. The only way to ensure that I don’t lose track of my own changes is to use the very same tools and processes, that I teach developers, for my own implementation work – thereby ensuring history and traceability of everything that I do. I have known lots of very smart developers who made mistakes due to forgetting details that should have been documented and stored for future reference. It often seems like developers are great at running up the mountain the first time, but it takes process and repeatable procedures to ensure that each and every member of the team can run up the same mountain with tripping. This article will discuss how to implement CM and traceability in a practical and realistic way.

The most basic form of traceability is establishing baselines to record a specific milestone in time. For example, when you are checking changes into a version control tool, there is always a point in which you believe that all of the changes are complete. To record this baseline you should label or tag the version control repository at that point in time. This is basic version control and essential in order to be able to rebuild a release at a specific point in time (usually when the code was released to QA for testing). But how do you maintain traceability when the code has been deployed and is no longer in the version control solution? In fact, you need to also maintain baselines in the production runtime area and ensure that you can verify that the right code has been deployed. You also must ensure that unauthorized changes have not occurred either through malicious intent or just an honest mistake. Maintaining a baseline in a runtime environment takes a little more effort than just labeling the source code in a version control repository because you need to actually verify the correct binaries and other runtime dependencies have been deployed and have not been modified without authorization. It is also sometimes necessary that you find the exact version of the source code that was used to build the release that is running in production in order to make a support change such as an emergency bug fix. Best practices in version control and deployment engineering are very important but there is also more to traceability than just labeling source code and tracking binaries.

When software is being developed it is important to develop the requirements with enough detail so that the developers are able to understand the exact functionality that needs to be developed. Requirements themselves change frequently and it is essential that you can track and version control requirements themselves. In many industries such as medical and other mission critical systems, there is often a regulatory requirement to ensure that all requirements have been reviewed and were included in the release. If you were developing a life support system then obviously requirements tracking could be a matter of life or death. Dropping an essential requirement for a high speed trading firm can also result in serious consequences and it is just not feasible to rely upon testing to ensure that all requirements have been met. As Deming noted many years ago, quality has to be built in from the beginning [1]. There are also times when all requirements cannot be included in the release and choices have to be made often based upon risk and the return on investment for including a specific feature. This is when, it is often essential to know who requested the specific requirement and also who has the authority to decide on which requirements will be approved and delivered. Traceability is essential in these circumstances.

Robust version control solutions allow you to automatically track the sets of changes, known as changesets, to the workitems that described and authorized the change. Tracking workitems to changesets is known by some authors as task based development [2]. In task based development, you define the workitems up front and then assign them to resources to complete the work. Workitems may be defects, tasks, requirements or for agile enthusiasts, epics and stories. Some tools allow you to specify linkages between workitems such as a parent-child relationship. This is very handy when you have a defect come in from the help desk that results in other workitems such as tasks and even test cases to ensure that the problem does not happen again in the next release. Traceability helps to document these relationships and also link the workitems to the changesets themselves. Establishing traceability does not really take much more time and it does help to organize and implement iterative development. In fact, it is much easier to plan and implement agile scrum based development if your version control tool implements task based development with the added benefit of providing traceability.

Traceability can help you and your team manage the entire CM process by organizing and tracking the essential details that must be completed in order to successfully deliver the features that your customers want to see. Picking the right tools and processes can help you implement effective CM and maintain much needed traceability. It can also help you develop software that has better quality while meeting those challenging deadlines which often change due to unforeseen circumstances. Use traceability effectively to accelerate your agile development!

[1] Deming, W. Edwards (1986). Out of the Crisis. MIT Press
[2] Hüttermann, Michael, Agile ALM: Lightweight tools and Agile strategies, Manning Publications 2011
[3] Aiello, Bob and Leslie Sachs. 2011. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional
[4] Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional

 

Call for Articles!

+
-
0
Call for Articles!

Hi Everyone!

I am excited to invite you to get involved with the Agile ALM Journal by contributing your own articles on Agile ALM and DevOps along with all aspects of software and systems development. The Agile ALM Journal provides guidance on Application Lifecycle Management which means that we have a strong focus on DevOps, Configuration Management and software methodology throughout the entire ALM. Articles are typically 900 – 1200 words and should explain how to do some aspect of software methodology. Contact me directly to get involved with submitting your articles and I will help you with getting started, forming your ideas and editing your article for publication.

Common topics include:

  • Software development approaches including agile
  • DevOps throughout the entire software process
  • Configuration Management (including the CMDB)
  • Build and Release Engineering
  • Source Code Management including branching and streams
  • Deployment Engineering (DevOps)
  • Continuous Testing
  • Development in the Cloud
  • Continuous Integration and Deployment
  • Environment Management
  • Change Management

and much more!

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

So How Are Industry Standards Created?

+
-
0
So How Are Industry Standards Created?

So How Are Industry Standards Created?
By Bob Aiello

Industry standards and frameworks provide the structure and guidance to help ensure that your processes and procedures meet the requirements for audit and regulatory compliance. For US-based firms, this may involve passing your SOX audit (for compliance with section 404 of the Sarbanes-Oxley Act of 2002) or acquiring the highly respected ISO 9000 Quality Management System certification expected by many customers throughout the world.

Industry standards are not perfect and some of the specific reasons for why they may fall short of expectations can be traced back to how they were initially created. The process of creating an industry standard is actually quite deliberate and time-consuming.. There are some excellent resources from the IEEE and other standards bodies, which describe the process to draft and implement standards. But I would like to describe some of my own personal experiences participating in the collaboration and teamwork of creating an industry standard. Working closely with other colleagues who are dedicated to excellence has been far and away the most exciting professional experience that I have been fortunate to have.

Please note that this is not an official IEEE article, but rather Bob’s recounting of a personal experience being involved with creating industry standards.

The first step is always to decide on the initial scope and focus of the standard. We then review any existing resources available – including related industry standards and frameworks or simply documents which can help educate the members of the team involved with this effort. The standards working group is a high-performance self-managing self-educating cross-functional team with subject matter experts from a variety of disciplines and perspectives. We do not always agree with each other and, in fact, the discussions can be quite confrontational at times – although always professional and collaborative. These disagreements are a natural expression of the group’s striving to come up with the best approach to advocate in the text of the standard.

We create an initial outline and list of topics to consider and then address the task of creating a working draft. The focus is on “shall” statements which are mandatory (for compliance with the standard) and “should” statements which are recommended. We hold numerous sessions to collaboratively create the initial draft. It is common to assign specific sections to individual members (or subgroups) who then go off and independently create the initial draft wording.

Once the draft is written, it is sent to a few SMEs outside of the working group for their reaction and comment. Once this feedback is evaluated and incorporated, the draft is sent out to a wider group for review and comment and, once again, feedback is incorporated. The objective is to have validation that it is a solid document before it is put out for a vote.

Above all else, the standards creation process is collaborative and transparent. Typically, contributor’s comments are recorded and the reason for their acceptance or rejection documented. We have a strong desire to ensure that the draft standard is aligned with other industry standards and frameworks and do our utmost to harmonize with the current guidance provided by other sources. Final decisions are made and sometimes folks are not happy, but they know that their views are always heard and, most often, recorded for traceability. It is customary for a standard to require a significant percentage of voter approvals for passage and acceptance by the standards body. On occasion, controversial paragraphs have to be dropped in order to obtain the required votes for approval, similar to the negotiations, aka “horse-trading”, for which politics is known. Although such modifications felt to me personally like we were “watering” down the standard just to gain the required consensus, the teams focus and mission is to produce a clear document that will be both respected and adopted.

Over the years, I have written extensively on how to comply with configuration management related standards, including the highly popular IEEE 828 (which I had the privilege to participate in updating). Lots of folks like to criticize standards, but often they are criticizing a document that they have never actually spent the time to read – let alone understand or see implemented effectively.

It has been my personal experience that implementation of a standard requires two key skills. The first is harmonizing the guidance by understanding similar industry standards and frameworks. The second is tailoring, in which we provide a rationale for why specific guidance cannot be followed, if this is in fact necessary.

Here’s your opportunity! We are starting up an effort to create a working group to write an industry standard for DevOps. Please consider getting involved now to help shape the guidance that we provide. Rest assured that I will continue writing about this exciting project in the coming months and your voice is important to us!

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

Call for Participation IEEE P828 – Configuration Management

+
-
0

Call for participation in the IEEE P828 Standard for Configuration Management in Systems and Software Engineering

This standard establishes the minimum requirements for Configuration Management (CM) in Systems and Software Engineering, without restriction to any form, class, or type.

This standard describes CM processes to be established, how they are to be accomplished, who is responsible for doing specific activities, when they are to happen, and what specific resources are required. It addresses CM activities over a product’s life cycle. This standard is consistent with IEEE’s Software Engineering Body of Knowledge (SWEBOK), ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288.

Need for the Project: We currently have only one active standard for CM (IEEE 828-2012) The current standard establishes the minimum requirements for Configuration Management (CM) in Systems and Software Engineering.

A revision of 828 needs to be consistent with the CM process as described in 15288 and 12207. The revised 828 should be consistent with the ISO/IEC 19770 IT Asset Management series and should answer the question of what CM data to track for what types of object. The revised 828 should recognize differences between hardware and software CM and could also discuss CM of services and should work with open source and current tools and release practices. The revised standard must be usable with any life cycle model and including Agile, Lean and iterative waterfall and the revised 828 must be aligned with IEEE P2675 – IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package and Deployment as well as related SC7 standards.

The Standards Creation Lifecycle

+
-
0
The Standards Creation Lifecycle

The Standards Creation Lifecycle
by Bob Aiello.

I have written about my personal experiences being involved with the amazingly collaborative process of writing an industry standard. This article will specify the steps that are commonly followed in creating a draft of an industry standard. We will be following this sort of lifecycle as we work on creating an industry standard for DevOps.

The IEEE lists the following stages in the standards lifecycle:

  1. Initiating a Project
  2. Mobilizing a Working Group
  3. Drafting a Standard
  4. Balloting a Standard
  5. Approving a Standard
  6. Maintaining a Standard

For this article, our focus will be on step 3, which is the process to draft a standard. Creating a draft usually involves the following steps:

1. Decide on the initial scope and focus.
2. Create an initial outline, which will likely change several times over the drafting process.
3. Identify similar standards and frameworks, which will be reviewed by the team.
4. Assign areas for each member of the working group to research and then share with the working group. (The working group is self-teaching and knowledge based. Additional SMEs outside of the working may be asked to present material to educate the team).
5. The initial outline is revisited several times and updated.
6. Sections of the draft are assigned to volunteers, sometimes in pairs, who go off and draft the initial language.
7. An editor consolidates input and creates the initial draft, which is reviewed in a series of sessions. This step is often quite time consuming.
8. The initial draft is sent to a few subject matter experts outside of the working group for review and comment.
9. Feedback from the reviewers is incorporated into the draft standard and sent out to a wider audience. This process is iterative and the team may find themselves reworking major sections of the standard, and in rare cases, even the scope of the standard itself.
10. Finally, the initial draft is complete and sent out for ballot and comments may still come in from the wider balloting community requiring additional updates.

Above all, the standards creation process is collaborative. There are often many different views and perspectives. The process is also very transparent. Differing views may be expressed and they should be tracked in a document. There should be a documented rationale for rejecting a suggested change or edit to the draft standard. Every effort should be made to harmonize to related industry standards and frameworks. In practice, decisions are made to move the standard along.

The working group chair ensures that the dialog is constructive. If there are personality conflicts or (less than amiable) agendas it is possible that members will be separated from the group. This happens most often due to personality clashes, but can also be due to a vendor trying to hijack the standard to promote his business or product. Vendors are encouraged to participate as they often have highly experienced subject matter experts and it is in their best interests to ensure that industry standards are robust and viable. However, standards must be vendor neutral in every way.

Industry standards are not perfect and there are specific reasons for why they may fall short of expectations. But the process of creating an industry standard is actually pretty robust. I hope that you will consider joining our effort to create an industry standard for DevOps!

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

The IEEE P2675 Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package and Deployment

+
-
0
The IEEE P2675 Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package and Deployment

IEEE P2675 – IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package and Deployment is now available for purchase from the IEEE.

This 95 page document specifies technical principles and practices to build, package and deploy systems and applications in a reliable and secure way. The standard focuses on establishing effective compliance and IT controls. It presents principles of DevOps including mission first, customer focus, left-shift, continuous everything, and systems thinking. It describes how stakeholders including developers and operations staff can collaborate and communicate effectively. Its process outcomes and activities are aligned with the process model specified in ISO/IEC/IEEE 12207, Systems and software engineering – Software life cycle processes, and in ISO/IEC/IEEE 15288, Systems and software engineering – System life cycle processes.

Disciplined DevOps – Achieving Success in Finance, Banking and other industries

+
-
0
Disciplined DevOps – Achieving Success in Finance, Banking and other industries

https://youtu.be/VgZdZXXMQM0

CM Best Practices: Practical Methods that Work in the Real World

+
-
0
CM Best Practices: Practical Methods that Work in the Real World

Based upon Bob Aiello’s book on CM Best Practices, this video covers the core CM Best Practices of source code management, build engineering, change control, environment management, release engineering and deployment automation. Accelerate your software development with CM Best Practices!

Video: Exploring IoT for DevOps

+
-
0
Video: Exploring IoT for DevOps

123...11Page 1 of 11