Welcome!

Search Authors: Shelly Palmer, Max Katz, Sandi Mappic, Jnan Dash, Alex Forbes

Related Topics: SOA & WOA

SOA & WOA: Article

Business Agility Depends on DevOps

Business agility depends on development and operations collaboration

True business agility is not about doing more application updates faster.  True business agility is about doing more application changes faster without sacrificing the application's performance or service quality.

From my perspective, achieving that second part of business agility means preventing application performance and service quality problems.  For the longest time IT operations have focused solely on remediating problems, which is not the same thing.  When someone's focus is on remediation, they quickly realize that it is easier to remediate problems when the environment does not change very often.  So no matter how much IT operations teams have streamlined their application problem resolution processes, there has still been an undercurrent of resistence to the constant change that is business agility.

Resistence is futile, and operations teams know this.  They recognize that they must also tackle problem prevention earlier in the application lifecycle.  The more experience one has in trying to manage the performance or service quality of constantly changing applications the more it becomes clear that the number of application performance problems depends on:

  • how well the application is engineered for the production environment,
  • how well application updates are managed; and
  • how well defect and problem knowledge are shared across development and operations.

Those issues are driving the growing interest development and operations collaboration (DevOps). Let us look at each to understand why.

1) How well the application is engineered for the production environment.
The final production deployment configuration often bears little resemblance to the application architect's original Visio diagrams.  Operations teams map the application service model, designed by software architects and developers, to the resource environments available from physical, virtual, or cloud infrastructure. This mapping activity has become an engineering effort as the complexity of the applications has grown.  This means there is often a big difference between software design and deployment configuration.  This difference often results in miscues that cause organizations to have as much as 50% their deployments rolled back.

Rollbacks can be caused by configuration had problems such as incorrect IP addresses.  That type of problem occurs when developers with no operations experience are managing this application engineering effort. Rollbacks can also be caused when the placement of the distributed components caused unexpected application performance and service quality problems.  That type of problem occurs when operations folks with little insight into the application design are managing the application configuration effort. The converse is also true, when development teams have little insight into how production deployments are configured, they can create application architectures that are not as scalable in production as in the test environment. Skills from both development and operations must be applied during the deployment configuration effort to prevent these problems.

2) How well application updates are managed.
Back when tiered web application deployments were new, I did research showed that when enterprises went from client/server to tiered web application architectures, application updates jumped from bi-annual to monthly events.   Now I'm beginning to track that the combination of SOA and agile programming means weekly (sometimes daily) application updates. It seems obvious to me that weekly application updates done with release management tools and processes designed for bi-annual updates will result in poorly performing applications.  The application service quality is even worse when those release management tools and processes used by infrastructure administrators with hardware and OS configurations expertise but little insight into application design and configuration.  If the goal is business agility without sacrificing application service quality then application development and operations teams need new collaborative means to manage how updates get done.

3) How well defect and problem knowledge flow across development and operations teams.
Defect knowledge from development teams is extremely useful because it allows operations teams to create infrastructure workarounds (such as throwing more hardware at the problem or staging server restarts).  These workarounds protect application service quality while buying the development team time to resolve the problem.

Problem knowledge from operations teams is useful because it allows agile developers to improve their application design for better performance as they work on the next round of user requirements. Therefore, it seems obvious to me that the more difficult communications is between development and operations, the more application problems there will be in production.  The chasm between development and operations groups has to be bridged with effective collaboration for application service quality to be maintain in the face of constant change.  Effective collaboration  is not about more meetings, reports, email trails and CYA activities.  It is about enabling the different groups to share the right information with the right people at the right time.

So there's my take on three key issues that determine how agile a business can actually become. From my perspective, fostering application collaboration between development and operations should be a cornerstone capability of those solutions if they are to deliver true business agility. I'm interested in hearing your perspectives.

More Stories By Jasmine Noel

Jasmine Noel is a founding partner of Ptak, Noel & Associates. She has over 15 years experience analyzing and consulting on IT management issues. She currently focuses on technologies and processes that organizations require to design, engineer and manage the performance and service quality of business applications, workloads and services. Noel served previously as director of systems and applications management at Hurwitz Group, where she formulated and managed the company’s research agenda. She was also a senior analyst at D.H. Brown Associates, where her responsibilities included technology trend analysis in the network and systems management space. Noel is regularly quoted in and contributed articles to several leading publications and content portals on various IT management topics. She holds a bachelor of science from the Massachusetts Institute of Technology and a master of science from the University of Southern California.