devopsy.kinsta.cloud

Category: Enterprise DevOps

Chevy and DevOps: What the Wi-Fi?
In DevOps: Rapid Feedback, Rapid Repair

I’m sure you have seen it too. Chevy cars now come with wi-fi. How cool. I want that (and so would my kids). I can only imagine the possibilities.

But, this is not all about my needs. Chevy and every other vehicle maker wants this too. And not for the reasons that you might first consider. Quickly, let me introduce you to the recalls of today:
The glitches were related to cars losing power, erroneously deploying airbags, and other defects. This is just a small glimpse of the software recalls that have happened over the past year.

But more troubling is this form of software “recall” from BMW showing a security flaw that could allow cyber criminals to unlock doors on 2.1M vehicles. Because every one of the 2.1M vehicles has the same defective software part, criminals effectively had access to a skeleton key to every one of them.

In DevOps: Rule Your Supply Chain

The reality is, that your new car has more software in it than you can image — about 100 million lines of code. And, as we know, all software has flaws. But who wants to go to a dealer to get a software update? If my car can connect to the internet and update itself, that would save me an unscheduled trip to the dealer for a repair.

While software updates to cars models in the past were would take 5 years to feed themselves onto the production line, that is now all changing. For decades, large automakers like Toyota have been applying excellent management process for their entire supply chain. And with the introduction of wi-fi in vehicles, they are expanding their highly-tuned practices to include their software supply chains. They know where every piece and version of their software is and who owns it. If a flaw is detected (be it quality, safety, security, or another attribute), they will now be able to automatically update that vehicle. Not only can they remove defects, automakers like Telsa are even making their cars faster.

While many of us outside the auto industry think of these large industrialists as slow moving organizations, the introduction of wi-fi in cars is allowing them to now apply a core principle from the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

In DevOps: Version Everything

For those of you in the software industry, this kind of evolution is at the heart of many DevOps and continuous delivery efforts. Automate everything you can. Version everything you can. Deliver fast, improve visibility, and change fast. In many ways, the addition of 4G LTE Wi-Fi in Chevy Trucks means that DevOps has entered into our auto and software supply chains.

If you imagine an even broader perspective of this wi-fi feature and software supply chain management, the auto makers are now leading the way to expectations of quality improvements in the Internet of Things (IoT). There is not much difference between an internet enabled truck, thermostat or fitness bracelet when it comes to rapidly improving and updating quality, features, performance, etc. (I’ll cover this topic more in future posts.)

In DevOps: Optimize Your Software Supply Chain

What have the auto makers learned from the software industry? And perhaps more importantly — when it comes to software supply chain management and continuous delivery — what can we learn from them?

A final note on software and auto safety: I am the Cavalry (@iamthecavalry) is encouraging the automotive industry to commit to cyber safety. The movement recently published a Five Star Automotive Cyber Safety Framework (PDF download) and calls for Automotive Industry adoption. Media outlets from across the US and Europe praised the effort and joined in calling for automakers and security researchers to work together to ensure a safe future.
April 28, 2015
A True Story: DevOps(Sec) Manages Out Elective Risks
A True Story

There are over 2000 developers in Bill’s organization. He is a C-level executive for one of the largest insurance companies in North America. Bill boosted developer productivity by 15% last year after taking a closer look at the company’s software supply chain. And this approach isn’t unique to Bill’s organization. Many high performance IT and DevOps teams are adopting proven supply chain principles to accelerate software delivery.

Origins, Quality and Integrity

The concept was rather simple and straightforward. Bill’s team recognized that they were consuming hundreds of thousands of open source and third-party software components to build their applications. But at the same time, they did not apply much scrutiny to the origin, quality, age, or integrity of those components. Developers simply selected components at-will that met their functional requirements and helped them meet the next delivery deadline.

Secrets of the Free-For-All

Deeper analysis of their practice revealed that the free-for-all component sourcing methods were leading to quality, efficiency, and productivity issues. Here is what Bill found:
- The company had downloaded an average of 27 versions of over 100 different binary artifacts over a one year period. Bill knew this meant the quality of their applications was being impacted through the use of outdated software components.
- The company had also downloaded 13,203 software components with known security vulnerabilities — and 65% of those included alerts earlier than 2014. Without quality controls in place, Bill recognized they were sourcing in elective and avoidable risks that would impact the integrity of their application, grow their technical debt, and lead to more rework down the road to replace the flawed components.
Removing Complexity

Bill decided to take action. He knew that to accelerate innovation, he needed to remove complexity from the company’s software supply chain. He enacted three moves to eliminate waste and complexity within the open source and third-party components being used:
1. Automate the scrutiny of software suppliers to minimize risk and bloat.
2. Enable real-time traceability and visibility to components used across the development lifecycle, in order to improve response times when defects were discovered – cutting back from days/weeks to minutes!
3. Reducing complexity, rework and risk by standardizing on specific components types (e.g., web frameworks, logging frameworks, encryption modules), using fewer and more current artifact versions, and managing out elective security risks.
Want to hear the rest of the story?

The same principles that Bill applied to his business that boosted developer productivity by 15% are being discussed by Gene Kim (@RealGeneKim), author of The Phoenix Project, and Joshua Corman (@JoshCorman), CTO of Sonatype, on April 30th. Both Gene and Josh are huge fans of marrying DevOps practices with leading supply chain management principles that enable developers to maximize throughput of features from “code complete” to ‘in production,” without causing chaos.

If you’re looking to achieve similar goals, be sure to join Josh and Gene for this April 30th, 1pm ET, discussion.
April 23, 2015
Enterprise DevOps: Standardize for Security

Etsy is a shining example of the success that can be achieved with continuous delivery (CD). By 2014 Etsy had doubled its deployment rate, deploying more than 50 times a day. Today the site deploys API changes in 18 seconds and launches a new website every 150 seconds.

That’s speed, to be sure. Speed that very few enterprises need or want to achieve. But that doesn’t mean that Etsy and CD don’t have valuable lessons for the enterprise, because one of the reasons CD and Etsy succeeds is because of the underlying principle of standardization.

Whether it’s standardization of tools or of processes – or both – it is standardization that eventually drives such speed. The use of the same tools and the same processes over and over hones them until they’re an optimized, lean delivery machine. That standardization has other, benefits, too that are as beneficial – maybe moreso – to the enterprise than the speed it eventually brings.

Standardization of delivery processes in the enterprise, especially when extended to such concerns as security and the network, result in direct and indirect benefits. Directly, standardization allows security and even network infrastructure to ensure that corporate policies are implemented. If all infrastructure – application and network alike – should only be hosting certain services (like HTTP and SSH) and not others, standardization can help enforce that. Template-based (or policy-based, if you prefer) automation along with an “infrastructure as code” approach can assist in ensuring that basic security and network policies are put into place for every application deployed. Customization can (and should) be allowed and encouraged as extensions to the core templates (or policies) deployed during the app deployment process.

Indirectly, standardization on a common toolset and processes will reduce the stress on network and security operations that comes from trying to implement common policies across a conga line of solutions. There’s no getting around the reality that many enterprises employ sometimes twenty or more “middle boxes” that provide everything from security to monitoring to performance and scalability services. Each one must be provisioned and configured during the app deployment process. This is not a trivial problem. 26% of organizations cited “security policies that are too complex and can’t be enforced with the current network security processes and controls” as a significant challenge in a 2014 ESG survey. Establishing a standardized template that encapsulates common (required) policy implementations can go along way toward addressing the challenges network security professionals face when trying to secure applications across a growing portfolio of both applications and network services.

This level of standardization is not easily achieved. There is no easy button, and that’s one of the reasons DevOps can be a desirable approach in the enterprise to addressing these kinds of problems. It isn’t just about achieving phenomenal speed, but rather achieving consistency through the standardization of processes and methods used to deploy security policies and controls that can improve the stability and the security of the entire application and network environment.

DevOps is, in relation to network and security operations, more about CPR for infrastructure services than it is speed. Consistency through standardization. Predictability through automation. Repeatability through templates and by treating infrastructure as code.

DevOps is an approach to operations and inter-operations that can have just as many benefits in the enterprise as it does for web-scale and startups born in the cloud. The same standardization that benefits Etsy by giving it extreme speed can benefit enterprises by endowing it with extreme security.

April 23, 2015
The Top Ten ORA Messages Explained

In the past, data managers operating Oracle data systems had to rely on an unrelenting number of manuals and booklets to figure out how to efficiently maneuver around Oracle errors. The age of Google has transformed this quest, making the lives of countless developers far less painstaking. Now those facing an error that just does not seem to want to go away are also faced with a wealth of resources on the other side of a web search.

Several websites have dedicated databases and Oracle writers that work exclusively on developing content to streamline Oracle troubleshooting for individual errors. But why stop there? We compiled a list of the ten most searched Oracle errors on the Internet.

1. Invalid or Nonexistent Column Name – ORA 00904

This is a simple fix. The error is triggered by either an invalid or missing column name. An ORA-00904 can be evaded by making sure to begin a column name with a letter, only use alphabetical, numerical or special characters (and using quotations with other characters), and not exceeding thirty characters in length.

2. Unhandled Exceptions in PLSQL Code – ORA 06512

The description for this won’t bring much information; just an “ORA-06512: at line ” will show up. So what does it mean? The stack being unwound by unhandled exceptions in your coding brings about the error. There are a couple of options to managing this. You can correct whatever is causing the unhandled error, or you can write an exception handler for the error. However, due to the complexity of this, it may be best to refer to your database administrator for more help.

3. Failed to Connect with Listener – ORA 12154

For this error, the connecting name could not be located in the naming method repository, or for some reason the repository could not be found. There are a multitude of actions available to correct this, primarily involving the verification of file names, net service names and syntax.

4. Executing SQL Statement that Doesn’t Exist – ORA 00942

The basis of this message stems from attempting to execute a SQL statement that either references a table or view that does not exist or that you cannot access. You will need to check to see if the table exists, and if it does not you will need to create the table or view. If you don’t have access, speak with an administrator about this issue.

5. Invalid Username and/or Password – ORA 01017

The ORA-01017 is an error not exclusive to Oracle. All it means is that the username/password combination entered was incorrect. Checking your system parameters to make sure the ID is aimed at the proper location, and just simply re-entering the login information from there should do the trick.

6. Missing Expression Error – ORA 00936

Another quick syntax fix! This message is triggered from a required clause being left out, such as the SELECT statement being entered without an incomplete expression, or when a reserved word like SELECT TABLE is misused.

7. “Invalid Number” Error – ORA 01722

This error is being thrown due to a failed attempt to convert a character string to a number. This will happen because arithmetic functions in Oracle can only contain numeric data, and only numeric data can be added to or subtracted from dates. Find the invalid data, which sometimes can be hidden if part of a sub query, and correct it to fit within the Oracle numeric parameters.

8. Arithmetic or Numeric Value Mistake – ORA 06502

The ORA-06502 is triggered when a numeric, string, conversion, constraint or arithmetic error occurs. Many times this will result from assigning a value to a numeric variable that is larger than the variable permits, or from assigning a non-numeric value to a numeric-only variable.

9. Invalid Character Error – ORA 00911

This is a syntax error that is about as straightforward as it can get. The cause stems from a number of mistakes, such as starting an identifier with a character other than a letter or number, or not enclosing identifiers with special characters in double quotes.

10. Improper Clause for SQL Command – ORA 00933

The final error on our list, another syntax error, derives from an improper clause ending an SQL statement. For instance, an ORDER BY clause cannot be used to create an ordered view in Oracle, but perhaps the error was triggered when the ORDER BY clause was attached to a CREATE VIEW statement. Also, additional indented lines can trigger the problem.

Concluding thoughts

These are the most searched errors either because they are the most commonly occurring ones, or because they are difficult to resolve. The fortunate thing about Oracle is that so many errors derive from simple syntax mistakes that do not require a great deal of knowledge to mend. Of course, as you have seen with this list, working past them and preventing them requires a strong base understanding of how to operate efficiently within Oracle by keeping track of parameters and the proper protocol for actions.

The other prominent set of Oracle errors come from issues involving the network that Oracle is accessed through. By establishing a strong rapport with your network administrator and keeping aware of the details of your network (memory space on drives, who can access what, etc.) these kinds of errors can largely be circumvented.

While this list is not exhaustive by any means, it should help in not just providing brief descriptions and solutions for the ten errors mentioned, but also by putting you in the proper mindset to take on other Oracle errors beyond the list and work to operate your data with a superior adeptness.

About the Author/Judd Robins:

As Executive Vice President, Judd is instrumental in driving the overall direction and revenue growth of the consulting services division of TekStream Solutions. He works collectively with his team to launch territory campaigns to increase customer awareness, excel in quality of solution delivery, and established a presence in the region as a leading Gold Oracle Partner for Enterprise Portal and Enterprise Content Management technologies.

You can get in touch with Judd on Twitter | LinkedIn

April 22, 2015
Is ALM Dead in the World of DevOps?

Has DevOps killed Application Lifecycle Management (ALM)? If the question makes you dizzy, you’re probably not alone; after all, it seems like just a few years ago that ALM was a fresh, new idea — and a key component of most implementations of Agile. So what happened to ALM, and why would DevOps kill it (if that’s what actually happened)? First, a little history:

(more…)

April 15, 2015
DevOps across the Enterprise: Fostering Cross-Functional Collaboration
DevOps practices originated at startups, where nimble Development and Operations teams pioneered the concept of cross-functional collaboration to speed up software release cycles. By 2009, DevOps became a recognized industry practice: a software development methodology that promised higher velocity for enterprises working to get products to market more quickly. Many enterprises have since embraced DevOps among their software development teams, and early adopters are now taking it beyond code to other parts of their organization.

Unfortunately, successful cross-organization collaboration is uncommon outside of Dev and Ops teams. With the Internet of Things bringing software and hardware together in previously disconnected devices and industries, collaboration among design, development and product management teams has become crucial. There are technical, procedural and cultural challenges which must be addressed to bring the same level of DevOps success to other areas of an organization.

The State of Collaboration

An important place to start is understanding the interactions between different groups in an organization.

Consider one of the most frustrating areas of the software release process prior to DevOps-style collaboration. Builds would be “tossed over the wall” from Development to Quality Assurance, and then from Quality Assurance to Operations, with each team moving on to other things as soon as a build was handed over. Visibility into the overall status of the project was non-existent.

When other departments collaborate, what is the level of visibility into the work being produced by the groups that depend on one another? Does marketing know if the latest feature made it past the initial legal review and the likelihood of it being included in the final product? The answer is usually no; there is little visibility into the process and decisions are shared close to project deadlines. Applying DevOps practices to an organization’s entire product pipeline changes the collaboration paradigm, expediting time to market and improving overall quality.

Culture, Automation, Measurement and Sharing (CAMS)

CAMS is relevant when both technical and non-technical teams collaborate. As seemingly unrelated teams are required to work together, it’s important that they have a culture of shared accountability.

Skipping the details of specific tools and technologies, one key consideration for organizations to recognize is that automation is crucial to a repeatable process, enabling speed and scale. It also provides a high level of visibility, as it’s closely coupled with the sharing of data. When only one team is manually updating metrics, communicating what’s going on is manageable. But what happens when other groups are dependent on work being produced by a group that’s updating its data manually? What if multiple groups depend on knowing the status of a task in a timely manner? Manual processes result in an endless flood of phone calls, emails or instant messages asking if information is up to date.

The measurement aspect of DevOps opens up a can of worms. It’s important not only to determine what should be measured but also to have a common way of discussing how it’s being measured. Establishing a common vocabulary across an organization for day-to-day tasks can be extremely difficult.

In these situations, it is important to go back to the core benefits of trying to bring the DevOps style of collaboration to other groups in an organization.
1. What is the desired business outcome?
2. Why don’t current processes meet requirements?
3. How could change positively benefit employees’ daily work?
As people become comfortable with “why,” discussions of “how” become easier.

Once changes are underway, it’s important to make sure that there is a single place where people can obtain accurate status updates and share information. Bringing DevOps into the enterprise takes time, but providing visibility into any project in an automated, transparent manner will show the positive impact of sharing information in a timely way.

Most importantly, try to quickly demonstrate success—however small. There will be roadblocks, political objections (an unfortunate reality) and people who just don’t want to change. But by measuring and demonstrating success and tying it back to business outcomes, you will set up your organization for success.

Like many other initiatives, the key to a successful DevOps program is intention. To drive this home, an old joke: how many therapists does it take to change a lightbulb? Just one. But it has to really want to change.

About the Author/Jonathan Thorpe

Jonathan Thorpe, Technical Marketing Manager, Perforce Software –Before joining Perforce as a Technical Marketing Manager focused on Continuous Delivery and DevOps, Jonathan Thorpe held technical marketing roles at CFEngine, Serena, and Electric Cloud, where he specialized in DevOps culture and automation technologies. In his spare time you can find him reading, playing with all of the current video game consoles, dabbling with mobile software development, and playing with the Raspberry Pi.
April 10, 2015
What IT expects from SDN is DevOps

There was much excitement in the air when the announcement that Docker had acquired SocketPlane. Not the least of which was emanating from my corner of the world, where DevOps for network (the whole network) is something you’ve noticed I pretty much live and breathe.

The announcement was couched as an SDN (Software-Defined Networking) play by containerization-leading Docker. Which might be confusing at first because, well, Docker (and to be more general, containers) are generally associated with DevOps, not SDN.

Ah, but therein lies the rub, doesn’t it? While the original precepts of SDN were most definitely not DevOpsy in nature, it (like every other trendy term in tech) has evolved to focus as much (if not more) on what are certainly DevOps-like principles and goals than on technical specifications and standards.

Consider, for example, this recent Avaya sponsored, Dynamic Markets report (gated) on “SDN Expectations.”

The first data point to examine is the ranking of “problems” experienced by respondents. The number one issue (38%) was downtime caused by human error. The second (tying with a network-failover issue at 37%) was complexity of configuring services and applications across the network.

If these aren’t typically problems that are said to be resolved by DevOps – particularly with attention paid to collaboration and automation – I’ll eat my hat. And yes, I often wear hats, it’s a quirk I have.

And just as interesting was this table illustrating not just problem areas, but how many respondents had the problem and how many expected SDN to solve them:

If you ignore the network management tuple, the top two problems are definitely often associated with DevOps as issues that can be resolved with collaboration and automation and some measurement thrown in to boot.

SDN has evolved, at this point, to focusing more on network automation than it does on automated networks. The difference is actually profound as it relates to DevOps, as the former is really about management, about configuration and provisioning and automation of processes designed to extend CD across the entire application deployment lifecycle into the production environment. It’s about codifying and encapsulating configurations in templates and centralizing state of the network in order to engender better agility in both moving forward and falling back when things go awry.

SDN today really is (or should be) a subset of DevOps, focusing on network infrastructure operations rather than app infrastructure operations. But the same principles and goals are very much aligned between DevOps and SDN, between the network and the application infrastructure. That’s a critical convergence starting to appear that’s necessary, as when you dig into IT and its problems delivering apps on time these days, it’s mostly the network that’s still in the way.

The network is identified often as a key IT pain point and usually the pain is related to the provisioning of services and applications across the network. High costs of networking is also cited, and that is largely due to the complexity of the network and the amount of operational sweat and blood that goes into manually provisioning, configuring and testing the various pieces of network infrastructure required to deploy the services business needs to deliver applications.

SDN may continue to be referred to as SDN, if only to emphasis its focus on network infrastructure, but the reality is that it’s DevOps. DevOps for Networks.

Which brings us right back to why a DevOps-related, containerization company like Docker would swallow up an “SDN”-focused start-up like SocketPlane.

Because what IT expects from SDN is really DevOps. And if DevOps is ultimately about culturally change and breaking down silos, the folks who focus on the network can’t be (and shouldn’t be) isolated from the folks managing the application infrastructure.

Docker’s move brings software-defined networks together with software-defined operations under (what should be) an IT encompassing concept: DevOps.

April 2, 2015
Variable Speed DevOps: A Deep Dive

About 2 months ago I wrote an article on “Variable Speed DevOps“. To be clear I first heard the term used by Carmen DeArdo, Director of Application Development at Nationwide. It was a response or play on the 2 Speed IT dilemma. In 2 Speed IT, emerging digital processes coexist with traditional ones. The implication is that the “traditional” processes can’t run at the speed of the emerging digital ones (even older digital can’t run at the speed of newer digital processes). But the question is do they have to?

According to Carmen and other folks I have spoken to, the key is not making processes run faster than they are intended to. It is blending all of the different processes and the speeds they run at to mesh together into one finely tuned machine. Like the different size gears within a Swiss watch, perfectly tuned to keep the correct time down to the millisecond. Variable Speed DevOps is about the fine tuning of an organizations IT machine to make all of the different size and speed gears work flawlessly.

Of course this could be much easier said than done. Carmen has spoken about Nationwide’s journey in this regard. I have also had the pleasure of participating in a Google Hangout with Carmen, Sanjeev Sharma and Rosalind Radcliffe of IBM where we discussed this concept as well.

The notion of Variable Speed DevOps existing in Enterprises with traditional Systems of record, co-existing side by side with new Systems of engagement and code is destined to be as dominant in the world of DevOps within enterprises as Hybrid Cloud is going to be the dominant form of Cloud.

I believe that the idea of Variable Speed DevOps deserves a deeper look. There is much that we can learn and share by delving deeper into the concept and hearing from experts who are on the front lines of Variable Speed DevOps. To do this we are teaming up with our friends at IBM to peel back layers of Variable Speed DevOps and show you how you can bring it to your organization.

We will be kicking of our deep dive into Variable Speed DevOps with a series of webinars, the first of which we are announcing today. I will personally be hosting these webinars. What better place to start our deep dive than with Carmen DeArdo and Sanjeev Sharma. We will feature other guests in future webcasts.

Part 1: May 5 – How Nationwide Insurance is adopting DevOps for variable speed IT systems
In the May 5th webinar, we will focus on the ongoing transformational journey at Nationwide Insurance and lessons learned. (Replay available)

Part 2: May 19 – Canada Mortgage Housing Corporation breaks down IT silos and speeds up mainframe development
In the May 19 webinar, we will focus on lessons learned at the Canada’s national housing agency in their DevOps and Agile transformation. (Replay available)

Part 3: June 2 – Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study
On June 2 we will discuss the process for quantifying DevOps benefits for your business stakeholder. (Replay available)

Part 4: June 25 – Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud
On June 25 we will look into synchronizing mainframe, mobile and hybrid cloud to support end-to-end mobile development. (Replay available)

Besides the webinars, we will also feature articles and other content related to the topic. We will build up this new section of our site over the coming weeks, so stay tuned. But wait there is more. We want to hear from you! What is your view on Variable Speed DevOps? Do you have any lessons or thoughts on the subject? If so you can write me personally at editor@devops.com. I would love to hear from you. We can have you write your own post on this, we could interview you for a future article or maybe you could be a guest on a future webcast.

Variable Speed DevOps is going to be important in your DevOps Journey. Join us on May 5th to hear from Nationwide Insurance and stay tuned for additional client stories on this topic.

March 31, 2015
Webinar: How Nationwide Insurance is Adopting DevOps for Variable Speed IT Systems

To drive towards faster innovation, and also ensure the stability of the core business, the need arises for what is being termed as “two-speed or variable speed IT.” While innovative Systems of Engagement demand speed, agility and experimentation, legacy Systems of Record need governance and predictability. Two-speed IT enables adoption of DevOps capabilities by adapting them to the “speed” of delivery. It requires two-speed business planning and processes and even two-speed organizational structure and budgeting. Join Carmen DeArdo, Director of Application Development at Nationwide Insurance, Sanjeev Sharma, lead DevOps Technical Evangelist at IBM, and Lee Reid, executive IT specialist as they show how IBM’s solution is helping Nationwide adopt DevOps practices for variable speed IT systems.

This webinar is the first in the Variable Speed DevOps – A Deep Dive series.

Event recorded Tuesday May 5th, 2015

SLIDES

[seoslides embed_id=”be17733a1254″ script_src=”https://devopsy.kinsta.cloud/embed-script/webinar-how-nationwide-insurance-is-adopting-devops-for-variable-speed-it-systems/6643/” overview_src=”https://devopsy.kinsta.cloud/slides/webinar-how-nationwide-insurance-is-adopting-devops-for-variable-speed-it-systems/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Webinar: How Nationwide Insurance is Adopting DevOps for Variable-Speed IT Systems” /]

VIDEO

Your Host:

Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

About Panelists:

Carmen DeArdo, Nationwide – Director – Tools and Technology Leader

Carmen DeArdo, Director – Tools and Technology Leader, Nationwide Insurance, An ardent advocate of DevOps and a leading speaker in the DevOps and technology related events, Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies.

Sanjeev Sharma, IBM Worldwide Lead – DevOps Technical
Sales and Adoption, IBM Cloud Unit

Sanjeev Sharma, IBM Worldwide Lead – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

Lee Reid, IBM – Senior IT Specialist

Lee Reid, Senior IT Specialist, IBM, is a senior solution architect with focus on practical adoption of software engineering tools, software delivery solutions, application life cycle management, and DevOps. He has over 25 years of experience in software engineering, design, programming, testing, development, tools & methodology, team leadership, and strategic planning.

March 31, 2015
Making DevOps Work with External Contractors

On a recent ‘virtual panel’ session, many questions came in real-time from almost a thousand attendees around the globe. I’ll try to cover the most interesting questions in this column over coming weeks, but one that came through many times is very typical of the discussions I have with my customers and others, especially those from larger enterprises:

Q. How can we implement a DevOps approach with external contractors, consultants, vendors and service providers?

Many of my customers regularly use external programming shops and third-party consultants, from across the street and across the globe. A majority also use third-party service providers, especially cloud and hosting services, to help delivery the on-demand infrastructure that fuels DevOps.

The good news is that you can definitely incorporate these third-party vendors into your DevOps approach, even in a large enterprise, starting with a few simple steps.

Establish Open Communication

Establishing open communication lines is critical to DevOps, and no less so with external contractors and service providers. This open dialog should start at the planning stages, working together to establish common goals and expectations, including timelines, work methods, pace of delivery, and generally ‘how things work.’

I recommend connecting face-to-face if at all possible, even if you can only do it once or twice, whether you meet at their place or they come to you. There is something special about meeting in person that brings to life many important DevOps concepts – like empathy, sharing, communication and cultural understanding.

For large and globally diverse teams, in-person meetings can be cost- and time-prohibitive, but you can also achieve similar outcomes through virtual conferencing. Here I recommend immersive ‘tele-presence’ style systems, rather than the more common ‘cheap-and-cheerful’ web conferencing tools. Grainy headshots taken with low-res webcams, displayed seven-to-a-row in tiny windows, simply will not create the deep personal connections the same way as high fidelity communications.

Maintain Ongoing Collaboration

However, inexpensive web-based technologies are ideal for maintaining ongoing collaboration, once you have established those initial lines of communication. Use web–based video-conferencing to bring external consultants into your teams’ regular communications, from planning sessions and standup meetings to post-mortems and ad hoc chats.

Also consider integrating external teams into your internal messaging systems, providing them with corporate e-mail addresses, including them in mailing groups and directories, connecting them to your chat and IM applications, and providing access to collaboration tools like shared workspaces and shared storage. None of this requires them to be on-site, or even in-country, but will help immensely to make them part of a collaborative, integrated team.

Share Access to Internal Technologies

Speaking of technologies, I have also seen multi-national and other cross-silo teams using common tools to share SDLC activities, status reports, system views, operational insights, and even vocabularies. Sharing access to common tools between contractors and employees alike – for example to share goals and assignments during planning, manage and report on project or backlog status, check code in and out, perform QA and integration tests, integrate new code into existing repos, release code updates into QA or prod, monitor and triage operational performance, or provide feedback from one system or team to another – definitely helps to connect and integrate external teams with internal teams.

Share Processes with Automation Tools

Automation tools in particular will help to integrate third-party contractors into established DevOps practices and processes. Shared automation allows you to make your ‘known-good’ processes a repeatable and reliable shared resource to all your teams, internal and external. Providing shared access to automated processes for check-out/check-in, code integration, test data management, provisioning and configuration, code release, and more helps external teams to adopt the same approaches, and implement change in the same ways, as internal teams – while also providing essential audit and control.

Use Virtualization to Span the Globe

Virtualization technologies especially will help to abstract internal environments for external workers – across the street or across the globe. Server and OS virtualization (and related approaches like containerization and cloud computing) allow easy exchange of common platform and build environments; network virtualization allows remote teams to code for abstracted internal networks; service virtualization allows multiple teams to develop and test in parallel even without shared access to internal systems; virtual storage allows teams to easily swap in or out common shared datasets; exposing functions or microservices as virtual APIs allows remote specialists to work independently yet still leverage others’ work; and of course virtual private networks allow secure access to internal systems for remote users anywhere.

Find Your Own Approaches

Fundamentally, there is no reason DevOps will not work with external contractors, consultants, vendors and service providers. Communication, collaboration and integration can certainly face new barriers at the enterprise’s edge, but these are not insurmountable. Ultimately you must find approaches that work for your enterprise – and I would love to hear about them in the comments below or on Twitter – but if you establish mutual goals, ongoing communications, common processes, and shared tools, you will be well on the way.

March 30, 2015