devopsy.kinsta.cloud

Author: contributor

Trick Question: What is DevOps?

DevOps suffers from the lack of a clearly defined definition. A Google search displays results that state that DevOps is empathy, culture or a movement. There are also derivations of DevOps, such as ChatOps and HugOps.

A lot of speakers mention DEVOPS but no-one seemed to have a widely agreed definition of what DEVOPS actually means.

— Stephen Booth (@stephenbooth_uk) November 19, 2015

Proposed Definition of DevOps: “Getting more done with fewer meetings.”

— DevOps Research (@devopsresearch) October 12, 2015

The real head-scratchers are the number of job postings for DevOps engineers and the number of certifications for DevOps popping up all over the web. The job title “software engineer” is contentious within the technology community, so the job title “DevOps engineer” is just begging to take pointless debates to a new level.

How, then, do you create a curriculum and certification course that has any significant value on an unclear subject?

For a methodology that has an emphasis on people, empathy and communications, it falls woefully short of heeding its own advice and values. On any given day, you can see the meaning debated on blog posts and tweets.

My Understanding of DevOps and Why it Exists

DevOps is an extension of the agile methodology that is hyperfocused on bringing customers extraordinary value without compromising creativity (development) or stability (operations). DevOps is from the two merged worlds of development and operations—operations in this context include all aspects of IT such as system administration, maintenance, etc.

Creation and stability are naturally at odds with each other. The ripple effect is a good way to explain how these two concepts have friction. Stability wants to keep the pond from becoming turbulent and causing harm. Creation leads to change, which can act as a random rock thrown into the water and sending ripples throughout the whole pond, leading to undesired side effects that cause harm to the whole ecosystem.

DevOps seeks to leverage the momentum of controlled ripples to bring about effective change without causing enough turbulence to impact the whole pond negatively.

The natural friction between these two needs often drives a wedge between development and operations. Operations worry that a product update may include broken functionality that customers have come to depend on, and developers worry that sorely needed new features may not make it to customers because of an operation’s resistance to change.

Instead of taking polarizing positions, DevOps is focused on blending those two positions into a force that effectively provides value to the customer without compromising the creativity and stability that a product or service needs to compete in an ever-evolving world.

Why is a Clear, Singular Meaning Needed?

The understanding of a meaning is an important part of sending a message.

If an unclear word is used to send a message, the word risks becoming noise and the message risks becoming uninterpreted or misinterpreted.

Without a clear, singular meaning, you risk losing the message that you want people to hear. In technology, I see messages get drowned in noise all the time.

In communications theory, noise is anything that interferes with understanding. Noise is more than just the sounds of static, loud music or machinery. Creating noise can be simple as using obscure words to explain a topic or providing an unclear definition that muddles the comprehension of a given subject.

DevOps suffers from too much noise that increases people’s uncertainty of the word. After reading a few posts on DevOps, each one with its declaration of the essence of DevOps, people can get confused by what the word means. DevOps is empathy! DevOps is culture! DevOps is a movement!

Because of noise, DevOps seems to stand for multiple ideas plus agile operations without setting any prioritization or definitive context. Okay, so which is it? Is it one of those or is it all of them? Which idea is the most important? Furthermore, these ideas can cause friction, as not everyone shares the same view on these topics. DevOps is supposed to reduce friction between naturally opposing groups within a business, not create more of it.

Remove the Barriers

Another aspect of noise is using words that are a barrier to understanding a given definition.

DevOps is the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support.

— the agile admin

People from a non-technical background or outside the world of agile and development may have a difficult time understanding a definition like that. When I read something like this, all is hear in my head is same sound the teacher in Peanuts makes: “Blah, blah blah, blah.”

If you want people to remember something, make it easy to understand and memorable.

Appeal to All Personality Styles

In marketing, you’re taught to write to appeal to four personality styles: driver, analytical, expressive and amiable. Getting people to work together in the workplace also requires appealing to these four personality types.

There is a need for a single definition of DevOps that appeals to the four personality styles—or, at the very least, refrains from being a barrier to entry. If a person needs to persuade someone who has a driver personality, but the definition includes language that invokes an automatic “no,” that puts people who want to use DevOps at a disadvantage.

Give people every advantage you can for them to adopt DevOps.

It’s Time for a Definition for DevOps

At a time when the DevOps role is becoming increasingly important for businesses, it is crucial that a globally recognized definition be created to reduce uncertainty. It’s hypocritical to introduce a word that touches upon the importance of communication and then expect people to take it seriously when the definition constantly changes.

It’s time that we have a singular definition for DevOps so people can use it for the hiring process or certifications without the risk of the message being lost or co-opted into something it is not.

About the Author/Michael Herndon

Michael is the head of DevOps at Solovis, creator of badmishka.co, and all around mischievous nerdy guy. He is writing on behalf of Packt Publishing.

March 15, 2016
Building a Business Case for DevOps
You can get your DevOps vehicle as fast and fine-tuned as you like, but until you provide an effective business case to the board it will remain in the garage. To get the thumbs up, you have to prove your model is efficient and makes financial sense for the company as a whole.

Do You Need to Make a Business Case for DevOps?

Coherent business cases are needed for companies at various different stages of their DevOps journey, not just those at the very beginning. Ask yourself which one of these scenarios best suits your current situation:
1. You/your CIO know(s) the company needs to become more agile, but you don’t know how to quantify the benefits.
2. Your teams have started to implement DevOps practices locally and can see the benefits, but you don’t know how to quantify the success to sell it to management.
3. Your organization sees the success of DevOps pilots, but need to justify the investment to bring DevOps to an enterprise scale.
DevOps can represent a huge shakeup of the IT department that must be justified clearly and logically. The risk must be outweighed by the projected financial gain. Crucially, this needs to be quantified in language that finance department can relate to. It is referred to as the hurdle rate: the necessary annual or total return of a project to compensate for the risk.

What Should the Business Case Contain?
1. Executive briefing
2. Recommendations
3. Required decisions
4. Business drivers
5. Scope
6. Assumptions
7. Analysis
8. NPV (Net Present Value)
9. Strategic options
Hallmarks of a Successful DevOps Business Case

Agility

This is the main benefit of DevOps: the ability to deliver applications faster and allow for frequent changes and adoptions all the way into production. But how do we measure and quantify the benefits of agility?

Time Value of Money

The time value of money expresses the fact that money today is worth more than money tomorrow. The more you have to invest early (instead of over time) and the longer it takes to receive the return, the lower the present value of your investment.

The number you receive when calculating the present value of an investment (benefits minus costs) is called NPV (Net Present Value). It tells you what your future investment is worth today.

With agile and DevOps you are able to develop an application and deliver it to your end user in small chunks rather than in big ones; thus, you will improve the NPV (Net Present Value) of your project even if the total amount of investment and output are the same.

Delivering software continuously rather than yearly creates benefits in the same way as receiving interest on your savings account every day rather than just once a year.

The precise time value of money depends on the average cost of capital a company has to bear. For example, a large, publicly traded company has a lower cost of capital than a small, privately owned one. Your finance department will know it.

Cost of Waste

A second aspect, which speaks for agility in a quantifiable manner, is the reduction of waste.

Functionality delivered using non-agile software engineering practices may be irrelevant or outdated once it reaches the end user because of the time gap and mismatches in requirements and expectations. The cost of such waste can be reduced drastically by using DevOps.

Calculate the benefit of waste reduction using available statistics on the average percentage of functionality used without changes in your applications. It may pay off to assess this number for the last two or three releases delivered.

Take into consideration:
1. Total cost of development and delivery of these releases.
2. Relative efforts of different functionalities delivered by release.
3. Cost of change requests that arrived during and after the release date.
4. End-user survey on the need and usability of these functionalities.
Combine the benefit of waste reduction and of frequent delivery and add them as positive future cash flows to your calculation.

You also need to calculate the forecasted costs of your DevOps initiative. Consider:
1. Investment in build, test, deploy and provisioning and related operating expenses.
2. Investment in IT infrastructure.
3. Investment to complement skills in development and operations teams.
4. Investment in organizational changes.
5. Operating expenses for all above.
6. Extra cost of non-automated activities in test, release and deploy due to increased release velocity.
As part of your strategic options in the business case, balance your investments in automation with investments in more resources for build, test and deploy for given agility scenarios. The higher the release velocity, the more build, test and deploy activities are required. The more automation, the less of these activities must be done manually. Visualize in diagrams how the investment in more automation starts to pay off with increasing release velocity.

Finally, sum up positive and negative cash flows and use your company’s hurdle rate to calculate your NPV.

About the Author/Michael Schmidt

Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.
March 11, 2016
Embracing DevOps in the IoT Era
To those of us struggling to cope with the challenges of delivering software over the Internet of Things (IoT), DevOps can be the savior.

Delivering software over the Internet is no easy task, and delivering it over the Internet of Things is even more formidable. How do you deliver software to so many “things,” many of which are “loners” unconnected to the rest of the world?

What’s encouraging is that the software management processes and tools that we know and have learned to love still work in the IoT era. In fact, not only do they work, they are essential.

We need teams to work together more smoothly and communicate more quickly to mitigate the higher technological risks. DevOps processes and tools, therefore, are critical in the IoT era because they facilitate smooth, well-oiled collaboration between teams.

A Typical IoT Scenario

Consider a scenario in which you need to develop a “smart” parking system for a “smart” city. The system will involve multiple sensors in the parking lots, a display device in each parking area along with communication equipment, a central server for control and analysis and a smart device in each car.

Drivers can check how many slots are available in nearby parking lots on their automobile devices and navigate to the appropriate parking lot. They also can book slots in advance and start paying from the time they book the slot. When they leave a slot, the parking slot sensor automatically detects that the slot is free and updates a central server. The central server transmits slot availability to the car-based devices, where they become visible to drivers. The central server also generates various kinds of reports and performs various kinds of high-end analysis.

As with any conventional Internet system, there are multiple software components. All of them have their respective delivery (development, testing and deployment) streams. These streams need to work interdependently and collaboratively, and they need centralized configuration management and dashboards.

The Scale and Diversity of IoT

The differences and challenge, however, lie in the sheer scale of deployment, the diversity of deployment environments and the multiple deployment channels. As you can imagine, any large city will have millions of cars, thousands of parking lots and, hence, hundreds of thousands of individual slots. The number of deployment devices easily can run into the millions.

In the interest of preventing monopolies, not all the parking sensors will be from one manufacturer. The same holds for the car-based devices. While certain standards can be enforced, not all manufacturers will adhere to one universal protocol. It will be necessary to allow multiple communication and security protocols on these devices. This multiplicity of protocols can complicate software deployment on the devices.

Other Considerations

What makes the entire deployment process even more complex is the fact that most of the deployment will be done over the air (OTA). Given that OTA deployment is susceptible to radio-frequency interference and other transmission issues, the deployment process must allow for more robustness than conventional wired deployments.

There are even more factors to consider: A city-based system can be extremely dynamic. New cars get registered every day, adding to the traffic. New parking lots may be built every now and then and get integrated into the smart city system. New kinds of chips from new sensor manufacturers could be added, as mentioned earlier, to increase competition. New, more sophisticated car-based devices coming into the market might offer to host the smart parking software. Of course, as in conventional systems, new functionality and patch fixes would be released frequently. Finally, as the system becomes part of city life, its utility as an analytical tool could increase beyond analyzing parking trends to other spheres of activity.

These business and technological factors can exert tremendous evolutionary pressures on the system. A smart system in a smart evolving city must evolve, too. Yet, no change anywhere in the system must be allowed to break the system anywhere else. The chances of this happening are higher in an IoT system because interconnection protocols have not matured enough to become universal and because physical device conditions can never be predicted perfectly. For instance, a single extra field required by the central big data server could place an unsustainable additional burden on the fragile radio-frequency system in the parking lot and bring down the entire data transmission.

How DevOps Can Help

To offset the increase in technological and business risk in the IoT, we need robust processes and tools that mitigate the additional risk by improving communication and collaboration between teams. Tools that have the following features become indispensable:
- A centralized dashboard providing a cross-stream view of the software development;
- The ability to trace linkages between all related software artifacts across streams and lifecycle stages, given the stressful nature of interdependencies between streams; and
- A tool that can detect broken linkages.
The tools also need a well-oiled DevOps management culture that encourages close collaboration and rapid communication between development and operations.

IoT heightens the need for close collaboration between multiple software streams and within streams between development and operations. Adopting a DevOps culture and DevOps enabling tools is the way to offset the risks of software delivery in the Internet of Things.

About the Author / Vidhya V. Kumar

Vidhya is an advisory software engineer at IBM. An evangelist and practitioner of agile methodologies, continuous delivery and documentation, she has about 10 years of experience in the IT industry. She is a subject matter expert in DevOps, application lifecycle management and search methodologies.
March 9, 2016
3 Skills Developers Should Master in 2016

The era of mobile and web is upon us, which has caused nearly every business decision-maker to ask the question, Is now the time to hire a developer to build our app or website? In 2016, businesses are going to be looking for the best developers to join their team and help scale their business. We’ve already started to see this trend, as a recent Harvey Nash Technology Survey 2016 found that developers are the most sought-after of all technology personnel.

To stand out from the pack, developers must master the critical skills businesses are looking for. The most valuable developers will be those who can adapt to the changing technology landscape and further hone their craft to help companies scale and solve specific business challenges.

To stay competitive in today’s market, developers need to invest in these three skills to be relevant in 2016 and beyond.

Master the Skills to Scale a Product or Service

Startups increasingly are evolving from early stage concepts to building a growth model to take their business to the next level. To be an asset today, developers need to master and specialize in scaling technologies that are key for businesses looking to expand their customer base and focus on technological innovation.

There is a demand for developers that have not only a breadth of experience in bringing an organization up to scale but also depth in their technical skill set. Having the ability to work on major systems, support large amounts of traffic and customers and maintain the system for several years are critical competencies that companies will be looking for.

Also, having a data model or database experience is very important—NoSQL solutions such as Cassandra, CouchDB or Riak, as well as traditional data sources such as MySQL, are in high demand. Middleware languages such as Java and Golang also are an important part of a developer skill set when building services and APIs.

Understand the Customer Perspective

When building a technology solution, an engineer must be able to look at the product from a customer’s perspective to understand what problem the product is fixing. While technical skills in developing a product and user experience (UX) are very important, the ability for a developer to understand and create a product that solves a customer challenge far outweighs the focus on building the most elegant software.

Engineers who are able to demonstrate project management skills and have experience around scaling infrastructure and ensuring the platform is robust will be in high demand. Businesses increasingly are seeing a need to support growing customer bases and traffic with utmost end-user reliability.

Become a Subject Matter Expert

There is a gradual shift in the developer community, in which engineers are focusing on specializations and becoming subject matter experts. There is an opportunity for developers to create career highlights by merging their talent and passion with opportunities.

Developers are encouraged to identify an area they are passionate about and focus on refining those skills. By being able to find these opportunities that build on their passion, these developers can demonstrate they are able to solve a challenging problem for a large number of users—a competitive skill in high demand across the industry.

The overarching strategy of a successful developer career is to invest in learning how to scale a product or service, understanding the customer perspective and becoming a subject matter expert. Investing in your skills as a developer in 2016 can lead to a longer, more fulfilling career.

About the Author/Sha Ma

Sha Ma is the senior director, Software Engineering at SendGrid. She led development teams at both startups and Fortune 500 companies prior to joining SendGrid. In her current role, she drives strategic planning, development and management of large scale projects. Ma is a graduate of MIT where she earned both her bachelor’s and master’s degrees.

LinkedIn: https://www.linkedin.com/in/shama902
Twitter: https://twitter.com/SendGrid

March 9, 2016
Building a Foundation for Big Room Planning
When people think of agile, the first thing that comes to mind is a software development team. But agile is much more than that now, as every DevOps practitioner knows. Nearly a decade and a half of practice has shown us that high-performing agile software development teams are critical, but not sufficient on their own. When they operate in a silo, software development teams can easily become disconnected from the business and from other teams. To truly achieve the higher business goals, those development teams need alignment, or else they risk delivering the wrong things or the right things but at the wrong time. That is where Big Room Planning comes in.

Big Room Planning is the secret sauce for effective agile planning and execution because it brings together all the people in an organization responsible for delivering software value to market—from development and test to program management and the business—to plan collaboratively. When I say bring them together, I don’t mean that figuratively: The key is to bring them together quite literally, assembling all of the stakeholders together in the same room in real time. That can feel quite shocking because it represents such a significant commitment by the company, but that is the point. Making agile work requires a commitment across every level of a company.

Before the Big Room

So do you just have everyone roll into a large space somewhere in a hotel’s conference area and hit a home run? Clearly, no. Setting up an effective agile delivery group takes time, and is far more complicated than spinning up agile development teams because of all the roles involved and how each team and individual will approach their part of the work. Most importantly, establishing the leadership changes required to truly change the way an organization works must also take place. Bottom line: Establishing an agile mindset throughout the organization is critical to have a foundation for success.

There are three distinct phases of preparation required when standing up an agile delivery group (Agile Release Train, in SAFe parlance), which we call:
- The Ready phase
- The Sync phase
- Rhe Go phase
Each are vitally important, and without success in the earlier phases, your delivery will get bogged down in the latter stages.

Get Ready

The Ready phase is probably the most critical, and it establishes the right leadership, organizational mindset, and right group of people required for agile value delivery. Three key steps include:
- Enterprise value stream mapping
- Agile organization design
- Leadership development
Without these key steps, supported by leadership at every level, you simply cannot instill the cultural and mindset changes required to stick.

Get Synched

In the Sync phase, agile practices are instilled first. Agile practices specific to each role requires training and coaching to set in, and we advocate for a four-to-12-week period to ensure everyone understands their role, the ceremonies they will use to ensure collaboration and what artifacts they will use to plan and execute their part of the overall work.

Once everyone in the delivery group gets it, it’s time to set up a first Big Room Planning event. This typically takes one month of preparation—without which your event is likely to fail.

Preparing for Big Room Planning should focus on the inputs for the event. First among these is the business vision and context—the domain of executives, line of business leaders, etc. This is essentially the “why” behind what the teams will work on. Key initiatives for the delivery group, with clear outcomes defined (often supported by a lightweight business case), must be communicated effectively to inspire the group. It takes time to put this together.

Next, develop a feature backlog that represents what the delivery group will be planning out during Big Room Planning. Doing this well is a more rigorous process than meets the eye. Features are the crucial ingredient because they represent the value being built to both the business and the customer, and they represent the key deliverables teams will produce.

Product managers typically own this step, and if they are not well-prepared, they run the risk of either asking for too much or asking for the wrong things that won’t have the desired impact on business results. At CA, our product managers go through several iterations of backlog preparation involving stakeholders throughout to company to make sure the priorities are clear.

Even with a well-formed and prioritized backlog, effective Big Room Planning requires an understanding of the capacity of the organization to build what’s needed. This requires good estimation and a good understanding of the each team’s velocity. Estimation and a team’s velocity are big parts of what we learn during the Sync phase: Over a few iterations, the amount of work (a.k.a. story points) a team can deliver outcomes and provides an understanding of roughly the right capacity needed for effective planning. Doing this well ensures teams will be asked to plan not only the right features during Big Room Planning, but the right amount of features so that detailed planning can take place with enough time to design stories, resolve dependencies and address risks that emerge.

Then Go

The Go phase actually kicks off with the Big Room Planning event. The event itself occurs over a two-day period, which marks the starting point for agile execution. If formed well, the right people will be in the room to build value fast. With upfront preparation, the group members will understand what they will be building and why it’s important, and will be set up to create a plan that best delivers the value needed.

Planning collaboratively ensures that the plan is well-designed across the group. Most importantly, because everyone has a part in building the plan—with the opportunity to work together across teams and across roles, with the ability to challenge and even veto decisions as they form—everyone ultimately feels a strong sense of ownership and commitment to the final plan. A successful outcome almost always ensues, and the group only gets better from there are they learn to prepare, plan and execute together as a cohesive “team of teams.”

About the Author/Steve Wolfe

Steve Wolfe is Senior Principal, Product Marketing for CA Agile Solutions. He has worked for more than 20 years on software products in both hardware and software companies. His experience spans 10+ years in both software engineering management and product management, including 7+ years on agile teams and delivery groups. Steve’s passions include helping organizations learn how to build the right things fast and reliably by applying agile and DevOps practices at scale. He is a certified SAFe Program Consultant.
March 4, 2016
Putting People Before Software

Software development teams typically are focused on a single goal: delivering new, killer features that users love. Driving revenue and usage is core to Agile and DevOps. Yet without motivated, productive people, you can forget about building good software.

Heightened competition requires companies to go the extra mile to develop and retain employees. Here are several ideas for team-building and personal development, while still pushing an awesome product out the door quickly.

Focus on high performers first

Struggling employees often receive the most attention and oversight from managers, but it’s really the top performers who should get the majority of the attention and development opportunities. While modern learning and development methods can be less costly than traditional conferences and seminars, the same philosophy rules: spend the most time and investment on those individuals with the highest potential. Don’t underestimate green developers who are eager to grow; they may not have shown their colors yet, but you can typically see early on if they will with a little push.

Ditch the annual performance review

Over the last few years, companies of all sizes are starting to move away from traditional generic performance review metrics and processes. The annual review is nearly obsolete, given the pace of change in business and the fact that employees change companies so frequently. Goals set forth a year earlier may no longer be relevant after six months. Performance review planning is also too time-consuming for busy managers these days.

Instead, consider a more organic process where the employee and manager visit quarterly, developing mutual agreements and goals for the coming months. The customized approach is more meaningful and real-time for everyone. A useful reference on modern employee retention tactics is “The Alliance,” co-authored by Reid Hoffman, a founder of LinkedIn. The book’s premise: Stop thinking of employees as family or free agents and start thinking of them as allies on a tour of duty. The “tour of duty” theme is highly relevant in software development, where tactics and objectives are constantly changing and the pressure can be intense. As long as the employer and employee are constantly seeking to get the most mutual value out of the relationship, employee retention should not be an issue.

Offer diverse experiences

Younger employees, including those of the Millennial generation, typically enjoy working in a flat organization where they can take ownership of projects and feel they’re advancing within the organization. Take advantage of that independent ambition by creating smaller teams and giving leadership roles to those who are ready. Younger employees also covet change, so rotational roles can be an excellent way to give them that diversity in experience while also monitoring their progress for long-term career growth. Mid-level employees often feel the highest level of stagnation due to the typically long process of promotion into senior management, so it’s critical to have a strategy for developing and retaining those positions as well.

Motivate and grow senior developers

Organizations often go to great lengths to bring in promising young talent and grow them into senior developers. However, the path beyond for a senior developer often provides a fork in the road, with options to either focus deeper on the technical side as an architect or on the people side as a manager. Executives should support senior developers early in this transition and identify key candidates for each role, and then help them to prepare accordingly.

Make collaboration fun

Developers today should be groomed and evaluated for their collaboration skills. There’s no right way to do this, but a good start is by making collaboration easy and even fun for those highly independent people who haven’t had to communicate much with coworkers in the past. Offer simple chat and social media tools for real-time, online collaboration or feedback tools such as TINYpulse, which can mask someone’s identity if they are too shy to share feedback otherwise. Requiring team members to demo their work in progress for colleagues can encourage collaboration and sharin, and boost product quality through timely feedback. Offer perks or bonuses for those team members who show initiative in teamwork and cross-team collaboration. Needless to say, FACs (happy hours) and other offsite opportunities for the team to unwind together also can break down barriers.

Make innovation a cultural trait

Measuring innovation isn’t straightforward, but making room for it within your organization is a powerful way to both motivate and retain employees and, ultimately, generate business value. Google grabbed headlines a few years ago when it shared its policy of giving technical employees 20 percent of their hours every month to work on independent research projects. Granting employees free time to work on new ideas is smart, but works best if developers are passionate for the business and will reinvest that time in areas that add business value.

More importantly, recognize that innovation is not a program but a cultural value that can only be communicated from the top. Senior-level support for innovation, along with free sharing of ideas, should be baked into team processes and communications. Finally, time is a finite asset. If you’re going to give your team some time off for creative brainstorming, don’t penalize them for lower output or require them to work weekends to make up for it.

Push the soft skills

This is a no-brainer. Modern development teams increasingly are linked hand in hand with business goals and customer outcomes. Therefore, developers must be able to work effectively with business counterparts and understand the language of the business. Give your developers frequent opportunities to present in front of their co-workers for practice, and whenever possible, the chance to work directly with business units on projects.

Look to the community

The days of structured career paths and employee development programs are largely over. Employees want and benefit most by self-learning and exploration with their external communities. This entails giving people leeway to attend meetups, participate in developer contests or attend half-day workshops where developers can interact with others in their field. MOOCs, online degrees and certifications are gaining favor as flexible ways to quickly gain new skills. These informal learning opportunities are much more cost-effective than formal training programs of the past and more relevant. They help employees gain general marketplace knowledge on new development trends and tools, rather than company-specific knowledge and processes.

Investing in technical skills is imperative, yet developers also to want to feel part of a team and work with someone looking out for their career potential. By paying more attention to developers’ personal goals and the needs of the team, software development organizations gain more stability to do what they do best: develop great products.

About the Author/Kevin Dunne

Kevin Dunne is VP of Strategy & Business Development at QASymphony.

March 2, 2016
Why Financial Companies Should Embrace Automated Testing

The drive to deliver new functionality to customers faster is being felt across every industry, and especially so for financial markets that are under pressure from new market entrants. Adopting agile development and continuous delivery can help financial institutions gain an edge and beat competitors to market, but it’s vital that quality is not forgotten.

Financial institutions are accelerating to update software and release new products in days or weeks instead of months. That means software must be tested rigorously and quickly. Manual testing simply cannot compete with automated testing when it comes to speed, accuracy and the ability to perform functions repeatedly over time. However, it can be challenging to implement successfully.

The Customer is Always Right

Customer power is forcing banks to improve customer experience. Accustomed to slick, efficient website experiences from such leaders as Amazon and Google, customers now are demanding similar experiences from their banks and credit card companies. Millennials expect easier access to banking, precipitating a shift to self-service, which presents all kinds of new IT challenges for banks.

When customers don’t like their online banking experience, they will simply choose another provider. A full 18 percent of millennials switched their primary bank in the last 12 months, according to a recent Accenture survey. When failed or flawed software gets into the customer domain, the fallout can be very damaging and expensive. Think: lost sales, disgruntled customers, bad PR and a massive price tag to fix the problems.

Test Automation a Solid Foundation

Introducing test automation isn’t just about finding defects more quickly and efficiently, though it will do that. It’s also about shifting the burden of regression testing and freeing manual testers to focus on issues such as exploratory testing, usability and penetration testing, where they can add the most value.

To implement automated testing successfully, financial institutions must devise a long-term plan that dovetails with their business objectives. Having a plan—and sticking to it—outweighs the importance of getting C-level support and winning a huge budget for automated testing. Without a plan, the most well-intentioned objectives can get rejected by senior management, stalled by other forces and, ultimately, forgotten.

Automated Testing Misconceptions

The plan should include a robust dismissal of two popular misconceptions about automated testing. The first—and bigger—one is that automated testing will produce instant cost savings, as fewer resources (mainly of the personnel kind) will be needed to perform testing.

Over time, automation will cut costs. But cost should never be the main factor when considering automated testing. Applying test automation greatly outweighs all the negatives of manual testing (time-consuming), but it also opens new doors for more sophisticated testing and, hence, the competitive advantage.

The second misconception is that automated testing is a one-time only exercise. Reality proves that automation is always going to be an ongoing process. Automated testing should be treated as (yet) another development activity: You write the production software and you write the software that tests the production software.

Overcoming the Challenges

Financial institutions face a threat from newcomers to the market, unencumbered by legacy system baggage and physical branches. They are offering disruptive products and new business models. How can existing financial institutions compete?

It obviously makes sense to include the business and marketing teams in the development process to develop new solutions for customers. Extend the DevOps mindset to break down those silos. A united team that includes test and marketing alongside developers can ensure that automated tests are well-designed and focused on business aims.

Pulling together to design and test new ideas can enable financial institutions to reinvent themselves and innovate. Embedding test automation in everything mitigates risk and increases velocity and quality. It can deliver the data businesses need to make the right next move.

Long-Term Vision, Short-Term Plans

Fast feedback is paramount to make the right business decisions, but financial institutions must cater to existing legacy systems and integrate new software deliveries from a range of vendors. Without test automation in place, it’s simply not possible to integrate deliveries, test them and reject them as quickly as possible if they are wrong.

The reality is that organizations must be able to quickly introduce new tools and technologies, because agility and innovation go hand in hand, but the impact on legacy systems must be repeatedly gauged. Test management tooling should be fluid and extensible to cater to this diversity. To accurately measure quality and risk in real time, test automation must be dynamic and flexible.

Failure to embrace automated testing will leave traditional financial institutions exposed and in danger of being swept away by the new wave of lean, agile, IT-focused competitors.

About the Author/Viktor Clerc

Viktor Clerc is product manager for testing applications at XebiaLabs, a provider of automation software for DevOps and Continuous Delivery helping companies to accelerate the delivery of new software. You may reach him at vclerc@xebia.com.

March 1, 2016
Embracing a DevOps Culture, Part 1

DevOps is popular right now. So it should come as no surprise that organizations across all industries are eager to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight.

Compared to companies such as Netflix or Amazon, most organizations do not have thousands of application deployments per day. In fact, it’s usually newer companies that are able to fully embrace DevOps, since all of their business operations rely on IT already.

DevOps Philosophy > Procedure

There are many articles out there that try to define DevOps, but DevOps is more of a philosophy than a procedure. If you polled 100 organizations on their experiences implementing a DevOps strategy within their existing business processes, you’d likely get 100 different answers.

An organization’s journey toward DevOps is usually unique, since there are so many different factors that influence a DevOps integration. These include the size and age of the company, what industry it’s in (banking/finance, retail, health care, e-commerce, education, public services), how sophisticated its technology is, the nature of its IT (data center or SaaS), organizational structure (siloed or integrated), development methodology (agile or waterfall), the nature of its mission-critical applications (Web 2.0, virtualized, client-server … ) and more. For most companies that exist outside of the startup ecosystem and rely on Web 2.0 and agile application development, Dev and Ops just don’t get along.

Dev vs. Ops

Trying to collaborate with Dev and Ops can feel like trying to mix oil and vinegar if the goals of each department are not aligned. As a result, IT’s ability to deliver maximum business value is greatly reduced. To efficiently drive the business forward, Dev and Ops must get along.

Most often, the conflict between Dev and Ops is because the focus of one department is at odds with the focus of the other, which creates tension when it comes time to collaborate with one another. While Development is focused on continuously delivering new products and/or features to meet business needs, IT Operations strives to preserve the availability and the stability of IT services and the IT cost-efficiency.

DevOps Can’t Be Limited by Tools

First, for a seamless collaboration to occur between Dev and Ops, both departments must use compatible tools. Mismatched toolsets create bottlenecks, misunderstanding and miscommunications, which result in so much wasted time that the implementation process ends up hurting the business.

Next, processes must align; compatible toolsets with conflicting processes are useless. For example, it’s not unusual to find the service desk is using a ticketing system which is separate from the application development tools used to manage product defects and enhancements.

Developers tend to rely on toolsets that are optimized for rapid development to provide fast feedback on code changes, to automate build creation and for application release deployments. In addition, the Dev team may be unaware of the runtime environment, which makes it difficult to adjust the code accordingly, whereas Operations uses solutions on the target runtime environment, where stability and performance outstrip flexibility requirements.

Since the integration process is unique to each organization, it’s key to find tools that are the right fit for your new processes and employees. Just because a team uses the latest application release automation tools to consistently drive repeatable deployments of application into production, does not mean they have adopted DevOps.

In fact, version control, application release automation and application auto-discovery of business transactions are all tools that help developers meet their objectives, but may not address the other portion of the equation: Operations.

At the end of the day, one of the most important decisions is choosing the right leadership team across your business—from your C-level executive team to the heads of your Dev and Ops teams. The integration process for DevOps can be difficult; to merge two separate departments and processes together to drive collaboration, both the Dev and Ops team need leaders with clear vision of the bigger picture and what’s needed from everyone to drive the company’s forward.

About the Author/Vincent Geffray

Vincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience, as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

Vincent’s Twitter: @vgeffray

February 29, 2016
An Engineering Think Tank to Change the World

In his famous book “Mythical Man Month,” Fred Brooks says, “Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

While being very fond of engineering on the big scale, such as building millions of high-end and yet individually configured cars or double-deck aircraft or space ships, for example, I have always asked myself, why the most promising industry—software engineering—is so often not capable of doing engineering on that scale, too? Or, why are so many big enterprise IT projects painful in so many ways?

With these questions that nobody seemed to be really interested in on my mind, one day I met some higher corporate management, who wondered why the IT department would be so reluctant to follow their lean transformation advice and instead talked about some agile and continuous integration thingy.

From that moment, I understood that everything necessary to radically upgrade software engineering was already there! The biggest problem was that we do not communicate enough—and furthermore, there is no holistic view on the complete IT value chain.

By that I mean we need to create awareness for the value chain, starting with digitized formal models of business processes and written business requirements.

That was how the following chart came to existence, and I still love it. Apparently, most awesome things happen on the borders of separated knowledge domains; you need just to talk to colleagues from departments you’d never talk to! What if we would mix knowledge from big industry, best available process improvement and quality assurance methodology, and apply all this to how we design, build and deliver software?

At first I thought I had found a new perspective on DevOps, but now I believe there could be more to it. Well, now the door to the radical innovation is open! Just imagine: What if we would apply the Internet of Things approach to our industry? Maybe we could close the loop of process improvement in software development and test, moving it to real time and running optimization not by ambiguous frameworks but by hard facts coming from virtual sensors, with unprecedented levels of transparency?

This was how a couple of friends and I came to the idea of our foundation we call SIGSPL (Special Interest Group for Software Production Lines). This public organization is a non-profit think tank, built around three generic domains—Labor Automation, Analysis and Advanced Visualization—which we consider to be the three pillars of the upcoming convergent software engineering in the post DevOps era.

We are sure this sort of thing inevitably will happen, but our mission is to catalyze these processes to make radical innovation happen intentionally and faster, so we all can build information technology that rocks!

We are a small team of six with some infrastructure, publications at our blog and a well-established yet growing knowledge base. We would like to reach out to more like-minded people to let this idea grow and change the world. Our plan is to foster further exchange and discussions between DevOps experts and other specialists “unexpected” in this context, such as production lines and supply chain management experts, Six Sigma Black Belts, 3D artists, hackers, venture capitalists and many, many others.

Our proof that we are not ponding to nowhere is our magic triangle diagram, showing some well-known tools we map to the three generic domains, which are also of high interest for venture capital. Our question to the world is, What would appear in the middle of this triangle in, say, five years?

About the Author/Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, including IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations.

LinkedIn: https://de.linkedin.com/in/muryshkin
Team blog: http://sigspl.org/blog/

February 25, 2016
Shouldn’t DBAs Be Part of the DevOps Inner Circle?

DevOps is changing the culture of IT. This movement is bringing application development and operations teams to the same table and the same time, working to understand and overcome the challenges facing the entire application delivery process—not just their piece. Development and operations teams are forging new bonds and alliances in the spirit of accelerating software release cycles.

However, while quickness to market is paramount to success, businesses can’t forget about the internal implications of accelerated release cycles. With that in mind, there is one conspicuously empty seat within the “DevOps Inner Circle,” and that’s the database administrator’s (DBA).

DBAs hold the keys to one of businesses’ most important assets: the database. But database change innovation has not kept pace with agile development methodologies and DevOps tooling that enable continuous delivery of software updates and changes. The vast majority of enterprises are still updating databases the same way they have been for the better part of the last three decades: through manual script review, validation, execution and individual heroics. As a result, application release cycles ultimately slow down at the last mile—the database.

It’s time for a better approach. It’s time databases and their stewards, DBAs, be part of the DevOps Inner Circle. Including DBAs can create better, more efficient teams; save time and money; and even help companies create better solutions for their customers’ needs or their own.

Shattering Silos

One of the founding principles behind DevOps is the breakdown of silos between development and operations teams. Product managers can easily translate customer needs and communicate that feedback to developers in a way they understand—using epics and themes, for example. This helps bring everyone on the same page so that application updates or changes can be quickly coded, tested and delivered. But before application updates can be released to users safely and effectively, they have to be translated into the changes that will update the database. This is where the DevOps breakdown occurs. DBAs often have to rely on manually intensive, timeworn, error-prone processes and tools to make sure the right changes are made to the database.

By inviting DBAs into the DevOps Inner Circle, database updates that go against business policy and will ultimately lock the database or “break the build” (think inserting a new column with a default value when the row count exceeds a million) can be found faster and addressed by the development team well before that change reaches the database. Having DBAs involved in release cycles sooner can help ensure developers are coding with corporate compliance in mind, ultimately making changes to the database smoother while adhering to guidelines that DBAs have typically policed.

There was a time when databases needed protection from changes made by creative problem-solving in development, but DBAs simply cannot stand against the deluge of changes necessitated by accelerated cycles. Inviting DBAs into the DevOps Inner Circle enables teams to consider the implications of new changes and updates across the entire technology stack. Breaking down silos and making teams more aware of catchpoints in the last mile of the release process lets them anticipate and avoid database issues—which means faster releases and fewer headaches for everyone.

Saving Time (and Time is Money)

Faster release cycles are good for business, and not just because they get applications in front of end users sooner. Continuous delivery cycles are designed to cut costs associated with application development considerably by saving man-hours. Still, while development timelines keep getting shorter, the workload and time to deploy database changes gets longer.

Enterprises can have multiple database configurations, so each change needs to be checked for compatibility. As the complexity of data repositories grows, so too does the time it takes to review and approve changes. In a 2015 IOUG survey on database manageability, 41 percent of respondents said changes took a week or more to approve. With multiple change requests coming to DBAs each month, each week or maybe even daily, it’s clear that sheer manpower can’t keep up with continuous delivery forever. Relief for DBAs is nonexistent without automation.

Remember our earlier example, where we ran the risk of locking the database by inserting a new column with a default value when the row count exceeded a million? Database automation software protects against outcomes like this by forecasting the impact application changes will have on the database. DBAs can use forecast reports generated by automation software to pinpoint any issues without expensive hours or days of searching.

As part of a DevOps team, the DBA equipped with automation can do more than save time and headaches for themselves. Protecting against errors that could break the build saves teams from spending time to find and fix the source of a breakdown, and also saves a business from losing revenue while the fix is made. If so much time, money and potential frustration ride on DBAs’ ability to implement changes at the speed of continuous delivery, why are they still on the outside of the DevOps Inner Circle?

Freeing Up Time for Innovation

Flashes of inspiration rarely come about when you’re just trying to keep your head above water, and for so many DBAs, that’s the reality of work. Today, enterprises fight a war of attrition with the database, throwing manpower at the final hurdle of the release cycle. In addition to the attractive benefit of saving money on man-hours, bringing DBAs into the DevOps inner circle and automating some of their tasks also creates time and space for innovation.

The relational database is nearly a 50-year-old innovation, one that changed the way people and computers interface through data. After so much time, and with so much on the horizon, the next innovation seems imminent or perhaps even overdue. The advent of quantum computing may bring with it a fundamental change to the way databases interact with one another. It’s certain to bring a shift in the way data is stored and retrieved, though at this point experts expect only the most complex business processes will benefit from quantum computing. So, while future tech remains out of reach, DBAs will be vital in the effort to innovate faster, more streamlined ways for dealing with zeros and ones.

The first step to innovation, then, is addressing the needs of DBAs alongside those of customers and developers. Breaking down walls and increasing efficiencies between existing DevOps teams and DBAs will give teams more opportunity to create novel solutions to both their users’ problems and their own. Add another seat to the Inner Circle, save time and money, get quality applications to market even faster, and create innovative solutions to the problems of today and tomorrow.

About the Author

Derek Hutson joined Datical as CEO in 2015, bringing more than 15 years of leadership experience in enterprise software. Before joining Datical, he led multiple companies through extended periods of rapid growth and also held several executive roles at IBM. There he served on the leadership team for IBM’s acquisition of Telelogic, and was responsible for due diligence and integration of the acquired sales functions globally. He currently serves on the board of Hart InterCivic and Charity Dynamics. Other board or advisor positions have included CoreTrace (acquired by Lumension), Innography, StreamStep (acquired by BMC) and Phurnace (acquired by BMC).

February 17, 2016