Category: Doin’ DevOps

  • DevOps and QA: What’s the real cost of quality?

    DevOps and QA: What’s the real cost of quality?

    As continuous delivery and DevOps speeds the cadence and volume of development, quality assurance professionals and the groups they work in must find ways to transform their roles. Because in order for businesses to truly get value out of the applications they’re delivering through DevOps automation and iteration, they don’t just need to attain speed from the process but also quality. And if they don’t, the costs to the business may be more than people think.

    “Software is transforming from a business enabler to a business differentiator,” says Wayne Ariola, chief strategy officer for Parasoft. “The costs and risks associated with failure has shifted dramatically over the years.”

    Ariola recently presented some cost figures at the STAREAST conference to show how dramatic the costs of quality failures can be. Over the past few years he’s made it a pet project to follow headline news on notable public company software failures and track them to stock prices to do a quick back-of-the-napkin equity analysis. According to his analysis, the typical net decline in the value of a company associated with the announcement of a failure is $2.3 billion.  These types of events can be anything from something like American Airlines’ announcement of that a glitch in iPad software used by pilots in the cockpit grounded a number of flights this spring to Chrysler’s admission that software incompatibilities between the electric control unit and the battery pack control module in Fiat electric cars could suddenly shut cars down.  Ariola says that in 2015, the average net decline of publicly-traded companies that made headline news for software failures was 4.18 percent.

    “When you’re about to release something, and it’s about to go out the door, do you hang out with the developers and say, ‘Hey, if this fails our stock price is going to decline by 4.18 percent? ‘” he says. “These are conversations we’ve got to start having (as QA professionals).”

    Market valuation is only one indicator of the costs, too. There’s also the more difficult to track issue of customer churn, which is only going to increase as the software-driven world evolves and newer generations’ expectations of software quality ramp up. Whereas Boomers, GenX and GenY consumers simply got used to things like the blue screen of death and troubleshooting wonky software, Millennials have been less desensitized to quality issues. What’s more, they have more alternatives than ever, so when problems come up, they’re more likely to ‘nuke’ a product or service and choose a competitor—say switching between one app to another on their phone—rather than even bothering with failed software.

    “Their tolerance for faulty software is much, much lower than ours is, and it’s going to change the way people consume software,” Ariola says. “We need to be aware of that as a team of testers, because we need to drive the agenda much differently than we are today.”

    One of the key elements of that is switching the mentality of testing as a time-boxed event into a set of practices that “infiltrate” development and deployment processes and “escalate the process maturity.”

    “You’ve got to go from manual to continuous tests.  You’ve got to get beyond this idea of just pure automation, and strategically look at this application so you understand the risks associated with it today, and the concept’s going to change,” Ariola says. “So with this speed comes a totally different paradigm.”

    In the past, the question that gated releases was whether testing was done or not.

    “I’m going to propose that the real question is does the release candidate have an acceptable level of risk?” he says. “I have to understand the business expectations associated with the risk of that application, and if it’s in an acceptable boundary, we’re going for it, we’re releasing it, and hopefully we can roll back really fast if we need to.”

     

     

  • DevOps Leadership Series: Monitoring Containers and Microservices

    DevOps Leadership Series: Monitoring Containers and Microservices

    Trevor Parsons (@trevparsons) is a Co-Founder and Chief Scientist at Logentries, a leading SaaS-delivered log management and analytics service. I caught up with Trevor at the Velocity Conference in Santa Clara and asked him what themes were resonating with attendees this year.

    For this episode of the DevOps Leadership Series, Trevor briefly illustrates some current problems with state of microservices and container-based architectures, while sharing a positive outlook for the future.

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

    Trevor says there’s been a lot of development in how to log and monitor containerized systems and he sees better support from Docker for logging, showing an increasing focus on this topic in 2015 and beyond. He anticipates the next year to have huge improvements in managing and monitoring these new systems and architectures.

    Next up in the DevOps Leadership Series, I headed to London for the DevOps Connect: Rugged DevOps event, where we’ll discuss more about Rugged DevOps practices.  In London, I was able to catch up with Helen Beal (Ranger4), Justin Arbuckle (Chef), and Gareth Rushgrove (Puppet Labs).

    If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).

  • DevOps Leadership Series: Compliance, Testing, and Rugged

    DevOps Leadership Series: Compliance, Testing, and Rugged

     

    This past week, I headed to London for the Rugged DevOps event, where I had the chance to catch up with a few more industry thought leaders.

    Screen Shot 2015-06-10 at 9.22.55 AM

     

    First, I caught up with Gareth Rushgrove from Puppet Labs, who also runs the DevOps Weekly newsletter.  In this episode of the DevOps Leadership Series, Gareth explains why the importance of security tests within DevOps practices is going to be a big topic for years to come. Gareth anticipates that “In five years time we will look back on this and ask ‘why were we not always doing this’?”

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

     

    I then caught up with Helen Beal, Head of DevOps at Ranger4, where she discussed the importance of DevOps and security.  While the two ultimately need to work hand and hand, she voiced concerns about DevOps practices sometimes circumventing controls that are essential to a business’s safety. She also said that DevOps supports security in a number of ways: from making things consistent to relying on more automation.

     

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

     

    Finally, I caught up with Justin Arbuckle, Vice President, EMEA & Chief Enterprise Architect at Chef. He discusses key trends he expects to see in over the next 9-12 months regarding compliance and security.  Justin explains that compliance as a core driver of DevOps is something that will start to shape our conversations over the next year, whereas the two have previously been seen as contradictory. He believes that we will see that high velocity organizations are able to improve compliance continuously, and tells us to look out for the changing role of the security officer in 2015.

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

     

    Next up in the series, I head to the United States Capitol, Washington DC, for DevOps Days DC.

    NOTE: If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).

  • 5 Ways Continuous Integration Reduces Risk in Development

    5 Ways Continuous Integration Reduces Risk in Development

    ***This post is based on themes and ideas from the great e-book, “Continuous Testing,” by our friends at Parasoft.

    There’s a lot of talk about DevOps and Continuous Integration in the tech space right now, but sometimes the implementation of those methods can be tricky.

    An effective Continuous Integration strategy requires DevOps teams to manage risks in software development with a range of practices.

    Here are five processes you can use to make Continuous Integration work for you.

    Automated and Self-Testable Builds

    DevOps professionals can use separate machines for software integration to eliminate the tight coupling between the build process and Integrated Development Environment (IDE) that leads to last-minute integration concerns.

    Everything needed to build the software should be contained in a separate version control repository.

    Dedicated Continuous Integration servers and open source build automation tools can run these builds through continuous testing processes and deploy the product in the required environments.

    Automated deployment further eliminates the bottleneck of waiting for other team members to deploy testable versions of the latest software.

    Synchronize Version Control Repository

    Continuous integration is only possible as long as Dev, Ops, QA and the wider IT team is tightly integrated, collaborative and supportive of each other’s efforts.

    From a tooling perspective, effective collaboration requires a separate-but-unified master database updating changes in real-time.

    All database artifacts — including scripts, procedures and other assets should be placed in this version control repository.

    DevOps teams can enable Continuous Database Integration by using automated database integration, local database sandbox and version control repository to share database assets, as well as empowering developers with capabilities to modify the database and making DBAs a part of the Dev team.

    Build a Stronger Foundation and Expand Test Coverage

    Limiting test cases to individual assets executed at every check-in to the version control repository ensures the continuously integrated builds are defect-free in combined form.

    Tests should be repeatable and performed continuously in virtualized systems replicating unavailable testing environments.

    Continuous Integration methodologies allow you to determine how much of the code was actually tested without much manual intervention.

    Although some code coverage tools can assess the percentage of test coverage by package or class, Continuous Integration systems ensure this coverage is updated in real-time.

    For instance, DevOps teams can run these tools as part of the Continuous Integration server build script every time the version control repository is updated with a code change.

    With this information, untested code would never get through to the next stage and the latest test will be conducted across all areas as required.

    Enhance Project Visibility

    With automated build testing and deployment using a centralized code repository, build feedback mechanisms update Devs and Ops with the latest test results and the necessary progress information.

    In cases when the same level of automation for complex builds seems impractical, DevOps teams using manual procedures must establish a feedback loop to bring everyone on the same page with real-time communication and notification of accurate performance and results.

    These capabilities ensure the same high standard of reporting is maintained for manual testing practices as available for automated build testing systems.

    Follow Consistent Dev Standards

    Quality code forms from the ground up, with adherence to common code and architectural standards established for an organization’s specific requirements.

    Automated inspection tools enable Devs working on short and quick builds to maintain their focus on quality from the very foundation of the software itself.

    DevOps teams should assess every integration build for potential defects that surface after integrating several iterative builds but should be taken care of far earlier during the development stages.

    In Conclusion

    The right toolset is key to Continuous Integration, as is the cultural change that facilitates this DevOps practice.

    Continuous Testing presents several areas of improvement for DevOps teams to develop iterative builds in individual, isolated branches and then merge the latest builds in a unified, single and well-synchronized Master branch.

    The idea is to ensure all risks are mitigated beforehand so DevOps professionals are not bogged down with endless needs to rework the product — and that gives them time to focus on true Continuous Integration.

  • How DevOps could save the world; like your colleagues’ day

    How DevOps could save the world; like your colleagues’ day

    DevOps is about a few things but above all, it’s about communication and understanding each other. In that spirit, I decided to create a new day to celebrate: “Like your colleagues’ day”. The rules are simple:

    The first rule of like your colleagues’ day is: You do not talk about Fight…

    • Each year, on the last Thursday before summer (Thursday the 18th of June this year).

    Thursdays are ideal days to make people happy since they’re right before the week-end but not totally there. Right before the summer as it’s all sunny and nice outside.

    • Present a token of your affection to your dear colleagues. Remember, it is a token, not a romantic dinner for 2 in a 3 stars restaurant in Paris. It could be anything from a rose to a beer after work or anything that makes sense to you and the person who receives the gift.
    • Since DevOps is all about loving each other, the day is called “colleagueS’ day”, meaning that you should make as many people happy as you can. A box of chocolates for a team is a good way to make many happy at once for example.
    • Once again, DevOps is about love so you should also consider this day as a good opportunity to bury the hatchet. If you have notoriously grumpy colleagues, maybe all they need is some consideration. A smile, an uninterested chat (meaning you actually listen to what’s being said and do not expect anything in return) and maybe a sweet or a coffee are excellent ways to make people around you happy.
    • Even better, try to make someone you do not know happy. After all, people you have not talked to yet might be full of surprises, right?
    • Money is not the point. For once, you can bake a cake, you can offer to get coffee for your colleagues, you can listen to them and maybe even share a bit too, after all discussions are better with two or more persons.

    Actions have consequences.

    It’s quite simple really, once you’ve introduced your colleagues to the concept (beforehand for better results) and the day has happened, take a step back and draw your own conclusions.

    The first few times I have tried this, only a few persons followed but as the actions were not focused on one person only, others got to enjoy the day and joined in in later editions. The results were above expectations, people got to talk about food, cakes and pretty much everything that can be said during mingling. Where I really saw a good DevOps potential in this is when people from different teams started to play the game and started to communicate together. Some went for beers after work and got to know each other, making things smoother and easier at work afterwards.

    LYCID is also a good opportunity to have activities. While you can think of a management breakfast, it’s not too hard to imagine a technological lunch where everyone is invited or a wine/beer lottery in which everyone can play. As long as the normal work time is respected, everyone should be happy.

    Don’t stop me now, I’m having such a good time.

    Well, you get the point by now, make your colleagues happy and try to create a better work atmosphere by being nice to each other. But that should also open your mind a bit and maybe you could apply a layer of niceness to the world around you. Let people out before going in the subway, hold the door to the person behind you, try to smile when you think the moment is right (you have to figure that out for yourself) and why not, give your change to the first person in need you see.

    This can sound naïve, maybe borderline stupid but imagine a world in which people were nice to each other, no matter the social class, gender, religion… If we were a bit more tolerant, a touch nicer to everyone and a tad less self-centered, this world could actually be really pleasant to leave in.

    Add a pinch of DevOps in that and what do you get?

    Repeat the operation as many times as you want, being nice never killed anyone. Make it a part of your personal and professional culture to be nice, available and polite. Through an iterative process, determine when you can smile without looking like Forest Gump and after a while it will be automatic, you will naturally become good and this will feel nice, trust me. Check the impact of what you did on your colleagues, measure their happiness and if you think things did not change enough, don’t wait until next year, be spontaneous and repeat the operation. After all, baking a cake and getting the coffee for your team should not take too much time or efforts, should it?

    If you feel this could do a difference, spread the word, DevOps is about communication and sharing. Feel free to improve the rules, feel free to ignore some, in the end, all I want is to make you happy.

    I’ve said this before during a conference but as we talk about unicorns, rainbows and other nice things when we mention DevOps, why not dream that we could also make a little difference in the world surrounding us. A little is better than nothing. DevOps could save the world!

  • Top 3 DevOps Practices for Operational Stability

    Top 3 DevOps Practices for Operational Stability

    Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

    (more…)

  • DevOps for non-engineers

    DevOps for non-engineers

    If you’ve scrolled through LinkedIn or companies’ career pages, you’ve probably seen the term “DevOps” used as a part of a job title. DevOps Engineers and DevOps architects are everywhere, and many people are surprised to find that those titles aren’t correct. It sounds innocuous: After all, isn’t DevOps something that you do? If you’re a marketer, hiring manager or non-engineer at your company, it might seem like it.

    But nothing could be further from the truth. DevOps is actually a philosophy and a set of practices that guides how your engineering and IT teams work. And using the term improperly can cause problems, even if you’re speaking with somebody who has “DevOps Engineer” on their LinkedIn profile.

    To clarify what DevOps is and what it means, it helps to know where the movement came from and why it matters.

    Where Did DevOps Come From?

    The rise of DevOps is rooted in the Agile Systems Admin and Enterprise Systems Management movements, as well as an effort by businesses to become more responsive to rapidly evolving markets and problems. Enterprise Systems Management attacked this problem by replacing large vendor solutions with faster, smaller and sometimes open-source tools, while at the same time, the Agile Systems Admin movement was gaining popularity in Europe as forward-thinking companies translated lean and agile manufacturing lessons to IT departments.

    The combination of these agile movements, the rise of SaaS and 24/7 service delivery, and examples like Flickr of excellence in developer-operations collaboration all helped prime the technical community for a change. After a talk by Flickr at the O’Reilly Velocity conference in 2009, highlighting challenges the company faced in continuous deployment and how they solved those problems with focused collaboration across the development and operations silos, Patrick Debois started organizing the first Devopsdays conference, and the name stuck. DevOps has been growing ever since, with conferences around the world, and has become synonymous with collaborative, agile, teams that ship quickly while maintaining high quality. This a very simplified account, of course— I recommend Richard Rapaport’s “A Short History of DevOps”, or Damon Edward’s video on the topic for a detailed history.

    And when you understand that history, it’s easier to understand why engineers bristle at the idea of DevOps as a job title or company role. By referring to and thinking about DevOps properly, you’ll not only make tech talent at your company happier, but will also help internalize DevOps principles within your organization.

    So, What Is DevOps, Then?

    Definitions vary according to who you ask, but The Agile Admin sums it up well:

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

    Put another way by the site, it’s “agile systems administration.” That means DevOps is about software developers and ops engineers working together with shared values, principles, methods, practices and tools to build, maintain and improve systems.  “Works on my box, ops’ problem now” has no place in this movement, and the entire technical organization takes responsibility — together — for delivering great quality and service to customers.

    Engineering organizations often think about problem-solving in terms of technical constraints: do we have enough server capacity? Enough bandwidth? Enough test coverage? But DevOps is also about engaging with the human side of shipping: do responsible teams have the right communication processes? How do we minimize error, and how do we effectively learn from mistakes without compromising morale? Patrick Dubois characterizes effective DevOps champions as “ambassadors, peace makers, facilitators and communicators,” who build bridges across the organization and rally teams around a common cause.

    Why Isn’t DevOps a Job Title?

    For many organizations that are moving to a DevOps model, it represents a fundamental culture shift, and the messaging around it is important.

    The definition above doesn’t fit on a business card. DevOps is not about software developers taking over the job of ops nor ops taking over the job of developers. And it’s not just about shared tools (though that is part of it). It’s about breaking down organizational silos, scaling and automating processes, and leveraging best practices from both the development and operations world to ship better stuff to customers.

    Good DevOps work requires testing, iterating and, even, breaking things. That needs to happen quickly, without friction and, most importantly, without blame. Defining someone as a “DevOps manager”or creating a “DevOps team” could imply that only those individuals are responsible for DevOps, and, should it fail, those failures are due to that individual or team rather than systemic organizational problems.

    As Chip Locke writes, software developers and operations engineers are often different types of people, and trying to combine them into a single role won’t always be effective. When devs and ops are forced into a contrived role instead of encouraged to collaborate across their individual teams, competing values and (sometimes) suboptimal results are the outcome. Additionally, implementing DevOps as a third team that sits between the development and operations teams is a recipe for disaster.

    You’re not in Kansas anymore

    As organizations have to ship faster, more complex software to an increasingly demanding and quickly changing market, the prevalence of devops will only grow— fluency in the movement will help you collaborate with, hire, and retain great engineers, while pigeonholing it can lose you credibility with your technical team that’s hard to get back.

    As the outsider, the onus is on you to educate yourself. Watch the presentations that birthed the movement, read some history, talk with those in the movement. To start you off, here are some of my favorite resources.

    A short history of DevOps

    10 Deploys Per Day: Dev and Ops Cooperation at Flickr

    What is this DevOps thing, anyway?

    The Agile Admin: What is DevOps?

  • Imperative or Declarative? The question of DevOps in the network.

    Imperative or Declarative? The question of DevOps in the network.

    A significant amount of bandwidth is spent discussing automation and praising the value of APIs within the broader DevOps umbrella. These concepts are particularly important in the context of CI/CD and the evolution of application architectures toward decoupled, service-oriented systems. Automation is used for build and test, to drive the workflow that moves an app from disconnected sets of services to a working release candidate ready to breach the wall of production and be put into the hands of adoring fans impatient consumers.

    But in between the consumers and your app stands the production pipeline; a process-filled wasteland through which an app must travel so that the appropriate services required to deliver it can be provisioned, configured and put into place. It is this pipeline that will meet DevOps head on next, whether we call it DevOps or SDN or SDDC. It stands in the way of an increasingly critical “time to market” metric by which all of IT is being measured. Research shows that the production pipeline is a major pain point for IT; taking weeks or even months to traverse. The network is still in the way, and that must be addressed if C-level concerns about meeting increasing pressure to get apps to market are to be met.

    Applying DevOps principles to the infrastructure and network makes sense as it’s as much about optimizing processes (workflow) as it is writing scripts and it is the production pipeline process that would benefit. Automation and orchestration, of course, will help drive a more consistent, efficient, and repeatable production pipeline traversal. Identifying where inefficiencies (latency) lies in the process and eliminating it by establishing more efficient (and perhaps automated) handoffs using automation and orchestration systems can go a long way toward shortening the amount of time between hand off to production and delivery to consumers.

    APIs are our “go to” technology today for driving automation, orchestration, and integration with the frameworks and systems we rely on to scale operations. Most every infrastructure and network device today has an API and can be controlled via frameworks like Puppet and Chef as well as directly using .

    But most are imperative methods of control. It requires processes to be strictly defined through a sequence of API calls. Unlike simpler resources like virtual machines, one does not simply need “start, stop, or pause.” Configuration that was once (and still is, let’s be honest) accomplished via CLI (command line interfaces) using SSH is simply migrating to an API using HTTP instead.

    But otherwise, not much has changed. The same commands used on the CLI are now sent via an API. We’re still in an imperative mode and if we need to tweak or adjust the configuration, we need to tweak and adjust the script that drives the configuration.

    Compare that now with a different approach: a declarative approach. Using templates to describe what needs to be configured or accomplished (data) as opposed to how it needs to be accomplished (commands) makes a significant difference in not only the process but in the long-term technical debt acquired (or not acquired, as the case may be). APIs change; methods deprecate, versions matter. Treating application services (load balancing, caching, optimization and acceleration, security) as “code” (templates) instead of a series of API calls can dramatically change the velocity with which such services can be provisioned and configured. This has the added effect of reducing the amount of churn in the automation code which should reduce technical debt as well. Such methods are also more portable, enabling easier migration into cloud environments for applications that might be (or will be) moved into or around different environments.

    Ultimately, the question is whether or not you want to tie your processes – and the interfaces between workflow steps in that process – to many API calls or a standardized set of API calls that leverage declarative policies (templates) to provision and configure the services that make up the production pipeline.

  • Where is the DBA in the DevOps conversation?

    Where is the DBA in the DevOps conversation?

    dbapicIn reading case studies, surveys, and research articles on DevOps I am reminded of a cartoon I saw taped to my high school physics teacher’s file cabinet. Two scientists stand in front of a complex proof scrawled on a chalkboard. Separating steps 1 and 3 of the proof is the statement, “Then a Miracle Occurs.” One of the scientists points to the statement and says, “I think you should be more explicit here in step 2.”

    This is an apt metaphor for the DevOps zeitgeist’s avoidance of the database. ISVs and analysts spend a lot of time talking about how to streamline, accelerate, and automate application development and testing (Step 1) and how to monitor and automate the deployment of those applications (Step 3). But when it comes to managing the database change necessary to support the application and its release processes, it seems that everyone is waiting for that miracle to occur.

    This oversight is unfortunate. DBAs have a lot to offer when it comes to correlating the development of technology with the management of the environment in which it’s hosted. In a sense, DBAs have been DevOps all along.

    On the ‘Dev’ side, DBAs carefully evaluate each change request to ensure that it is well thought out, is compliant with organizational best practices and won’t have unintended consequences on database performance or the validity of dependent objects. They have developed and tested all of the SQL that has materially changed the database and crafted it into what it is today.

    On the ‘Ops’ side, DBAs have designed and provisioned the data platform. They are in charge of monitoring their databases and keeping them available and high-performing. They manage access to and the overall security of the platform. They perform release activities in support of the application and troubleshoot any errors that happen during that process or during day to day operation.

    So why isn’t the larger DevOps community including the data platform in the conversation? Why aren’t DBAs a crucial part of every DevOps team? Why are we relying on a miracle like the scientist in the cartoon?

    Every decision a DBA makes, every process or standard they put in place is influenced by the dual nature of their role. They are used to thinking about the impact of any task, requirement, or problem from both sides. It is deeply ingrained in them. They are deliberate and meticulous in their approach to change management because they understand that what they do has impact beyond what’s directly in front of them. They rely heavily on their expertise and their deep understanding of their organization’s data strategy to ensure they are making safe, future proof decisions to the best of their ability.

    This also explains why we haven’t seen the same proliferation of automation and orchestration solutions for the database that we have seen for other domains in the SDLC. True database automation has to be more than “run this script after that one” or “make this object look like that object over there.” To have a meaningful impact on your release throughput and staff productivity your database automation has to make use of your team’s intelligence. Any solution you implement has to harness the collective experience and knowledge of your DBAs and apply that knowledge to the evaluation of changes as they’re introduced in development. It has to be…miraculous.

    This is the whole reason we started Datical. When it comes to completing your DevOps vision, we wanted Datical to provide a real answer to Step 2 from that comic that has stuck with me all these years. Our flagship product Datical DB was designed and implemented to address the unique challenges associated with automating database changes in support of application releases. It automates and accelerates the propagation of database changes without sacrificing safety. We provide a highly customizable automation framework that is fueled by your experts. It allows you to define standards specific to your organization that are incorporated in our pre-deployment analysis. This greatly reduces the time spent manually reviewing SQL and checking the logic of your SQL scripts for errors that will cause application failures and downtime.

    About the Author/ Pete Pickerill

    High-Res-Peter-Pickerill-6571-150x150Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. His ability to understand product demands from a customer’s perspective and translate those demands into actionable product and development plans has led to expanded duties at every company for which he’s worked. In his time at Symantec, Pete worked directly with large financial services companies and online retailers to implement and improve online fraud prevention solutions that were used daily by millions of people worldwide. In addition to managing a development team and product schedule at BMC, Pete worked directly with large financial services institutions to provide the features they needed to achieve greater efficiency and cost savings in their application deployment processes.

  • The DevOps-Price of Segregation of Duties.

    The DevOps-Price of Segregation of Duties.

    Segregation of duties will change because it must change. It has a tremendous impact on our motivation, time to market and IT Security. It influences many parts of an organization. Most organizations have started with DevOps, Continuous Delivery and Continuous Deployment and it is only natural to think about segregation of duties at one point and how we deal with it today. Today, it costs us a fortune that we’re not willing to pay in the near future. And why should we?

    (more…)