devopsy.kinsta.cloud

Tag: software development

Tasktop Survey Shows Customer, Business Needs Must Align
Recently, Tasktop surveyed 120 global IT professionals on their software delivery processes. The results were based on analysis obtained from its licensed Forrester Modern Application Assessment Tool, which helps organizations evaluate where they fall on the spectrum of modern software delivery and offers insight into what needs to happen next.

The survey covered topics such as customer needs, application development and delivery objectives and strategies, business value, metrics, tools and more.

Key Findings

In spite of the increasing adoption of agile and DevOps initiatives, the survey identified the need for stronger alignment with customer and business needs and tools that increase coordination in the software delivery process.

Developers, tech leads, project managers, chief technology officers and other IT titles surveyed reported the following:
- Only 6 percent strongly agreed they could trace the contents of a software release back to business needs or customer satisfaction.
- Just 9 percent strongly agreed their application development and delivery strategies were aligned with business strategies.
- And, strikingly, a scant 15 percent strongly agreed their work management tools assist in coordinating the work of the software delivery team satisfaction.
It seems that in spite of a strong industry drive toward being more responsive to the the needs of the business, there remain large gaps in how organizations realize the benefits of the tools they use to support these initiatives.

Any parties interested in taking the survey and receiving an assessment can do so here.

About the Author / Betty Zakheim ‎

Betty Zakheim is vice president of Industry Strategy at Tasktop and is the vertex between Tasktop’s customers, the company’s product team and marketing team. She has an extensive background in software development, software integration technologies and software development tools. As a software development manager, she was an early adaptor of “iterative development,” the precursor to Agile. As the VP of product management and marketing at InConcert (acquired by TIBCO), she pioneered the use of Business Process Management (then called “workflow) as the semantic framework for enterprise application integration. Connect with her on LinkedIn and Twitter.
September 14, 2016
Follow the Simple Path of Nirvana to DevOps

Perhaps the title of this post is a misleading, as nothing is truly “simple. But there is a well-defined pathway to achieving DevOps goals for any size company. Just follow a step-up pattern by adopting the principles of agile, continuous integration and continuous delivery, and you will reach your goal of DevOps. This path is a natural progression of DevOps maturity that an organization can follow while adopting key principles and technology solutions along the way.

Agile Development

Adopting agile development methodologies often is the first step maturing organizations take, as they no doubt have heard the resounding benefits of leaving behind waterfall software development life cycles. There is a reason this is the first step. It helps your organization’s employees mature into a tightly knit working machine that fosters improvements in driving down technical debt while also laser-focused on building key features.

As agile teams continue their maturation, they’ve roped in key business stakeholders who are able to grasp the drivers of technology challenges and are able balance out the growth needs of the business with the sustainability requirements of the technology teams. Suddenly, teams are investing a minimum of 20 percent of their sprint time to dealing with technical debt and reporting out these victories to their product owner(s). These small wins become major victories as the unwieldy pieces of infrastructure and software of the business become relics and folklore of yesteryear.

But there is an underlying reason why agile development is the most crucial first step: It truly empowers the developers to improve the customer experience and feel good about it. With the scrum master’s shields up protecting the team from burnout and ensuring sprint planning happens, team members are more likely to be passionate about their work and the results of their efforts to the business and customer. This is where the empowerment of DevOps really begins.

Continuous Integration

As teams mature along the agile development continuum, the next step in their DevOps maturation is moving on to continuous integration. Continuous integration is the process by which a company automates its software build process: code check-in triggers a build job that then triggers a test validation job and so-on. This process enables teams to continuously integrate their code build with downstream processes, avoiding manual touchpoints.

In addition, this paradigm allows for faster feedback loops to ensure a higher quality product, and empowers diverse teams to work together utilizing automation as the “middle man.”

Continuous Delivery

The third step in DevOps maturation is continuous delivery. Often businesses confuse “delivery” with “deployment”—in fact, continuous delivery is simply the process to ensure that at any given point a company’s software is in a state where it can be deployed. This is useful for quick iterations, A/B testing and a more mature way of delighting customers fast and often.

A key component of continuous delivery is ensuring that software is ready for production. When a team is doing continuous delivery, they’re assured that they’re nimble and responsive and adhere to the highest quality standards.

DevOps

At this point, the company has reached the DevOps nirvana state. This is where software is not just delivered continuously, but all of the operational needs are constantly met. Monitoring, metrics, the ability to automatically roll back software releases, scalability and much more are the key building blocks to a powerful DevOps organization.

With this thoughtful step-by-step process of DevOps adoption, organizations can meet the needs of business in a mindful and cohesive way without compromise.

I’d love to hear any feedback or tips on DevOps at @jsin.

About the Author/Jason Shawn

Jason Shawn is a technology leader in DevOps and Cloud. His began his career as a software developer and has held multiple functional and managerial roles which has found him with a unique perspective on the software development lifecycle. He’s extremely passionate about Continuous Delivery, Agile software development, and empowering teams to adopt DevOps and Agile principles in their daily lives. He is also a member of the Cloudbees Customer Advisory Board and enjoys public speaking, travel, and time with his family.

July 13, 2016
Does Security Slow Down DevOps?
Since the primary goal of DevOps is to eliminate bottlenecks to increase a company’s speed and efficiency, organizations tend to embrace new strategies that make DevOps even more efficient. However, when it comes to integrating security into DevOps, there is some debate whether such integrations help to improve the success rate of the DevOps process.

The Security Dilemma

Some arguments against integrating security into DevOps include:
- Security and DevOps function better separately,
- There is no need for security in DevOps, or
- Security will somehow slow down the creativity driven by DevOps.
Some say security integrated with DevOps stifles the work flow and innovation due to its restrictions. In other words, security can viewed as getting in the way of development, or being overbearing to the process, because it is not geared toward rapid development, but rather toward safety.

Another Perspective

Despite the arguments against integrating security with DevOps, security breaches because of neglecting safety during development can be a nightmare. For example, software or a website attacked via an overlooked vulnerability point, or a major bug to the code, costs the company in terms of time, money and competitive edge.

Not only can it crash the product, but it also can halt sales or seriously damage the reputation of the product or site. If security is not integrated with the fast-paced DevOps team, security problems often are not solved or even detected until well after the product is released. This can make it very difficult for the security team to limit the negative effects of any security problem.

The Benefits of Integration

Security integrated with DevOps creates an opportunity for the security team to fix and identify problems or vulnerabilities before the product is launched—and before the stakes are suddenly much higher and much more costly.

Integrating security into DevOps allows the security team to protect the code and the products from within, while they are being created.

It can be compared to safety inspectors being part of a team that builds a railroad: Wouldn’t it be easier for them to identify any problems with the railroad while it is being built, rather than trying to fix them after a train crashes?

Security from the Beginning

It is true that DevOps and agile development involve being very adaptable to change and making rapid prototypes and new products that account for errors, flaws or even security risks. However, just because a DevOps team can move fast doesn’t mean the business won’t be more profitable if it can prevent security risks in the first place.

Developers don’t possess the same knowledge and skills security professionals have. For that reason security professionals should be included in the development process to increase the chance of releasing a stronger and more effective product.

The database specifically is an area that can spell disaster. Security and regulatory compliance should be a central component of DevOps for database to prevent unauthorized and undocumented changes to the database and a potentially disastrous security breach.

It’s important to protect a developer’s creativity and workflow, but most companies have room to integrate more security into their DevOps team. Doing so might just save them from huge problems down the line.

Next Steps

Here are a few key steps to enable secure DevOps:
1. Configure the dev, test and deployment environments identically.
2. Make proactive changes to all environments automatically, significantly reducing the opportunity for engineers to make security mistakes.
3. Create a secure process and determine roles and responsibilities as early as possible in development stage.
4. Perform all vital secure connectivity reviews during the development process.
5. Implement separation of duties across your entire release process.
6. Fully automate your deployments to reduce the need for manual access and attended processes.
7. Ensure your database does not become a compliance and security risk.
About the Author/Yaniv Yehuda

Yaniv Yehuda is the co-founder and CTO of DBmaestro, an enterprise software development company focusing on database development and deployment technologies. Yaniv is also the co-founder and the head of development for Extreme Technology, an IT service provider for the Israeli market. Yaniv was a captain in Mamram, the Israel Defense Forces computer centers, where he served as a software engineering manager.
June 30, 2016
Q&A: Full City Tech’s Higbee on Culture, Part 2

In part one of this two-part Q&A we dug into Wes Higbee’s position on instilling a DevOps culture. Higbee, a developer and business consultant, continues his separation of wheat from chaff in the field of DevOps dreams.

devopsy.kinsta.cloud: How is automation, which is a focal point for DevOps, also a trap?

Higbee: Focusing on the automation can become problematic if you forget about other things. Something like automation will distract you and you’ll end up having great turnaround times on new features that don’t mean anything to your customers.

devopsy.kinsta.cloud: Doesn’t failing fast fix that?

Higbee: Failing fast could help, assuming you have metrics in place that tell you that you’re failing in a way that matters.

devopsy.kinsta.cloud: Could you please illustrate an example of isolated devs and ops that serve the given purpose better than combining them would?

Higbee: I have a history of doing projects in the software development space where we had tight collaboration with everybody that’s involved in the process. Users, stakeholders, developers, testers, managers … you name whatever role, people worked closely together. I also have a history of examples where there was no collaboration at all.

A lot of smaller projects end up in this latter bucket where you really just need one person to create a software system for a very specific purpose. They create the system, they deploy it, and then it just has to be supported at that point because it’s not going to be changed thereafter. It serves its purpose. People are happy with it. It’s probably never going to be changed ever again, so the separation there between dev and ops is perfectly acceptable and if you tried to bring together a whole team of people and synchronize them, it would just be a waste of time because the effort isn’t big enough to justify it.

Another example would be pretty much any company that has ops staff but doesn’t do their own development. They outsource their development. Sure, there are situations where a project would necessitate everybody working closely together, but I’m sure there are a lot development efforts that happen in this regard where the dev team is outside the organization so there’s going to be functional separation. They developed software, it’s deployed, and maybe it’s never changed again, so there’s really no need for some tight-knit collaboration.

devopsy.kinsta.cloud: How do recommend helping organizations produce rapid results such that they can rapidly move to a DevOps approach successfully?

Higbee: First and foremost, I don’t extol any methodology, so I’m not a DevOps consultant. I’m not an agile coach. I think it’s ludicrous when people put these fads in front of their titles. The thing that I do that makes the difference, that produces rapid results is to make sure that we have a common goal, make sure it’s crystal clear and make sure everybody understands it. It’s like hiking to the top of a mountain. Everybody knows how far along we are. They can measure their own progress. They can flag things if we’re headed in the wrong direction like down the mountain. They can always see the goal. It’s always in sight.

In another example, if you’ve ever gone to an Escape the Room Adventure, everybody is dumped into a room. It’s a group of people who oftentimes are strangers. About 10 people get dumped into a room and the goal in the duration of an hour is to get out of the room. The challenge is set up so it would be pretty difficult to get out in that hour, so if people don’t focus on that goal, then people aren’t getting out of the room.

I’m not interested in how fast we solve each of the individual puzzles, so we don’t measure those things. We just get to work on getting out of the room. That’s my approach to doing business with people and that’s how people get rapid results. Because if you have a crystal clear goal, then you can go to the last hundred years of management philosophy to find the ways you need to get to your final destination. You aren’t worried about the right way of doing things; you’re just worried about the way that works for your specific situation.

June 27, 2016
Q&A: Full City Tech’s Higbee on Culture, Part 1

Every day, more people are hopping on the DevOps magic bus, drinking the spiked punch and singing “Kumbaya.” I imagined everyone I interviewed would offer tales of instilling this undefeatable, undeniable, brand-spanking-new rapid development culture.

It was refreshing to discover that I was mistaken. Apparently, DevOps is just another methodology for accelerating business success—one for software development.

In part one of our latest Q&A, we chat with Wes Higbee, software developer, business consultant and president of Full City Tech Co. Higbee ably defends his stance on how special DevOps and instilling a DevOps culture is or isn’t in the grand scheme of things.

devopsy.kinsta.cloud: So you say that DevOps is nothing new; that you have books collecting dust from the mid- to late-20th century describing similar organizational and management philosophies. What are some examples from those books you have collecting dust?

Higbee: DevOps is the latest reincarnation of a lot of management philosophies that have been around for a long time. There are a couple of examples to reference. Alan Weiss, author of the book, “Best Laid Plans: Turning Strategy Into Action Throughout Your Organization,” wrote about functional organization at an insurance company that employed him. They had a functional department of typists and a functional department of people that would check the typist’s work.

Underwriters sent requests to the typists to type up contracts. Typists would type up those contracts and then someone collected those for a separate group of checkers. The checkers would then check them and there was a lot of back and forth correcting errors. This led to a lot of inefficiencies.

The solution was to take the checkers and pair them up with teams of typists. So a checker could review the work of several typists. That group of people worked together, and it turned out to be much more efficient, productive and effective.

This is the heart of a cross-functional team, which is a fancy word for teamwork. This is one of the many ideas in the DevOps space, specifically taking developers and ops and putting these two groups of people together instead of having them as completely separate functional units inside the organization.

Another reference is to pretty much everything Peter Drucker wrote. Specifically with regards to the people who are talking about focusing on the big picture. This is one thing that some people in the DevOps space are getting right. They’re talking about the big picture and not making optimizations to small parts of the picture that then jeopardized the whole, so optimize the whole. This comes from the work of Peter Drucker, “Managing for Results: Economic Tasks and Risk-Taking Decisions.”

devopsy.kinsta.cloud: You say the danger is in the term DevOps itself; that as with agile, people slap a new name on what they’re already doing and think everything is better. If it’s not the terminology that needs to change to ensure a DevOps cultural transformation, then what is it?

Higbee: I can’t tell you how many times I’ve encountered DevOps where devs and ops were still siloed. If you want to be successful—and this applies to any methodology—you have to start with real problems and real opportunities, because somebody else’s best practice is your own worst practice. If your customers are happy and your company is successful, you are seeing great profit margins and great growth, why would you change anything?

Automated tests are something that people extol a lot in the DevOps space. You should have automation of your entire test suite and it should be part of your release process that’s also automated. But if you have no bugs in production, there’s no reason to go adding a bunch of tests to your release process.

However, if your users routinely experience bugs in their production environment, then it would make sense to start talking about some testing and maybe even some automated testing during your release process. But don’t start with blindly writing tests of everything in the system. Start with the specific parts that are buggy, and you might be surprised how fast you can get those parts covered with some good tests. And then once you’ve done that, stop there.

June 23, 2016
Redefining Product Value in the Continuous Economy

The internet is now more than 20 years old. It’s older than my kids, which is a scary thought. It’s older than Kendall Jenner. It’s older than Uber, Grey’s Anatomy and the iPhone. And so now, after more than two decades of software and e-commerce, it’s high time we take stock of where consumers really are today.

First, consumer expectations are shifting dramatically. The digital world has brought a whole host of changes in how people work, shop, interact and engage with businesses.

Second, the notion of brand loyalty has dissolved, shattered beyond recognition.

And, third, this utter lack and loss of loyalty puts companies at an insane disadvantage. We’re living with a “see you later” digital mindset, where it’s easy to say goodbye to something you know online for an opportunity with the newest, next-best thing.

All of this means that companies must deliver a constant stream of software that is fluid, flexible and competitive to gain and retain customers.

It also means that companies absolutely must understand how consumers weigh and determine product value today, because, quite clearly, buyers aren’t making product choices in the same ways anymore.

Indeed, 20 years ago, customers chose products based on product features. Today’s modern consumers are continuously looking for new products, embracing them and then discarding them for something even more new. In fact, the willingness to switch is so strong, according to Harris Interactive, that 86 percent of consumers quit doing business with a company because of a single bad experience. And 90 percent say they would be willing to pay more for the same product if they received a more positive purchasing experience.

This continuous process of discovery, adoption, discarding, discovery, adoption, discarding, discovery, adoption and discarding tells us—very loudly and unequivocally—that value isn’t in the actual product itself, but in our ability to continuously evolve the product.

Shifting Consumer Expectations Require a Continuous Approach to Business

If you can’t continuously transform the way you deploy your product, people and processes, there’s no way you can keep up with customers’ “see you later” mindset and their continuous discovering, adopting and discarding of products.

Two decades ago, for example, you chose a car based on ideal product characteristics (make, size, etc.) and how much you could afford to spend. Your choice would live with you while you paid it off or until you could justify changing it.

Now, software and the speed of innovation have allowed consumers the opportunity to make product choices at a greater frequency. Instead of only getting the newest features when you buy a new car every 10 years, car operating systems are updated wirelessly and provide the latest and greatest features to existing owners, without the need to buy a brand new vehicle. The car has become a software platform.

Even the physical choice of platform (the car itself) is beginning to change. For those who wish to change their car regularly, there are many services (such as Zip Car) that allow you to rent access to a car and return it when you’re done. Or even not to drive at all, with the advent of software companies such as Uber and Lyft.

Obviously, each product—software or otherwise—must have a set of threshold features, or else consumers won’t choose it. A car, for example, needs to be waterproof with airbags and ABS brakes. And a task app needs to allow you to add appointments and meetings to your calendar. But to be competitive today, products must now also include the ability to switch away from features and add new ones seamlessly.

Value is Driven by Option

This “optionality” drives product value in what has become the ‘continuous economy’ of 2016. Companies can deliver “optionality” only by eliminating barriers from their production processes.

Companies need to adopt product development processes that are lean and high velocity to provide customers with an ongoing series of new product features and choices. That’s why you need to continuously deliver and continuously change your software.

Keeping Pace with the Acceleration of the Continuous Economy

If you can’t—or won’t—continuously transform innovative software products and the way you produce them, you won’t be able to compete in today’s quicksilver-fast marketplace.

Or, to put it more broadly, software, as well as the organization and its people and processes, must be able to pivot with agility in what seems like a nanosecond to keep pace with the acceleration of the continuous economy.

This is all very different than what we’ve experienced in the past.

Two decades ago, an organization confronted a new competitor or change in the market, by developing and deploying new operations, organization adaptations or products to meet the challenge.

Today, software is the primary route to market, so companies must continuously develop and deploy new software as part of an always-transforming organizational culture. If you’re unable to develop and deploy on a sustained basis in today’s continuous economy—if you only transform on a selective basis—you won’t be in business very long.

June 15, 2016
DevOps is a Risky Business
I spend a considerable amount of time with clients discussing DevOps and the potential value it can bring to them, but there is one theme that always resonates: the ability of a DevOps approach to eliminate risk. While many of us understand the benefits in terms of being faster (improved productivity), cheaper (reduced cost) and better (improved quality), I find that a conversation based around risk, especially when talking to the business or department heads, usually gets straight to their concerns in a language they understand.

IBM’s definition of DevOps is not simply about connecting development and operations; it is fundamentally about providing a capability that: 1) allows lines of business to connect with their customers (which may be internal employees) quickly, and 2) facilitates rapid feedback from their customers so relevant adjustments can be made. DevOps, therefore, embraces the philosophy of iterative (and incremental) development and delivery, whereby solutions are delivered through a series of incremental releases.

By ensuring all aspects of a solution (requirements, designs, code, executables, tests, etc.) evolve over time as each increment is completed, DevOps is fundamentally focused on addressing risks including:
- The risk of not knowing the requirements (have you ever tried to write down and freeze the requirements for a mobile app?)
- The risk of not knowing the solution (especially when it’s new, you’re defining a new architecture or you’re embracing new technologies)
- The risk of not knowing the effort (especially when the solution is novel for the organization)
- The risk of not delivering on time (when the pace of the team, for example, is an unknown)
- The risk of not providing the right level of quality (and the impact this may have on customer sentiment)
- The risk of adopting inappropriate practices (meaning that the approach being taken by the team is not working for them)
- The risk of having an ineffective delivery environment (including automation through the use of delivery tools)
I could go on. There are so many risks that can be addressed simply by delivering working software iteratively, that it’s surprising how many organizations continue to fall back to a “waterfall” mentality—even in high-risk environments where much is unknown.

The tack I’ve taken here originates from my time at Rational Software Corp. (which IBM acquired in 2003), where we would emphasize the need to deliver software iteratively and progress was measured based on the results achieved (i.e., working software) rather that the documents produced. My favorite graphic from that time is the one shown below, which shows how a modern approach changes the risk profile associated with a delivery project, since it focuses on removing risk as early as possible in the life cycle.

In summary, incremental and continuous delivery evident in a DevOps approach allows us to call out risk early and determine its resolution. DevOps often is used along with “lean startup” thinking (and its build-measure-learn cycle) and monikers such as “fail fast” since these are, at their heart, also focused on addressing risk.

Take the DevOps self-assessment to find out where are you on your DevOps journey

About the Author / Peter Eeles

Peter Eeles is an Executive IT Architect in the DevOps Global Tiger Team, IBM Hybrid Cloud, where he helps organizations improve their IT delivery capability in order to drive tangible business value. He has a particular interest in the adoption of architecture, agile, DevOps and cloud as innovation enablers. In the IT industry since 1985, Peter comes from a delivery background and was previously chief architect of IBM Rational’s Worldwide Solution Delivery organization, where he led many large-scale transformations in a variety of industries. Peter has written many papers and several books, including “The Process of Software Architecting” (2009), “Building J2EE Applications with the Rational Unified Process” (2002), and “Building Business Objects” (1998). He runs his own website at www.architecting.co.uk.

Connect with Peter on LinkedIn and Twitter.
May 19, 2016
The Cost of Not Building with Security in Mind
The unfortunate reality for today’s organizations is the fact that a security breach is bound to happen. Major breaches are happening with alarming frequency and fill the news headlines almost daily. And behind many of these major breach stories is a software vulnerability that has been exploited. There is a silver lining, however. Addressing security at the development stage can help organizations “get upstream” of certain issues, which goes a long way toward alleviating potential breaches.

Now there are always two sides to every coin, and this is where companies need to weigh the costs of not taking a proactive approach to making security a key part of their software development process. Is the upfront time and effort worth it when it comes to developing software and ensuring bugs and vulnerabilities are addressed before it is put into the wild? The simple answer is, yes! We are already seeing this in certain industries such as financial services, which learned the hard way that it is a critical component of software development—mitigating risks and significantly lowering the financial burden associated with a major breach.

In fact, security should have been more central to software development a long time ago. As software, and more broadly technology, continues to evolve and permeate our lives from more angles, it is crucial that security be a consideration—a “use case” as developers call it—from the earliest conceptual stages of a project. The costs of not doing so are simply too painful to imagine otherwise.

Shifting to Security-First

To build more secure software, organizations typically must implement a software security initiative. You can break it down into four steps:
- Assess your current software assurance posture
- Define the strategy your organization should take to ensure a viable posture
- Formulate a road map of how to achieve that posture
- Implement your strategy
The above steps are simple and when you think of the alternative to not doing this, adding security as a pivotal part of the software development process seems like a no-brainer. To better understand what I mean, you need only look at the cost the average breach has on an organization. According to the 10th annual “Cost of Data Breach Study” independently conducted by Ponemon Institute, the average consolidated total cost of a data breach in 2015 was $3.8 million, an increase of 23 percent from 2013. The study also reported that the cost incurred for each lost or stolen record containing sensitive and confidential information increased 6 percent, to a consolidated average of $154 from $145. Depending on how much data has been compromised, the financial fallout can be staggering, if not crippling, to an organization.

Conversely, the cost to repair a single vulnerability in an application during the design phase is less than $500, according to the IEEE Computer Society. The fact that the financial impact of not addressing security during the development process can quickly become cost prohibitive, is a clear indication that secure software development practices can no longer be overlooked. Breaches are now a boardroom issue and require a seat at the development table.

As we can see from the stats above, the economic fallout for organizations is obvious, but with the Internet of Things coming to a house near you, this issue is suddenly becoming more personal and painful for the average person. Whether an attacker takes over your thermostat from Russia or finds a way to monitor your home via your baby camera, vulnerabilities are making it easier for malicious actors to corrupt corporate, government and now individual networks like never before.

We are well beyond the “it will never happen to me” phase. Breach stories that used to happen to so called “other” people are more likely to happen to you if software defects continue to be ignored and are not fixed when they should be. No matter how you crunch the numbers, if security isn’t addressed at the software development level, the result will always end in a costly lesson learned.

About the Author/John Dickson

John B. Dickson is an internationally recognized security leader, entrepreneur and Principal at Denim Group, Ltd. He has nearly 20 years hands-on experience in intrusion detection, network security and application security in the commercial, public and military sectors.

Dickson is a popular speaker on security at industry venues including the RSA Security Conference, the SANS Institute, the Open Web Application Security Project (OWASP) and at other international conferences. He is a sought-after expert and regularly contributes to Dark Reading and other publications. A Distinguished Fellow of the International Systems Security Association, he has been a Certified Information Systems Security Professional (CISSP) since 1998.

As a Denim Group Principal, he helps executives and Chief Security Officers (CSOs) of Fortune 500 companies and government organizations launch and expand their critical application security initiatives.

Twitter: http://twitter.com/johnbdickson
Linkedin: https://www.linkedin.com/in/john-b-dickson-cissp-41a149
April 14, 2016
Git: One Giant Leap Toward DevOps
If you work in an organization that has not yet embraced DevOps, then you might be wondering where to begin. Fortunately, there are many good answers. But I want to introduce one simple starting point that you probably haven’t heard: introducing Git to operations. By itself, Git might not seem like a meaningful way to overcome the barriers between dev and ops. Yet, Git provides some capabilities that mark the difference between the lowest performing IT organizations and the highest. And the difference in IT performance can translate into substantial business benefits. The highest performing IT organizations have noticed the following benefits:
- They are about twice as likely to exceed profitability, market share and productivity goals.
- Their employees reported far higher levels of job satisfaction.
- They realize 50 percent higher market capitalization growth over a three-year period.
To be clear, no amount of data will ever prove that use of Git leads directly to growth, profit, productivity and job satisfaction. What the Puppet Labs’ “State of DevOps Survey” does show is the incredible range between low and high performance in IT organizations. The rate of deployment has hovered at 30 times faster for high-performing organizations over the lowest. The 2014 survey showed 50 percent fewer deployment failures, while 2015 showed 60 percent fewer deployment failures, when comparing highest to lowest. The survey also indicates which practices separate the highest performers from the lowest. According to the State of DevOps Survey, the top two indicators of high performance are:
- Version control of all production artifacts (surprisingly, a far greater predictor of performance than version control of source code); and
- Peer review of production changes (in contrast to external change approval).
It’s not that these two practices magically yield business benefits. Indeed, ITIL has long recognized management of production artifacts and review of production changes as best practices. But too many organizations still believe faster deployment and higher reliability are trade-offs. What is “magical” in high-performing organizations is they realize they can have both faster deployment and higher reliability by collaborating across organizational boundaries and automating intelligently. That means dev and ops sharing goals, measurements and tools. So one way in which these practices differ from typical ITIL practices is how dev and ops perform them collaboratively. More specifically, when dev and ops use the same tool for version control, they can better share techniques and workflows. For example, the peer review of changes can include both dev and ops. Thus, Git is a gateway to DevOps.

Git has long provided those two capabilities for software developers: Developers use Git to version source code and developers use pull requests to perform peer review of source code. With a few tips about how to apply Git to configuration files, operations can use pull requests to perform peer review of configuration changes. Now with git-lfs, operations can also version production artifacts, which often are large, binary files that historically have not worked well with Git. More advanced concepts such as infrastructure as code and dedicated binary repositories, for example, build on version control, so even if the role of Git changes over time, the skills and collaborations remain valuable.

In summary, the business case of Git for Ops is simple. The Puppet Labs survey shows meaningful upside for low performing IT organizations to become high performing. The survey shows high performing organizations are characterized by both rapid deployment and high reliability, not picking one over the other. Two practices that characterize high performing IT organizations are version control of production artifacts and peer review of changes. Git is now well-positioned to provide both capabilities. If you’re ready to start introducing operations to Git, don’t forget that Bitbucket has no limits to the number of private repositories.

About the Author/Ian Buchanan

While Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of agile methods in large enterprises. He is currently the Developer Partisan for Developer Tools at Atlassian, where he focuses on the emerging DevOps culture and the application of Bitbucket and Bamboo for better continuous integration and continuous delivery. During his career, he has successfully managed enterprise software development tools in all phases of their life cycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality and improved customer satisfaction. He has built multinational agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming and domain-specific languages.
March 16, 2016
Developers Cite Startling Lack of Digital Leadership

Despite app backlogs, developers say their efforts are underfunded and undertrained, and lack a priority for security

We’ve long written about the challenges enterprises face when developing the apps they need, digging out of app backlogs and technical debt, and the overall importance of running a productive development pipeline. And, how to keep up, enterprise’s are seeing more and more citizen developers rising to fill in try to close the lag between what software apps they need built.

Which is why it was disheartening to read in a recently published report, “Investment in Enterprise Developers is the Best Risk Management System,” based on a survey of more than 100 developers by the Application Developers Alliance, that 40 percent of respondents have experienced failed development efforts from lack of funding, and a third are concerned that current projects could be pulled for budgetary reasons. Also, despite survey after survey of executives citing security as a “top priority,” only 45 percent of enterprise developers surveyed believe that their organization sets a “high” priority for security.

Not surprisingly, according to the survey, four out of five enterprise developers surveyed work on Windows and/or OS X, and 24 percent work on Linux. Yet only 20 percent work on mobile platforms exclusively. And, interestingly, two-thirds of enterprise developers develop their apps exclusively HTML5, hybrid or native, with native being the most common. And, not surprisingly today, cloud is the most common way to deploy apps during development, test or production.

Unfortunately, many developers report underfunding in technology, processes and training. A third report outdated technology and processes in their organizations—more than half (51 percent) of those in organizations with more than 100 employees.

Leadership Falling Short in Many Areas

When it comes to cultivating processes and technology guidance, many enterprises also fall short. Only 37 percent of those surveyed said their organization has a Center of Excellence. Not surprisingly, the larger enterprises were more likely to have a Center of Excellence; however the lack of such centers is more common in North America and Europe, Middle East and Africa. Most every organization surveyed in Asia, however, has a dedicated Center of Excellence. Additionally, a surprisingly low 29 percent of of developers surveyed reported that they are required to attend training, certification programs or other continuing education.

That’s stunning, considering that increasingly businesses are driven by their digital efforts. There’s no shortage of surveys citing this. In a recent study commissioned by CA Technologies, “The Battle for Competitive Advantage in the App Economy,” 43 percent of survey respondents said that becoming software-driven is central to being competitive today, and nearly 80 percent said that would be true in three years. Broadly, to be competitive in the years ahead, enterprises are going to have to be exceptional software companies in addition to their core current products and services. Yet survey after survey finds that enterprises are falling behind in their app development goals and are having a challenging time finding the talent they need.

Additionally, the Application Developers Alliance survey found that only 50 percent of enterprises discuss the capabilities and skills they need to succeed, while only 26 percent integrate such competencies in their evaluation process. And, just as when it came to establishing Centers of Excellence, Asian companies stood out, with 78 percent of Asian developers saying necessary skill development is discussed.

Centers of Excellence, the Application Developers Alliance survey found, also are excellent indicators of whether an enterprise is committed to building secure software. While 64 percent of developers believe they’re “adequately” trained to build secure software, more than 70 percent at organizations with a Center of Excellence contend that security is a high priority where they work. If they work in an organization without a Center of Excellence, that number drops to 28 percent, and 17 percent rank security as a low priority in such enterprises.

Clearly, if enterprises expect to compete globally in the years ahead they’re going to need to step up their priorities when it comes to budgeting app development, cultivating the skills they need and building the internal organization necessary to succeed as a digital enterprise.

March 16, 2016