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

Personality Matters- Paranoia in the Workplace

+
-
0

Personality Matters- Paranoia in the Workplace
By Leslie Sachs

One of the most difficult personality types to deal with is the person who always seems distrustful of others. Sometimes, this lack of trust is well-justified and sometimes it is really a manifestation of some dysfunctional personality issue. Fortunately, you probably won’t find too many severe cases in your workplace where the person is actually so paranoid that they are dissociated from reality. Psychologists sometimes diagnose this mental illness as paranoid schizophrenia, which may require medications and intensive therapy to manage. What is far more common is the borderline personality who manages to operate within a normal workplace environment, but always seems to be a little “off”. Eccentric behavior is not in-and-of-itself a reason to suspect that someone suffers from mental illness, but sometimes the behavior and personality of a co-worker may be so extreme that it impacts other people’s ability to work. This article will help you better understand this situation and suggest a few ways in which you can deal with difficult personality types such as the paranoid.

Harry Stack Sullivan was an American psychiatrist who noted that paranoia may be associated with suspicion, a tendency to blame others and also a heightened sense that one is being persecuted. [1] If you have a co-worker who exhibits some or all of these dysfunctional behaviors then you are not alone. Some folks just have a disposition where they are always expecting the worst from others and, quite often, this tendency may actually result in a self-fulfilling prophecy such that their overly defensive behavior elicits responses from others that actually reinforce their view that someone is always out to “get” them. As Dr. Sullivan noted, it is common for the person to then resort to blaming others in an attempt to protect themselves in what may seem like a silly turf war. Unfortunately, many of these folks take these incidents very seriously and may truly feel that they are being persecuted. These defense mechanisms may be quite destructive to not only the person themselves, but to everyone around them, too.
People who have trust issues often find it difficult to collaborate and cooperate with others. This can make it very tough in a technology organization where everyone has to rely upon each other for specialized expertise. Sometimes, people with difficult personalities actually focus on being experts in a specific technology area that enables them to feel safe because they have complete control and power due to their specialized knowledge and often extensive knowledge of institutional history. However, try not to pre-judge specific situations and consider for a moment that sometimes a little suspiciousness can actually be justifiable and perhaps partially a consequence of a given circumstance.

For instance, there are some organizations that just do not foster trust and collaboration. Employees who work in dysfunctional organizations may understandably exhibit dysfunctional behavior. If you are the new guy on the block, you may not know all of the organizational history and consequently may not fully understand why some employees seem unusually distrustful or have developed other defense mechanisms to defend their turf. One typical example is the organization that attempts to “motivate” their employees through a constant threat of layoffs or other termination. Creating a state of fear does not often result in productive, effective and loyal employees. Some managers use their positional power to try to control and motivate others through fear and intimidation. While respect for authority is important, there are much more effective ways to motivate employees than just fear, including fear of losing one’s job and livelihood.

The middle ground often involves understanding the person within the context or situation that they must function. If you are working in an army during a time of war then you will likely react very differently than if you are working in an internet startup company. So, here are some thoughts on how to navigate these difficult situations. First and foremost, effective communication is essential. If you find yourself dealing with a person who seems unreasonably distrustful, listening carefully to their view is a good starting point. After you have demonstrated an interest in their input, you can share your perspective and try to be clear about what you need. Conflicts in the workplace are often the result of a misunderstanding or even some institutional history that occurred long before you even joined the organization. You should consider who else can help you navigate these waters.

Your own manager may be able to fill you in on what factors have led to this state of affairs. Sometimes dysfunctional behaviors are a consequence of corporate politics, but also consider that there may be some other much more benign factors in place. We all go through life stresses. You may be catching someone as they are trying to handle their “day” job while also dealing with a demanding family situation that would make anyone short-fused. Another possibility is that the person is taking medication for some medical condition that results in behavioral side effects. Employees obviously have a right to privacy, but sometimes managers are made aware of these issues by HR so that the company may be as supportive as possible.

The best organizations consider the needs of their employees and try to provide a workplace that is conducive to success and productivity. Even in such well-run organizations, though, you may encounter difficult personalities. Hopefully, you won’t have to deal with too many people who are truly paranoid, but you will probably encounter at least a few colleagues during your career who seem remarkably distrustful, blame others and seem to believe that they are truly being persecuted. These situations are never easy and your best approach is to try to communicate effectively, if possible. The goal is to demonstrate understanding of their position while explaining your needs, as well. When possible, reach out to your own available resources – from your manager, and, in extreme cases, to HR. I know of one case where an employee who was on medication was actually physically threatening other employees. The workplace must be free of hostile and disruptive behavior from both a legal and business perspective. Feel free to drop me a line if you come across challenging situations that you would like us to address in future articles. The best work environments are both productive and respectful of their employees and, with good communication, you should be able to navigate successfully even when confronted with some difficult personalities!
References
[1] Harry Stack Sullivan, Personal Psychotherapy Early Formations, W.W. Norton & Company, Inc., 1972
[2] Meyer Friedman, Type A Behavior: Its Diagnosis and Treatment (Prevention in Practice Library). Springer 1996
[3] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[4] Aiello, Bob and Leslie Sachs. 2010. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.
[4] Byrne, Donn. 1974. An Introduction to Personality: Research, Theory, and Applications. Prentice-Hall Psychology Series.
[5] Appelo, Jurgen. 2011. Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley Signature Series.

Personality Matters- The Danger of Agreeable People

+
-
0

Personality Matters- The Danger of Agreeable People
By Leslie Sachs

Technology professionals often need to get along with some interesting personalities. While sales and management professionals pride themselves on their people skills, some technology geeks find it challenging to deal with others, especially those with noticeable quirks. I work closely with a number of interesting personalities in our consulting practice- including our lead principal consultant, a well-known expert in configuration management. Truth be told, sometimes stubborn opinions can be tough to accept even when the person is an industry expert. Sometimes, I wish that the person that I am dealing with could be just a little bit more amicable. However, it is equally true that too much of a good thing certainly comes with its own set of challenges. In fact, dealing with overly agreeable people can be fraught with obstacles, although quite different than those usually associated with the stereotypical stubborn geek who seems to not be able to bend or compromise. This article will help you understand and deal with the unexpectedly challenging aspects that you may experience interacting with some agreeable people.

Psychologists have spent decades researching personality [1] and formed many different models to explain the behaviors that we may observe in the people we interact with on a daily basis. One of the most well-respected models, known by the acronym OCEAN, is the five factor model based upon many studies. The five factors, openness, conscientiousness, extraversion, agreeableness, and neuroticism describe essential dimensions of personality. We all have some degree of each of these core qualities in our own personality, although the specific balance of each factor can certainly vary considerably from one individual to another. Successful sales professionals are typically high in extraversion while police and law enforcement personnel are often focused on conscientiousness. Folks who have personalities more geared towards being agreeable typically exhibit highly social behaviors and enjoy the company of others, often demonstrating more kindness, empathy and affection for others than the average person. Sometimes these people come across as “pack animals” who seem to be most comfortable operating within the context of a group. By definition, folks who are agreeable prefer to get along and their tendency to reflexively concur with others is exactly why problems may arise.

The dysfunctional side of agreeableness manifests itself in extreme conflict avoidance. These are the people who just cannot take a stand and always seem to forgo their own will for the sake of “getting along” with others. In our book on configuration management best practices, we discussed the middle child who is often the peacemaker in the family [3]. This behavior is often beneficial and can come in handy in helping others understand one another’s differing views. Unfortunately, though, being agreeable becomes dysfunctional when the person just cannot take a stand or will not engage in uncomfortable conversations, including what most of us would regard as necessary negotiation. The overly agreeable person will often avoid letting you know where they really stand on the issues and will typically do almost anything to avoid conflict. Agreeableness is nice in appropriate amounts, but someone who habitually goes along with the crowd may reach a breaking point where they just cannot take the disparity between what they say and what they feel and, at such stressful times, their response may be extreme as it has been building up for so long.

Technology professionals often need to analyze tough problems and collaborate to arrive at consensus on how best to address and resolve problems. It’s no surprise that smart people don’t always agree on how to fix complex technology problems. When dealing with a systems outage, the situation may be very tense and effective technology professionals must be able to express their views and listen to the opinions of others, too. In a crisis, tact and diplomacy may be less than optimal and people with a thin skin may find it hard to cope with the stress of feeling that they are under attack. Some people back off and actually become passive-aggressive, allowing those with either positional power or perhaps just a loud voice to make the decisions – which may or may not be the optimal choice. Effective leaders create environments where everyone can feel safe expressing their professional views and experience-based opinions.

Dealing with a smart analytical person who tries to steer clear of conflict may require some very strong people skills and this is exactly where you can emerge as a leader within your group. Creating an environment where everyone’s opinion is expressed and the team collaborates to reach consensus is by far the best problem-solving strategy. The most effective teams frequently consist of diverse personality types and have a common value of respect and consideration for each person. Although most people enjoy the validation of hearing opinions in alignment with their own views, confident members of successful technology teams work together to encourage the selection of correct decisions based upon facts, whether they come from the most popular member of the team or the quiet non-confrontational guy in the corner who just happens to really know how to configure the software to get your system up and running!

References:
[1] Byrne, Donn. 1974. An Introduction to Personality: Research, Theory, and Applications. Prentice-Hall Psychology Series.
[2] Wiggins, Jerry S. PhD (Editor), The Five-Factor Model of Personality: Theoretical Perspectives The Guilford Press; 1996
[3] Aiello, Bob and Leslie Sachs. 2010. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.
[4] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[5] Meyer Friedman, Type A Behavior: Its Diagnosis and Treatment (Prevention in Practice Library). Springer 1996

Southwest Glitch Strands Thousands

+
-
0

On Wednesday, July 20th, Southwest Airlines suffered a massive systems outage which resulted in the airline being essentially grounded, with over a thousand flights cancelled [1]. This incident forced the airline to temporarily resort to manual procedures which could not handle the normal volume, causing widespread delays and cancellations. The airline had previously suffered a significant outage in 2015 when over 500 flights were cancelled due to another systems glitch. Southwest CEO Gary Kelly was quoted as saying that the cause of the latest outage was a backup system which failed to take over when a router failed. Ironically, this more recent incident occurred shortly after the airline announced record profits, raising the question of whether or not enough efforts are being made to upgrade the airlines critical support systems. Kelly was further quoted as saying, “Southwest has an aging technology infrastructure”, but “the airline has been making significant investments to upgrade it”. Southwest is reported to claim that “it expects to replace the longstanding reservations system next year and replace other key systems over the next three to five years”. Let’s hope that the airline will embrace industry best practices, including DevOps, related to software and systems upgrades. Otherwise, future reports will likely describe outages due to the attempted improvements themselves.

Editor footnote added July 26th, 2016
[1] According to an article published July 25th, 2300 flights were cancelled and thousands more delayed. The cost of the outage may be as high as 10 millions dollars.

Behaviorally Speaking – Using ALM to Drive DevOps

+
-
0

Behaviorally Speaking – Using ALM to Drive DevOps
by Bob Aiello

DevOps focuses on helping the development and operations teams work together more effectively by enabling better communication and collaboration. One way that this is accomplished is by moving the application build, package and deployment upstream, allowing operations to more effectively participate in automating the entire deployment pipeline earlier in the lifecycle and as well as gain the requisite knowledge required to understand how to support the application. DevOps clearly works well and both development and operations benefit from DevOps best practices. But there are other essential stakeholders who can also benefit from improved communication and collaboration, including information security, QA and testing. The fact is that every stakeholder, from the business analyst to the DBA, needs to understand their particular role and assigned tasks as well as the work being accomplished by other members of the team. Application Lifecycle Management (ALM) provides the structure and framework that ensures that every member of the team knows what they need to accomplish and how to communicate effectively with the other members of the team. This article explains how the ALM can drive DevOps!

DevOps is a set of principles and practices that focus on helping development and operations communicate and collaborate more effectively. Developers are typically focused on creating software with new features and responding to customer requests as quickly as possible. Operations has a very different focus and is primarily concerned with maintaining a reliable service environment. Much has been written about the natural conflict that exists between development and operations. But the truth is that many other groups also have a focus that often fails to really consider the requirements of the other stakeholders. Organizational silos can have a detrimental impact upon any development effort and DevOps provides us with the best practices necessary to foster effective communications and collaboration. The ideal scenario is to develop teams that are cross-functional and self-organizing. This approach provides a lesson as to exactly why DevOps is effective.

High performance teams are typically self-organizing and often cross-functional [1]. While having a team of technology experts who can perform any role is ideal, it is often not very practical. You can still realize the benefits of DevOps by embracing application lifecycle management (ALM) which helps by defining the workflow for the entire software and systems lifecycle. ALM has its roots in the software development lifecycle (SDLC) which typically defined stages including requirements, design, development, and testing. The ALM actually takes a much wider view.

The ALM defines the tasks, roles and responsibilities that are required to support the entire software and systems lifecycle. This effort includes defining requirements, design, development, testing, but also other related functions including ongoing systems support functions such as the service desk. Application Lifecycle Management takes an integrated and comprehensive approach and relies upon a robust workflow automation tool for its organization and success. The ALM provides transparency, traceability and, most importantly, knowledge management and communication which is the key lesson that we learn from effective DevOps. While cross-functional teams are often ideal and very effective, sometimes organizations must maintain a separation of controls.

In highly regulated industries such as banking and finance, federal regulatory requirements exist for a separation of roles. For example, the technology professionals who write the code are not permitted to be the same resource who build, package and deploy the code. These restrictions, known as IT controls do not prevent organizations from embracing DevOps principles and practices. Whether you are agile or have reason to use a waterfall methodology, the core lesson from DevOps is really about communication and collaboration. Developers have specialized knowledge that must be shared with the operations team in order to successfully maintain and support the runtime systems. The fact is that each team has specialized knowledge that can benefit each of the other stakeholders.

DevOps includes information security (InfoSec), QA and testing as key stakeholders. InfoSec can learn a great deal from developers and both development and information security can learn from the QA and testing professionals. The ALM helps to define what each stakeholder brings to the table and facilitates sharing knowledge and information which is essential for success. These practices improve productivity and quality. It is my own experience, that the most effective way to embrace DevOps with the wider ALM perspective is in small steps. Continuous process improvement (CSI) is one of the effective methodologies that can help you to start at the beginning and work your way through embracing each of the roles in the ALM. DevOps focuses on effective communication, collaboration and knowledge sharing. Using the ALM, you can understand all of the different roles and tasks required in the software and systems lifecycle. Using the ALM to drive your DevOps efforts can help your team embrace DevOps principles and practices for success!

[1] Mankin, Don, Cohen, Susan G., Bikson, Tora K., Teams and Technology : Fullfilling the Promise of the New Organization, Harvard Business School Press, 1996
[2] Harvey Robbins and Michael Finley, Why Teams Don’t Work – What Went Wrong and How to Make it Right, Peterson’s Pacesetter Books, 1995
[3] Bob Aiello and Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work, Addison-Wesley Professional, 2011
[4] Deming, W. Edwards (1986). Out of the Crisis. MIT Press
[5] Bob Aiello and Leslie Sachs, Agile Application Lifecycle Management – Using DevOps to Drive Process Improvement, Addison-Wesley Professional, 2016

Subscribe to the Agile ALM DevOps Journal !!

+
-
0
Subscribe to the Agile ALM DevOps Journal !!

Subscribe to the Agile ALM DevOps Journal !!

Hi,

I am excited to invite you to subscribe to our new online publication which provides guidance on Configuration Management Best Practices, Agile Application Lifecycle Management (including videos) and, of course DevOps. Our publication explains hands-on best practices required to implement just enough process to ensure that you can build software and systems that are reliable and secure. Based upon our new book, Agile Application Lifecycle Management – Using DevOps to Drive Process Improvement, the Agile ALM DevOps Journal seeks to promote a dialogue that is really needed in the industry today. We will discuss practical approaches to implementing the Agile ALM using DevOps best practices including continuous integration, delivery and deployment. We will also discuss process improvement strategies that work in large organizations that must comply with federal regulatory guidelines, along with smaller teams that may very well grow as they become successful. We are taking this journey together and our goal is to ensure that you have a voice and can share your experiences along with learning from other colleagues too.

Enjoy Leslie Sachs’s amazing column: Personality Matters and Bob Aiello’s column: Behaviorally Speaking.

We will also report on major incidents where organizations clearly need to improve on their ability to develop and deliver software effectively, including the recent Southwest systems glitches which resulted in thousands of flights being cancelled and thousands more being delayed. We will also bring you exciting technical product announcements such as jfrog’s new xray, which helps to scan your runtime objects, including docker images, for vulnerabilities. This is an exciting time to be in the technology field. Join the revolution!

You can submit your articles for publication to share your own knowledge and experience!

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

PS. you received this announcement because you registered on the CM Best Practices website. If for any reason you do not wish to be on our mailing list, just drop me a note and I promise that I will remove your contact information immediately.

Personality Matters- Introducing Positive Psychology

+
-
0

Personality Matters- Introducing Positive Psychology
By Leslie Sachs

Many of my articles focus on identifying and dealing with dysfunctional behaviors in the workplace, such as paranoia or the learned helplessness that we have seen in many IT operations shops when systems went down even after the technical personnel warned that there was a problem. Psychology has long focused on pathologies in a valiant effort to identify and cure mental illness. However, one limitation with this approach is that focusing on the negative issues can sometimes become a self-fulfilling prophecy. First year medical students are notorious for thinking that they have almost every illness that they learn about in their classes. If you want an effective and healthy organization, then it seems obvious that it is essential to focus on promoting healthy organizational behavior. Psychologists Martin Seligman and Mihaly Csikszentmihalyi have pioneered a new focus on a positive view of psychology and this article will help you to understand and begin to apply these exciting and very effective techniques.

Technology leaders from CTOs to Scrummasters work every day to foster the optimal behaviors that lead to improved productivity and quality. That said, we all know that dealing with difficult people and dysfunctional behaviors can be very challenging and sometimes disheartening. Seligman and Csikszentmihalyi wrote that “psychology has become a science largely about healing. Therefore, its concentration on healing largely neglects the fulfilled individual and thriving community.” [1] Instead of concentrating so much energy on remediation, it would be better to empower technology leaders to focus on and encourage positive and effective behaviors in the workplace. Martin Seligman and Mihaly Csikszentmihalyi, note that “the aim of positive psychology is to begin to catalyze a change in the focus of psychology from preoccupation only with repairing the worst things in life to also building positive qualities [2].” Seligman delineates twenty four strengths, ranging from curiosity and interest in the world to zest, passion and enthusiasm, which he suggests are the fundamental traits of a positive and effective individual [3]. Notably, playfulness and humor, along with valor, bravery and a sense of justice, are also listed among these traits that Seligman describes. So, how do we apply this knowledge to the workplace and how can we use this information to be more effective managers? The fact is that we all know people whom we admire and we have all had more than a few employers who seemed less than completely effective.

Effective leaders do indeed exhibit valor, bravery and a sense of justice in identifying barriers to organizational success. The best leaders are not afraid to deliver a tough message and also use their positional power to help teams achieve success. Technology leaders are often particularly motivated by curiosity and exhibit interest in the world, as well as a love of learning. Most also display considerable enthusiasm and passion for their work. Other traits frequently observed in strong leaders include kindness and generosity, along with integrity and honesty. Successful leaders usually also exhibit perseverance and diligence. It hardly comes as a surprise that so many of these strengths are specified as beneficial traits. In fact, many of these aspects had been discussed earlier by Abraham Maslow and Carl Rogers in their work on Humanistic Psychology, a discipline which focuses on helping people to achieve success and realize their full potential. Positive psychology is providing a useful framework for understanding the traits which lead to success both at an organizational level, and also for each of us individually. Much of what positive psychology advocates aligns well with agile methodologies and the agile mindset which many organizations are finding to be so effective, especially in creating an environment where each stakeholder feels empowered to do the right thing and to speak up when there are problems or barriers to success.

Quality management guru W. Edwards Deming noted long ago the importance of healthy behaviors such as driving out fear, in order to ensure that your employees are willing to speak up and warn of potential issues [4]. Clearly, positive behaviors lead to highly effective teams and successful organizations.

Positive psychology cannot solve every problem and there is no doubt that many organizations have cultures and environments that just do not foster success. However, if you are a technical leader (or wish to emerge as a technical leader), then understanding the significance and impact potential of encouraging positive traits is essential for your success. In future articles, we will discuss strategies for employing these techniques in the workplace. Helping your organization to embrace and cultivate positive and effective behaviors will increase the productivity and success of every endeavor!
References:
[1] Seligman, M. E. P., & Csikszentmihalyi, M. (2000). Positive psychology: An introduction. American Psychologist, 55, 5–14
[2] Seligman, Martin.  (2002). Authentic Happiness: Using the New Positive Psychology to Realize Your Potential for Lasting Fulfillment, Free Press, New York
[3] Abramson, L. Y.; Seligman, M. E. P.; Teasdale, J. D. (1978). “Learned helplessness in humans: Critique and reformulation”. Journal of Abnormal Psychology, 87
[4] Deming, W. Edwards (1986). Out of the Crisis. MIT Press

Aiello, Bob and Leslie Sachs. 2011. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley Professional.

Aiello, Bob and Leslie Sachs. 2016. Agile Application Lifecycle Management: Using DevOps to Drive Process Improvement. Addison-Wesley Professional.

System Outages Cast a Cloud Over Amazon

+
-
0
System Outages Cast a Cloud Over Amazon
System Outages Cast a Cloud Over Amazon

By Bob Aiello

Banking and financial services firms are among those companies required to provide secure and reliable platforms, both to comply with regulatory requirements and to meet their own business objectives. It has become common for many of these firms to embrace cloud-based service providers as they offer highly scalable and elastic services, often at a significant cost savings. Such choices are not without their own dangers, though, as banks and other firms recently discovered in Sydney, Australia. According to published reports, a number of firms were impacted by an Amazon Web Services outage. Those adversely affected included banking services and retailers, among others. It was also reported that “Amazon Web Services, a web hosting platform popular with several banks and retailers, has been blamed for many of the ATM and Eftpos problems which have affected a number of banks and their customers, including ME Bank and Commonwealth Bank”. Among those hit were ATMs from ME Bank and Commonwealth Bank. Millions of Australian banking customers were unable to access ATM and Eftpos services … after severe storms on the east coast caused widespread damage, including a major outage at a cloud computing service used by several banks. While the banks blamed the weather and their cloud service provider, Amazon itself focused on their platform’s ability to provide consistent and reliable service. As reported, Amazon itself blamed the clouds (this time the real clouds). Amazon provided additional details saying “that bad weather meant that… our utility provider suffered a loss of power at a regional substation as a result of severe weather in the area. This failure resulted in a total loss of utility power to multiple AWS facilities.” Amazon was quoted as explaining that its backups employ a “diesel rotary uninterruptable power supply (DRUPS), which integrates a diesel generator and a mechanical UPS.” Amazon’s supposedly uninterruptable power supply was consequently interrupted.

Amazon was not the only company which suffered outages due, in part, to inclement weather and no one can say that the impacted banks would not have suffered outages if they had not been using Amazon Cloud Services. But this much is certain: banks and other financial services firms have regulatory requirements to provide secure and reliable platforms. When a storm, hurricane or other natural disaster hits, consumers want to be able to get access to their money. Most regulatory experts would agree that banks cannot just blame their cloud service providers when their systems are not available. In the banking industry, this is pretty close to a “dog ate my homework excuse”. The cloud has many advantages, but firms may want to have an “on-prem” [2] disaster recovery capability – just in case.

 

[1] Additional technical detail included “a set of breakers responsible for isolating the DRUPS from utility power failed to open quickly enough.” That was bad because these breakers should “assure that the DRUPS reserve power is used to support the datacenter load during the transition to generator power.”

[2] – On-prem means “on premises” instead of outsourced cloud-based providers.

Behaviorally Speaking – DevOps Drives Cybersecurity

+
-
0

Behaviorally Speaking – DevOps Drives Cybersecurity
by Bob Aiello

DevOps focuses on improving communication and collaboration between the development and operations teams. This is no easy task as they each have very different priorities and the truth is that DevOps impacts other groups as well including QA, testing and, most importantly, information security (InfoSec). In a time when Cyber attacks can originate anywhere from a lone high school student to an organized crime, Cybersecurity is becoming a major concern, and this is where you need to focus on ensuring that your InfoSec function has all the necessary support from the other members of the team. DevOps is, above all else, a set of principles and practices that focus on improving communication between all stakeholders. Information security is a key stakeholder within any organization and depends upon effective DevOps for its success. This article will help you use DevOps to drive your InfoSec initiatives.

Information security is responsible for establishing policies that help ensure a secure environment. Understanding your threat level is an essential first step. You may be dealing with hackers from far away lands or a lone antagonist trying to show that he knows how to break into systems and post his message on your website. Other more serious forms of cyber attacks can involve state sponsored cyberterrorism designed to sabotage critical infrastructure from electrical grids to nuclear facilities. InfoSec encompasses a set of practices that help maintain a secure environment. The completely secure environment is known as the trusted base, and includes the underlying hardware platform, operating system and the applications which provide your end-user functionality. The National Institute of Standards and Technology (NIST) publishes a series of standards including the Guide for Security-Focused Configuration Management of Information Systems (NIST 800-128). There are several other security related standards that also impact configuration and release management. But the interesting fact that is that Information Security and the NIST related standards actually depend upon Configuration Management (CM).

Configuration Management best practices are described in industry standards including IEEE 828, EIA 649 and ISO 10007 along with frameworks such as CMMI, Cobit and ITIL. The security standards include the NIST and ISO 27000 family of standards and they all reference and depend upon the aforementioned configuration management standards and frameworks. InfoSec could not possibly be effective without CM and we increasingly see that DevOps facilitates InfoSec too. To understand the real life application of these standards and frameworks, it is best to start by examine how application code is built, packaged and deployed.

DevOps helps to ensure that we know exactly what configuration items (CIs) need to be built and that we use the correct source code baselines to build them. These best practices, based upon industry standards and frameworks, enable you to build fully verifiable configuration items (CIs) and to embed immutable version IDs as part of the automated build procedure. Immutable version IDs are essential for conducting a physical configuration audit which an essential function to comply with audit and regulatory requirements. InfoSec also relies upon the configuration audit to verify that the correct configuration items were built and deployed as planned. Release packaging is also a key aspect of this process.

Many build tools such as Ant, Maven, and Make provide routines to automate the creation of release packages such Java JARs, WARs and EARs. These automated procedures also enable you to create a manifest that contains essential information about the configuration items in the container and the release package itself. Another important best practice in the use of cryptography to ensure the integrity of the release package and its contents.
If you have ever downloaded software from the internet then you have likely come across packages that have been signed and verified using cryptographic hashes such as MAC-SHA1 and MD5. Cryptographic hashes can be used to ensure that the authenticity of the source or what is known as non-repudiation. They also can be used to verify that the package has not been tampered with itself. Cryptography can help by maintaining secure baselines and alert authorities to unauthorized changes. These practices enable you to create what is known as the trusted base.

The trusted base is the secure and verifiable runtime environment built using these security-focused best practices that ensure that you know exactly what CIs were built using the correct source code baseline in the build itself. There have been recent incidents where banks, exchanges and other financial institutions have suffered serious system glitches because of security issues including attacks by hackers. Knight Capital group reportedly suffered a $440 million loss due to the wrong version of networking software on its servers. These incidents highlight the need for robust configuration management best practices including DevOps that should start early in the development process. DevOps focuses on implementing automated application build, package and deployment for development, QA, integration, pre-production and production deployments. In all of these situations, testing is a must have.

Application testing is an essential best practice including smoke testing that should always be completed as the last step in an application deployment. Testing is fundamental and automated build procedures should include unit tests as part of the automated build stream. From a security perspective effective source code management and automated application build enables information security by facilitating the scanning of source code for security vulnerabilities using automated code analysis tools. You can also build variants of the code that enable specialized testing to detect potential security problems. DevOps helps to establish the core CM Best Practices including application build, package and deployment that are essential for establishing the trusted base.

DevOps implements information security best practices including source code baselining and automated build, package and deployment. Embedding immutable version IDs and effective use of cryptography are also essential and very effective at ensuring the trusted base. If you are using DevOps best practices effectively you will be able to drive your information security capabilities to new levels, provide secure and reliable services and most importantly, delight your customers!

.

Personality Matters- The DevOps Divide

+
-
0
Personality Matters- The DevOps Divide

Personality Matters- The DevOps Divide
By Leslie Sachs

IT organizations often face challenges that range from complex technology to even more complex personalities. When I work with consultants in our CM Best Practices Consulting practice, I often hear of the many types of problems that plague organizations. For example, build and release engineers often have to interface with software development, data security, project management and IT operations professionals. DevOps tries to address the dynamics between IT operations and highly skilled software and systems delivery teams. Recently, I had an opportunity to read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win [1] by Gene Kim, Kevin Behr and George Spafford and my first reaction was that many of the situations described in the pages of that novel were ones we frequently encountered. Organizations are often challenged by the divisions between development and operations, what I have termed the “DevOps Divide.” Read on if you would like to improve your skills in dealing with these challenging dynamics.

Organizations evolve within a complex ecosystem with many forces impacting all of the stakeholders. Some of these forces exist and are controlled from within the organization. However, external forces can also impact an organization in very significant ways, too. For example, pressure from competitors and other market forces may require that companies take on significant risk in order to just stay competitive and ahead of the competition. With complex new technology systems emerging every three to six months, many businesses are hard-pressed to handle rapid deployments. While automation is an absolute must, collaborative communication is also essential. The development team is a key stakeholder in the DevOps divide.

Development bears the brunt of ill-defined and rapidly changing requirements. But development also gets to learn the new technology and get up-to-speed ahead of anyone else on the team. For this reason, build engineers and IT Ops often need to depend upon the technical expertise of the development resources who, in turn, can sometimes feel like they are the only stakeholders who truly understand the technical details. In fact, these dynamics often create a sense of friction between development and other stakeholders such as IT operations. Improving communications can help solve these problems, but in practice, there is often a significant gap between the development and the operations team. While development forges ahead, operations ensures that the systems stay online and all services are reliable.

Much is made of the fact that operations has a very different agenda than development. Operations is responsible for providing reliable services and, consequently, can sometimes be averse to constant change. While development is always pressed to have the next release completed and deployed, operations focuses on minimizing risk and ensuring continuous and reliable IT services. These opposing forces are at the heart of the DevOps divide and you must address them if you want your team to be more effective. The data security group also often faces similar challenges.

The data security group needs to set policy, determine standards and establish best practices to ensure that the systems are reliable and protected from intrusion. However, the data security group can also find itself challenged to safeguard complex technology that changes rapidly and is not well-understood. Once again, communication is essential or else the security team may find itself without the necessary expertise to be effective. There are other important stakeholders in the complex ecosystem as well.

The QA and testing function needs to understand how the system works, including business requirements which are often less than perfectly defined. Project managers are often challenged to provide the governance required by senior management to answer the classic questions of “are we there yet?” While Project Managers can be highly skilled at planning, they often do not fully understand all of the tasks described in the project plan especially in terms of duration, complexity and risk. Let’s not forget the end users either, whether they be internal corporate users or external customers. The DevOps divide, while most obvious between development and operations, can be viewed as a paradigm for similar communication impasses between any of the stakeholders involved.

At the heart of any organization is a culture and family structure that may be highly effective, but also may be at times dysfunctional. We discuss many of these factors in my book on Configuration Management Best Practices [2]. You probably have worked in many organizations that handle communication well and you have probably worked in more than a few which are sorely challenged in this crucial area. DevOps brings a set of principles and best practices which helps the team improve both quality and productivity. The most essential of these practices is effective communication. Understanding the organizational dynamics as well as the personalities of each of the team members can help you comprehend and effectively manage the DevOps divide.

References
[1] Kim, Gene, Behr, Kevin, and Spafford, George. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, IT Revolution Press; January 10, 2013
[2] Aiello, Robert and Leslie Sachs. Configuration Management Best Practices: Practical Methods that Work in the Real World. Addison-Wesley, 2010

1...567...11Page 6 of 11