devopsy.kinsta.cloud

Category: Blogs

Webinar: Using Jenkins & XebiaLabs Software to Ensure Quality in Continuous Delivery
With the growing need to quickly release software and add value for customers, the trend towards Continuous Delivery is undeniable. At the same time, challenges exist in managing code quality within the software delivery pipeline. You are likely to have numerous tests in your pipelines to ensure quality, but making sense of all the test results produced by various jobs – and identifying the culprits and repeat offenders – becomes harder and harder as you speed up the delivery of your software.

XebiaLabs and CloudBees can help you deliver better software faster. Join us live to see how you can:
- Quickly understand and improve the quality of your code by leveraging the Jenkins Workflow plugin and XL TestView’s (formerly known as XL Test) aggregation, reporting, and qualification capabilities.
- Make sense of your test data – collect, visualize and analyze data from all of your test tools in one central dashboard.
- Extract test results directly from multiple Jenkins jobs and visualize them in a consistent way.
Recorded Thursday, June 11th, 2015

RECORDING

SLIDES

[seoslides embed_id=”34a13639038a” script_src=”https://devopsy.kinsta.cloud/embed-script/7777/7805/” overview_src=”https://devopsy.kinsta.cloud/slides/7777/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Using Jenkins & XL Software to Ensure Quality in Continuous Delivery” /]

Your Host:

Alan Shimel, Editor-in-Chief of 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.

Panelists:

As CloudBees’ Sr. Director of Product Marketing, Dan Juengst leads the product marketing efforts for the CloudBees Continuous Delivery Platform powered by Jenkins. Dan brings 20+ years of high tech experience to CloudBees with expertise in grid computing, high performance computing, and application performance. Dan has worked as both customer and vendor at both startups and enterprises. Dan’s resume includes Red Hat, Sun Microsystems, SGI, Wily Technology, Terracotta, and Lockheed Martin where he started his career computing hypersonic reacting airflows around Mach 30 flight vehicles.

Viktor Clerc is the XL Test Product Manager at XebiaLabs and is responsible for development, marketing and support of XebiaLabs’ test management and analytics solutions as part of their delivery automation product suite.
May 14, 2015
Webinar: From DevOps to Dev-Test-Ops – Automate Your End-To-End Software Pipeline
Software quality matters. Adopting DevOps practices and increasing collaboration between Dev and Ops helps align teams around what matters to the business: Shipping product. Thorough testing is a critical step that is often handled manually, introducing risk and unpredictability into the process. Join Electric Cloud and Tricentis as we demonstrate proven techniques to ensure your software quality by automating more of your end-to-end software development lifecycle, including testing.
Join this webinar to learn:
- How DevOps practices help your Dev, QA and Ops Teams work more efficiently
- How test automation eliminates manual handoffs and increases coverage
- How detecting errors quickly can help developers optimize quality
Date: Wednesday, June 3rd, 2015

Time: 2:00pm eastern standard time

REGISTRATION LINK:(CLICK HERE)

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:

Dr. Gerd Weishaar Vice President of Product Management, Tricentis

Dr. Gerd Weishaar has over 20 years of experience in product development and product management from various software companies, including Segue Software, Rational Software and IBM. As VP of Product Management at Tricentis, Dr. Weishaar currently manages a team of experts who have a strong focus on market demands and needs. His team is responsible for managing the entire product life-cycle of the Tricentis Tosca Testsuite and product marketing related content and communication. Dr. Gerd Weishaar is a computer science graduate of the Johannes Kepler University in Linz, where he also obtained his Ph.D. He is also an MBA graduate of the prestigious MIT Sloan School of Management in Cambridge, Massachusetts, USA.

Anand Ahire Director Product Management at Electric Cloud

Anand has over 13 years of experience in product management, marketing and development and is a Pragmatic marketing certified product leader and customer advocate. Prior to Electric Cloud, he lead product marketing teams at BMC Software and eGain Communications and is very experienced in agile development methodology, DevOps, Continuous Delivery, IT Service Management (ITIL V3 Certified), application monitoring and automation. He holds an MBA in Information Systems and Marketing from Asia’s most premium business school Indian Institute of Management, Ahmedabad and a Bachelor of Engineering Electronics and Telecom from the College of Engineering Pune.
May 14, 2015
Moving from Infrastructure Automation to True DevOps

Deciding on two separate teams, or an integrated end-to-end team

While a lot has been said about “the right way” to do DevOps, what we’re seeing in practice are two different approaches being tried to enable development and operations to work together as a team. On the one hand, there’s the approach to create an end-to-end, integrated development team, which you might call ‘Devops’. On the other, there’s ‘DevOps’, featuring two development teams – one working on application code, with another developing a platform using Infrastructure as Code techniques in a virtualized environment.

DevOps: providing a platform

Perhaps the most obvious way to go is to have a platform team to provide a runtime environment that “just works”, and a separate application team that develops the business logic to run on the platform.

For some organizations, particularly where one of the teams is outsourced, this separation is going to make more sense. You might buy an off-the-shelf product, build your own platform in-house (which seems to be what many organizations are looking to do with Docker right now – warning: it’s harder than it looks!) … or sign up with a PaaS vendor.

Whatever the situation, the platform should be versioned, just like any other piece of software.

This approach can be ideal for developers because they are free to work on code and focus on the business logic, and they really don’t need to worry about how it runs in production. It’s up to the operations team to make sure that the platform is stable and that it delivers what the developers need.

Communication is still key

Even with a physical or organizational separation, the importance of effective dialogue between the two teams cannot be overstated. This won’t work if the relationship is adversarial. There has to be a genuine awareness of common goals. If the operations team doesn’t understand where the development team is going, and what they need from the platform, then there’s going to be trouble. The idea that one platform is going to cater for every development need is often unrealistic, so versioning and the ability to run multiple platform versions side-by-side, or cater for exceptional situations where a particular application might need its own stack, is very important.

There has to be a clearly defined boundary, which should be close to the application code and configuration layer. The application handles the business logic, the platform handles the deployment, logging, monitoring, failover and auto-scaling.

The development team can focus on getting those new features and improvements into the live product, while operations handles the actual roll-out and manages traffic. For this to work, the platform must enable you to quickly determine who is responsible for any problem that crops up. It’s worth investing time in the setup to ensure that errors are explicit, so you don’t waste time tracking them down.

Arguments between the two teams are bad for progress and morale.

Devops: A full stack development team

For some businesses, it’s going to make more sense to put together integrated development teams that work directly on delivering the full stack from a shared code base, from virtual machine to application code. This allows you to design and optimize each system in a way that takes the application’s specific perspective and requirement into account, and can be an especially good fit if your applications differ from each other greatly in terms of the operating systems, middleware, etc., that they run on.

This approach can only work if the overall group is small (Amazon’s “two pizza” teams are a good example) and has sufficient knowledge and experience to see the big picture of the entire system.

It’s not possible for everyone to understand every part of the full stack in detail, but there are areas of overlap where greater collaboration will increase the level of shared knowledge and allow the team to build a better overall system.

Pulling together

The shared foundation of the Devops approach builds mutual respect and enables more free-flowing communication, but it must be based on shared goals and a vision of what the overall purpose of the system is. This integrated approach can give you much more flexibility, but it also means holding the whole team responsible for keeping everything running. Shared code equals shared responsibility.

The right approach

You need to take a baseline, and then put metrics in place to track your progress. You have clear goals in mind and a system to measure them. So how do you find the right approach to achieve those goals?

It would be wrong to say that one approach is better than the other. What you need to do is assess what will work in your organization. Both are means to achieving similar goals, but finding the right approach is about understanding what your company is looking to achieve. You might choose common goals, like reduced expenditure, or reduced error, or you might choose something more specific to your industry. Establish your goals at the outset, and make sure that they’re measurable.

The right approach is going to be the one that gets results for you — that’s why setting up a baseline and metrics is so important. You may find that a hybrid of the two approaches is going to be the right fit, but you aren’t going to know for sure until you have some hard data to back up your expectations.

Be sure to join devopsy.kinsta.cloud editor-in-chief Alan Shimel on Thursday, May 21^st as he hosts the webinar, “Ship Faster without Breaking Everything” to further your smarts on Continuous Delivery.

About the Author/Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs, a provider of continuous delivery automation. Andrew is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

May 14, 2015
The 3 practical change elements in enterprise DevOps

Culture, Technology & Ecosystem

Most enterprises approach DevOps adoption in a singular fashion: they use a bottom-up approach that is typically technology-driven and groups all considerations like, culture, metrics, processes and communication into a single stream of work that is often led and implemented solely by technology-oriented champions.

However, this singular approach presents a few issues:

(1) First, it leads to poor planning on the change aspects of DevOps that are not (and should not be) technology driven – although we (DevOps Evangelists) are not change experts, we believe we can properly assess impact & lead organizational change just because we are the subject matter experts on the technical topic (DevOps). Accordingly, we miss the wider context and relationships with non-IT functions that would be impacted by DevOps.

(2) Second, it naturally focuses the efforts on the areas inside our comfort zone (technical aspects) and potentially disconnects the DevOps program from the Enterprise priorities. If it didn’t, it limits DevOps to a technical change of tools and automation.

(3) Third and most important, it contributes to the absence of realization that the changes in areas outside of IT is critical to the success of DevOps adoption and that specialist (internal or external) help in these areas may be required and better yet, often acts as a catalyst for change.

The consequence of the 3 points above is that post the initial phases, enterprises reach an incomplete point of “DevOps Equilibrium”; this is the state that enterprise IT reaches after installing some automation tools, setting up a basic practice and changing some behaviors. It takes a lot of effort, dedication and pressure on the organization’s DevOps evangelists to make this initial launch and bring the beginnings of DevOps into their Enterprise. By the time they reach that point, energies are depleted, the bigger challenges of enterprise politics and ecosystem become apparent and the thought of another push to bring in more teams, departments, tools and stakeholders on board becomes a burden.

The question then becomes, why is it a struggle and why is it difficult to adopt DevOps in an Enterprise? The reason is that the singular, technology-driven approach that “considers” the soft aspects of DevOps fails to leverage the value it delivers by transforming it into executive sponsorship and political influence; and the reason this happens is because executives consider a bigger enterprise view that stretches outside of their departments and outside of IT but the technology-driven, singular approach has a narrower view and fails to address the ecosystem of the enterprise that surrounds the technology and the culture, and accordingly all the executives’ concerns.

In my experience, one of the main reasons DevOps evangelists in Enterprises fail to move beyond their point of equilibrium is because they approach DevOps as a singular, technology change not as an enterprise change.

What I have seen from multiple enterprise DevOps journeys is that Enterprise DevOps adoption should be broken down to 3 main “Change Elements” and DevOps Evangelists should plan for each “change element” separately under a single program umbrella:

1st Change Element is “Technology” – Enterprise IT landscapes are typically diverse with bespoke and packaged products. Having the technical expertise to understand what DevOps tools fit the enterprise landscape and how to integrate them into bespoke and packaged products is key. Also, understanding what does “implementing DevOps” mean to different IT systems is crucial; for example, do you need to automate the release of revenue-assured systems where speed is not as important as quality or is it enough to implement quality inspections only? Also, which systems do you start your journey with and based on what criteria did you choose these systems/projects?

2nd Change Element is “Culture” – This is looking into how the IT teams would change the way they work, for example, developers need to check-in more frequently, business analysts need to learn to write behavior-driven requirements and operations should start understanding more about what developers do. Another example is how the developers’ (or testers … etc.) objectives will change to become more DevOps-Friendly? (For example, objectives should focus on the handover points between teams rather than team-specific activities). This is more focused on internal IT rather than the rest of the enterprise. Challenges arise here when adoption is phased without change planning – when developers potentially are required to change their approach when testers and operations teams are not. In this scenario, frictions arise.

3rd Change Element is “Ecosystem” – This is the core of the message and it is about how to plan for organizational change outside of IT. This element is about how DevOps impacts the enterprise outside of the IT space and how to position DevOps to the rest of the enterprise. Here are a few examples of what should be done in this space:

(1) Finding a Context: DevOps evangelists need a context for their initiative and it needs to complement other efforts in the organization. For example, evangelists should choose an organizational pain point like “poor customer experience driven by poor product quality”, and position DevOps as the IT solution among a wider enterprise program to tackle the issue – this helps evangelists take a benefits-driven approach to DevOps adoption, which goes along way in navigating the politics of the enterprise.

Another example is the “lean initiative” – in most organizations I’ve seen, there is usually a process improvement or lean initiative going on in non-IT functions; evangelists need to hook into these relevant initiatives, present DevOps as aligned with the organization’s direction of becoming lean and position DevOps as the IT part of that lean journey.

(2) Second, evangelists need to understand and assess the impacts of DevOps outside of IT. For example, as they change the culture by changing developers’ objectives (see above), how does that impact the overall HR strategy of the enterprise that places roles in bands and have a clear definition of a “Star” and how to promote this “Star”? Similar to HR is financial governance: how does a DevOps lifecycle work with the budgeting and financial governance process of large enterprises that releases budgets in gates/phases that are typically not iterative?

Another example is how do evangelists link their DevOps metrics with the wider organization performance KPIs and business objectives? How do evangelists deal with the enterprise’s managed service providers and system integrators who may very well be located oversees and get them to work in a DevOps way without breaking existing contracts?

(3) Finally, evangelists need to understand the political landscape and how to gain IT and non-IT support to their DevOps journey. Activities in this space should address the following questions: how do evangelists gain IT and non-IT Executive sponsorship to get non-IT teams to support their journey?

Answering all of these questions above requires partnerships and help from other non-IT enterprise departments – but how do evangelists build these bridges?

Because of all these Ecosystem challenges, I believe DevOps adoption in the enterprise should be approached as an enterprise change not a technology change. DevOps evangelists should dedicate separate plans for the 3 change elements above under a single DevOps program and they should not be shy of reaching out for non-IT help (external and internal).

In the next few blogs, I will discuss each change element separately. Then I will answer the question that probably most of you are asking by now (continuing with the analogy): So what happens if the enterprise passes this “DevOps Equilibrium” and reaches a point of “DevOps Escape Velocity”? The point when DevOps is an established and acknowledged enterprise standard. What benefits will the enterprise reap? And why isn’t the point of equilibrium enough?

About the author/ Tarek Negm

Tarek is a DevOps and Lean IT enthusiast with a specific interest in the change aspects of the movement. He is a founding partner at Do Consultants where he helps enterprises adopt and realise the business value of DevOps and Lean IT. Before that, Tarek spent his career in global organisations in the UK and Europe working in IT leadership and Technology roles in a wide variety of industries including Telecoms, Financial Services, Hospitality and F&B. Tarek’s experience spans all the technology lifecycle starting with Linux kernel development to Enterprise Architecture and IT Strategy, in addition to IT change where he previously led a global IT transformation program across 5 European countries. Tarek holds an MBA from London Business School focused on change management in technology. Reach him on LinkedIn:

May 14, 2015
Five areas of software development innovation to watch

Software development has undergone a massive transformation in the last two decades. From the first wave of breakthrough do-it-all PC applications such as Lotus 1-2-3 and Microsoft Office, to the launch of the first iPhone and its all-new “app” category, to the recent release of the iWatch and its projected evolution of apps, developers have never been more in demand to support these new technologies.

In May, my company Gemini Solutions will be celebrating our 10-year anniversary, and we’ve been fortunate to have worked first hand on huge advancements. Our close partnerships with some of the most innovative technology companies have given us firsthand insight into areas of significant change, growth and importance for software engineering.

1. Mobile Keeps on Rolling

The biggest area on the horizon for developers is the increasing prominence of mobile. Active in the mobile space since 2007, we have seen the demand for mobile-focused projects explode in recent years, and anticipate it is only going to get more popular. This space has seen incredible change in just a few short years. iOS app development continues to be the most requested, but we’re seeing a lot of growth in Android as well and expect it to continue to gain prominence as more Android devices enter the market. As Microsoft establishes itself as a platform, its apps will not be as in demand as iOS or Android, but I have a feeling that we’ll see growth for them as well.

2. Be Aware of Wearable Apps

Apps are no longer limited to mobile and are branching out to new devices, such as smart watches and bracelets, as they gain in popularity. There’s been a lot of buzz around Apple’s iWatch and the demand for the device is expected to be huge. We’re already receiving requests for the development of wearable apps so companies can keep up with the technology. Many of the inquiries are consumer-focused at the moment, but are beginning to move into the enterprise as well as these devices have the potential to become a one-stop-shop for both everyday and business uses. In addition, we believe that connected app development is also going to increase sharply in prominence. As these new devices link to mobile phones, tablets and computers the demand for interconnectivity is going to be huge.

3. Functional Programming Making a Comeback

We’ve noticed that the functional programming model is starting to see an increased push again. Scala is very popular for functional programming and is gaining traction with developers. We’ve also noticed people using Scala in conjunction with big data installations. JavaScript is immensely popular right now as well and we’re also seeing increasing use of Angular. This space is constantly changing and we expect to see even more infrastructures appear to offer more variety and choice for development.

4. It’s the Real Thing: The Internet of Things

The Internet of Things is the perfect amalgamation of mobile, embedded and cloud. The Internet of Things is bigger than the Internet of Humans. We’re seeing a lot of intelligent connected devices appearing on the market, and this is only going to accelerate as demand increases. A prime example is the popular internet-based security systems, with web-enabled locks, internet-controlled light and heating/cooling accessibility and the ability to view your home at any time via the device of your choice. Companies continue to make large investments in this space, prompted by the growing popularity of connected devices. We’ve been working with the Internet of Things for several years, but it is still a new frontier in many ways and we’re looking forward to being part of the space as it continues to develop.

5. Making a Big Deal About Big Data

In just a few short years, the hype of Big Data has gone from dream to reality. Everyone has their own interpretations of what Big Data actually means, but don’t let that fool you into thinking it’s a flashy trend; it is here to stay. The cloud is emerging as an increasingly popular way to develop and test new analytics apps and for processing big data outside of the enterprise. Data agility will also become even more central as organizations begin regularly using massive amounts of data, as opposed to just capturing and managing it. The umbrella of big data covers many disparate applications. Being able to analyze massive amounts of data to determine user activities, actions and preferences will be priceless to companies, and is why we will continue to see this space explode in popularity.

The software development space has never been constant or stagnant. Huge advancements and innovative new technologies are continuously appearing to change the game and open up new possibilities. We have been honored to be part of this movement for the past decade to help drive these crucial projects forward. If the past 10 years were any indication, the future of software engineering will be bright, unpredictable and unfathomable. I can’t wait to be there for the next chapter.

About the Author/ Theo Nissim

Theo Nissim, CEO, Gemini Solutions – Theo is a seasoned Silicon Valley technology executive with more than 20 years experience. He has led pre-IPO start-ups, built dozens of technical teams, developed technology strategies and driven innovative products and solutions to market. One of Theo’s many strengths and passions is managing large scale, cross-functional development efforts to high profile product releases. Theo has held executive and management positions with large public companies, Sun Microsystems and Wind River Systems, and served as the Engineering Vice President for VC funded start-ups, Digital Fountain and AdKnowledge.

Theo has a Masters Degree in Computer Engineering from the Technion, Israeli Institute of Technology in Haifa Israel. He lives in Palo Alto, California, with his wife and twin boys.

May 13, 2015
Documenting DevOps: Agile, Automation and Continuous Documentation
Chris Riley former GigaOm analyst, O’Reilly author, devopsy.kinsta.cloud featured writer and founder of Fixate I/O has written an outstanding report on the key role documentation must play in the modern software development lifecyle. Agile or DevOps, automated or not, we live in a continuous IT era. So why shouldn’t documentation be continuous as well? Riley’s analysis includes key findings including:
- Even the definition of documentation is subjective. Despite several decades of implementation, the methods, drivers, and even language of documentation are nearly limitless. Standards such as ITSM help stabilize the look, feel, and process of documentation, but it does not help an organization understand how to use that documentation and integrate it into development.
- The modern software delivery pipeline introduces new complexities in administration. New tooling in the DevOps space has improved application efficiency and quality, but in some cases, this has also reduced the manageability of the environment. This creates new challenges to knowing what you have, how it functions, and how to extend it into the future.
- As the delivery pipeline moves to a continuous stream of releases, classic documentation processes become impossible. Documentation must happen automatically within the process, or not at all.
- In order for documentation to be useful, it needs to be actionable.
Download the complete report on continuous documentation for an in depth analysis, conclusions and guidance:
Documenting DevOps
URL
This field is for validation purposes and should be left unchanged.
Name*
First Last
Company
Email*
May 13, 2015
Webinar: Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study

Whatever your conviction, the reluctance by senior management to justify new investments and sponsor major change in existing software delivery practices and technologies, while theoretically understandable, often leaves application development executives and managers lobbying for additional budget and resources putting them and their teams between a rock and a hard place. So the question is how do you monetize the benefits and measure your DevOps results? Join Valerie Scott, Manager of Shared Services Division at HM Health Solutions, Rick Slade from IBM, and Alan Shimel from devopsy.kinsta.cloud as they discuss the process for quantifying DevOps benefits using metrics your business stakeholder will care about the most. They will walk you through the methodology and share customer case studies that demonstrate the impressive ROI that DevOps is providing to IBM clients worldwide.

EVENT RECORDED: Tuesday, June 2, 2015

VIDEO

https://www.youtube.com/watch?v=J5haNExYZ2o

SLIDES

[seoslides embed_id=”f384dfd0ae4e” script_src=”https://devopsy.kinsta.cloud/embed-script/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/7686/” overview_src=”https://devopsy.kinsta.cloud/slides/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study” /]

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:

Valerie Scott, Manager of Shared Services Division, HM Health Solutions Strategic planner and IT leader with years of architecture and infrastructure experience in the healthcare insurance industry, Valerie is a key player in the IT Transformation efforts by driving a lean wave of change in the HM software delivery pipeline with DevOps concepts and technology.

James (Rick) Slade, Executive Solution Architect, BVA, Cost Benefit Analysis, IBM Rick is an Enterprise Solution Architect at IBM and spends his time helping clients design and automate enterprise software development and delivery practices. He is certified as an IBM and Open Group Distinguished IT Specialist.

May 12, 2015
4 Ways DevOps Teams Create Value.

Sven Malvik – I’ve written thousand of lines of code based on lies, lies I hoped were the truth. The truth is that we make false assumptions. Assumptions that kill our business. I’ve built software that was too expensive, I’ve built software nobody wanted, and I’ve built software that never saw the light. If you are like any other developer you probably have lied too. But it doesn’t matter. What matters is the application we haven’t built yet and that we will build based on the truth. We need the truth to create value and to survive. This article will show you 4 ways of how DevOps teams create value.

(more…)

May 12, 2015
DevOps Spring Tour 2015: Keeping Cool with ICE

One thing I love about conferences is finding out what other people are doing in industry and getting exposure to new ideas. I like to get external feedback on my work because I find it to be helpful. Here’s some highlights from where I’ve been and what I’ve heard so far in 2015, including Alterconf, RSA, A Data Presentation Course with Edward Tufte, and DevOpsDays NYC.

AlterConf

My first stop was Alterconf in Atlanta this year. I try to support local events and knew I would gain a lot of perspective from the presenters that I probably wouldn’t find elsewhere. There was a lot of discussion about age bias and discrimination for both younger and older people as we all move through those stages during our lives. Starting a culture of continuous learning early in life was a consistently supported goal among the presenters and attendees.

My other take away from alterconf is people may or may not be comfortable representing or discussing the different groups they belong to with anyone. Introverts can have a very difficult time talking tech at an event, for instance. Several speakers at the conference made note of the fact that we will occasionally step on each other’s toes due to what are ultimately misunderstandings and we should be quick to apologize, provide space, and try not to get too upset when someone makes a mistake or appears uncomfortable. I was encouraged to see the consensus lean towards discretely and respectfully bringing any issues up if necessary instead of public exposing someone. Even snapping at a manager in a meeting over a wisecrack about a father ‘babysitting’ his own kids does more harm than good. You shouldn’t stomp on anyone with both feet over failed build either. Having a calmer conversation with a smaller audience if possible was the advice I heard repeatedly throughout the day.

We’ve been having more conversations around anxiety and burn out as a community and talking a lot about comfort, learning, and danger zones. I’m going to openly admit I was more nervous than usual going into alterconf as a white cisgendered heterosexual male. It may have had something to do with the fact that I didn’t know what cisgendered meant before the event. The anxiety quickly passed after I found my seat and realized there were plenty of people there just like me. At a minimum all of us were passionate about technology. It was a very open and welcoming space and I gained a lot of perspective that I wouldn’t have otherwise. There are 5 more sessions scheduled this year if you may be interested in gaining some perspective from a broader range of people that are also passionate about tech.

DevOps Connect @ RSA

DevOps Connect @ RSA was a uniquely awesome experience. I met a lot of security folks coming into the DevOps space for the very first time which was encouraging to see. I also got an up close look at the security industry and why they need to gain some insight from a DevOps perspective. The expo floor was the most commercialized one I’ve ever seen at an event. It reminded me of a midway at a state fair. I wouldn’t have been shocked if someone had called me in for a go at the ring toss. Most of the sales pitches sounded like magic beans to me, bolted on for instant risk mitigation.

The one vendor that separated themselves as an exception to this was Tufin. Tufin’s security orchestration suite is a comprehensive solution for network security management providing visibility, change tracking, analysis and auditing for firewall policies, network devices and cloud platforms. It also provides automatic firewall change management and application connectivity management. It assures a tight security posture, rapid service delivery and regulatory compliance across all enterprise platforms.

I haven’t taken it for a spin myself, but Tufin definitely impressed me with their demo and orchestrated approach to the problems security is currently facing.

Certification was also a consistent topic of conversations at RSA. I think there’s a lot of misunderstanding in this space between arbitrary compliance and compliance that legitimately mitigates risk or provides a return on invested time and energy. This sentiment echoed through Secretary Jeh Johnson’s keynote, as he announced the opening of a satellite cyber security office in Silicon Valley and an invitation to cooperate with concerns surrounding encryption.

Data Visualizaiton Workshop with Dr. Tufte

My next stop was Boston for a data visualization workshop with Dr. Edward Tufte. When I told him I was a devOps engineer working on dashboards in an enterprise environment I could tell he was curious but may have not heard the word devOps before. The person I was speaking with before Dr. Tufte came by mentioned a health care system that still faxed data between offices and the problems it caused with younger employees that had never used a fax machine before. It was obvious to Dr. Tufte that they should switch it to a web based system, and the frustration with compliance and risk concerns that prevent that change from happening were not lost on him. For lack of better words and opportunity, I offered this as the type of problem devOps is currently trying to solve. The perspective I gained from the session that followed was from an experienced professional that can fully appreciate the current state of the art. I believe I appreciate it now more than ever, for which I’m thankful.

DevOpsDays NYC

The topic of discussion was ICE, or Inclusion, Complexity, and Empathy, based on a post by Dave Zwieback from earlier this year. The talks focused on how to try to cooperate better between teams both at home and abroad and suggestions on how to handle departments that are more territorial in addition to dealing with our own stress levels.

Attendees seemed particularly grateful towards John Willis and Justin Lintz for talking about burn out and anxiety in our industry among heavier topics. If you’re inclined to start a conversation about these types of health issues in your community then you probably should. I try to shut up and listen as much as possible, and that’s often helps more than one would think. If you have a venue to show John’s video before an open spaces event all you have to do is book the room and be available. Creating an opportunity to discuss these issues is a huge step forward in my opinion.

But wait! There’s More! I’m giving an Automating Enterprise Security Talk at Gluecon outside of Denver later this month. I spoke about this at devOps Connect @ RSA but I always update my content between talks as I get more feedback from folks. If you happen to be at Gluecon this year we should have a conversation over coffee, a beer, or a meal. From my experience a chat tends to be more fun in person than online, as I for one get tired of staring at screens all day.

May 12, 2015
Communication: Who is to blame for misunderstandings?

Communication is everywhere and it is far more than only the spoken word and its origin meaning. Communication is one of the most complex and also complicated topics in human relationships: most of the time very thrilling, sometimes frightening but always important!

As we all grew up with communication, you might think, we should be used to communicating very well. But daily life shows us that misunderstanding is the companion of communication. We all know from our own experience how hard it is to clear up such misunderstandings and how much precious time is wasted on them!

The more people with different personalities are trying to communicate with each other, the higher the probability of misunderstandings.

To take a closer look at all those cross-functional teams like devops or agile scrum teams you will recognize at once that there are lots of individual issues because of misunderstandings in every team. Each single issue on its own is disrupting daily work, something we all know from personal experience. Now try to imagine how much of a team´s efficiency is taken away by the sum of all issues caused by bad communication and misunderstandings! It is unimaginable!

Communication is the link between all stakeholders: it determines the atmosphere in a team, the relationship between all parts, the understanding as well as the knowledge and information transfer. It influences the project times, the employees´ identification with the company or their work, individual responsibility and how to deal with mistakes. This list could go on and on.

Time in IT projects is one of the limiting factors. To save time and avoid mistakes, new tools are be developed again and again. Companies invest money in these tools; sometimes tools are integrated in the teams, sometimes the teams are arranged around the tools or systems. But the very human part – the communication – which is important for every team, no matter which tools or which systems are used, is seldom the focus of IT education! You can changes methodologies, systems and tools, but if you do not get beyond bad communication, you won´t reach the full potentials of all those efforts. No matter if you have already chosen your tools or systems or if you are still searching for the right way for your team, you should always think about the communication within your team. Instead of always asking what the ROI of communication courses will be, you should better ask what the ROI of all those tools and systems could be with optimized communication!

Before optimizing the communication you first have to find the bugs in the individual and in the team communication and eliminate them. Due to the inherent complexity, the support of an expert is sometimes useful. Just as not all people using computers are IT experts, not all people are experts in communication – even though they are communicating the whole time, sometimes even by saying nothing. Some are more gifted than others, some are able to learn by studying on their own and others need a little more time and support. Changing communication mostly means to change personal habits and this is always an extremely challenging requirement. Particularly for “brain-workers” like developers or other people from IT, it is very helpful to have some background information in combination with practical applications given by experts. First little steps of debugging the communication will soon be honored by success.

“First do it right, than do it fast!”, is a developers wisdom. Concerning the communication this wisdom could be changed into: “First debug your communication, then optimize it!”

Coming back to the question in the headline, it is not important to blame anybody for a bad communication. Everybody is responsible for it and instead of searching for the guilty one, you should start working on it. Be brave, start debugging you communication!

May 12, 2015