devopsy.kinsta.cloud

Tag: development

  • The Need for Rapid Development in a Post-App World

    The Need for Rapid Development in a Post-App World

    Gartner’s May 2017 report, “Preparing for a World Beyond Mobile Apps,” anticipates a post-app environment in which consumers have a wide variety of interfaces to choose from—including wearables, bots, ambient voice interfaces, IoT devices and AR/VR—that not only lend themselves to more immersive and seamless digital experiences, but also upend how businesses need to think about developing and delivering experiences. The post-app world, which we’ve begun to see accelerating in 2018, requires a major shift toward a rapid development framework at a time when agile methodologies are becoming overly costly and time-consuming.

    Examples of the types of experiences requiring rapid development often surface in highly competitive areas such as retail.  Examples include a luxury car dealer greeting customers with a large wall display with depth-sensing 3D camera, gesture-based interface and face recognition. As the customer gestures around the screen, an application recognizes his face, alerts the service manager that he’s there to pick up a car from repair, and harnesses his sales history and its loyalty program to make a special offer if appropriate.

    Then there are highly scalable opportunities to offer better capabilities while lowering costs such as chatbot technologies for interactions with vendors and suppliers and numerous HR functions. Retailers such as Gap, Target and Ralph Lauren have started incorporating digital augmented reality, interactive mirrors, beacons and other advanced interactive interfaces to enhance the physical shopping experience.

    Immersive experiences and physical/digital blending calls for a rapid development framework in which developer resources are utilized on infrastructure but not wasted building custom features that can be easily integrated via pre-built modules. This frees developer resources and allows lines of business to have more influence on the resulting experience.

    Rapid development also demands a unique mix of emerging strategies, tools and technologies to achieve the best immersive user experience fast:

    Design Thinking

    To paraphrase Steve Jobs, design thinking is not about how a device, software product or business process appears, but how it works. It requires thoroughly understanding and empathizing with the user’s needs and continually coming up creative ways to meet them, so the interaction is not only immersive but effortless. Design thinking must involve the user—whether customer or business—and must be a process of continuous exploration, prototyping, feedback, evaluation and optimization. Even then, innovation continues as needs change and evolve.

    The ultimate goal of leading with design is to keep the focus on ensuring a superior user experience.

    Microservices

    Microservice architectures allow teams to continually optimize individual components of a larger application without affecting others, thanks to loose coupling, REST and real-time APIs. Scores of application components may exist on-premises or in the cloud and can interact and pass data back and forth easily but each is limited to one or a few functions. Since changes and optimizations in one component don’t necessitate significant changes in the others, teams can optimize each function continually without having to re-engineer an entire application infrastructure. These components can also be shared with other applications if necessary.

    Agile Engineering

    Agile engineering is one component of rapid development, rather than the primary focus, and the goal should be improving the connection between the rapid process of design thinking and quickly evolving microservices and the challenges of software engineering. Even in an agile process the DevOps cadence required to deliver robust and secure software requires multiple sprints of two to four weeks in length. In successful projects, the majority of the layout and workflow falls onto the rapid development side. Then, the investment in additional time and resources is only required for the remaining elements that need an additional level of control and engineering rigor.  Agile engineering is the perfect partner for design thinking as it is designed around the ability to accept well specified requests into backlog and turn them around with high quality in the minimum number of cycles.

    The Way Forward

    Rapid development tools enable quick prototyping, deployment and easy continuous integration with existing systems. Intuitive editors and extensive libraries of application components and immersive interfaces such as VR, AR, personal assistants and IoT components enable developers, business users and designers to pull together prototypes of post-mobile components in hours or days. This allows quick feedback and evaluation at very low cost.

    Developers can then extend and customize the prototypes further via scripting so they become the actual production system. The best come tools with an ample supply of connectors and APIs to link with existing systems and run natively on many different mobile platforms, devices and displays. The right tools can accelerate innovation and cut costs dramatically.

    Radical digital transformation has arrived and organizations will have to adopt post-mobile technologies to compete. The right mix of tools and strategies will be key to redefining the enterprise development process from application-based to immersive-experience-based regardless of device, operating system or infrastructure.

    — David Brebner

  • DevOps Brings Value to Security (and Vice Versa)

    DevOps Brings Value to Security (and Vice Versa)

    Many enterprises today are implementing security solutions that can be deployed and maintained more quickly and easily, and at lower cost, using a DevOps methodology.

    Organizations applying DevOps to security are not looking at IT groups separately as the database team and the application team; rather they see everything as the delivery team. It’s also a team that works together that deliver security services for customers.

    Application, database, network and endpoint security have traditionally been segregated, and you can see how that is built into the tools. DevOps is about bringing these pieces together and integrating operations because it’s about implementing security starting at the top of the value chain—the customers. Ultimately, we look at the value we’re delivering for the customers with security and really making sure we are inserting it into the front of the pipeline. Leading DevOps shops integrate security upfront when building the next big product, feature or service for external or internal users.

    Related Content:

    DevSecOps: Putting Database Sec In DevOps

    DevOps Introduces Complexity. Really

    There are several different models of organizational structure used to insert security into the software development life cycle. Most make sure it is an integral part of everything that gets released. But the point is that it needs to be integrated. It needs to be a living part of everything an organization is doing.

    One effective choice is make sure DevOps engineers are focused on the standardization of the network and the application.

    For example, look at locks. Most of the time, developers are keeping all passwords in locks. As a DevOps team, we’re sharing locks. That means that all credentials, even credit card information, can be exposed. Before we release the features, we need to think about security and remove passwords and credit card details.
    [su_pullquote align=”right”]Security needs to be a living part of everything an organization is doing.[/su_pullquote]
    When we look at the network and the database side, we need to disable all ports, and this is important to do before releasing things. Disable all the network ports and bring all the databases into these, and open only relevant ports.

    If you are going to embed security, it’s actually cheaper, more efficient and faster to do it in the DevOps team; otherwise, you have to train engineers in application, database or network teams on security or add an expert into those teams. But, if you add the security expert into the DevOps team, you could involve fewer people or simply additional people who are cross-trained.

    When we talk about cost savings and cost reduction with our clients, we focus on two things. We look at the model that shows how the cost of finding defects goes up as the product is developed. If you can include quality from the beginning, you reduce cost of maintenance and cost of quality—that’s the first thing. The same is absolutely true of security—that’s the second thing.

    When you’ve got an integrated SRE full-stack engineer working hand in hand with the development team, they’re thinking security, operational agility and maintainability of the system from the get-go, and they’re inserting those non-functional requirements and making sure they’re adhered to across the stack.

    This method is not at the exclusion of having the application team run code tools on security on their applications. Rather, it is someone who is looking at all these pieces and making sure they’re being done correctly.

    Ultimately, we’re producing a product that is not only functional, but actually operable in an efficient and effective way. It can’t break every minute, causing us to spend millions just to keep the darn thing alive. It works the same way with security.

    Even if it’s operable, if we get hacked, the company has a massive data breach liability.

    By having skilled engineers on the front line—particularly skilled DevOps engineers on the front line—you’ve got folks who are thinking in that full-stack mode about the security implications of the system’s operation and any issues they may see, making them more able to identify things that are potential threats.

    — Sean Mack

  • Accommodating Different Processes in Enterprise Software Delivery

    Accommodating Different Processes in Enterprise Software Delivery

    When an organization takes on a new initiative, it typically develops a procedure to optimize execution and limit blowback from the transition. Whether it’s the introduction of new processes, personnel, structures or technologies, there are a number of established ways—often gleaned from experience—to support the individual, the team and the wider organization.

    That said, while this procedure may work for one department or team in a certain discipline—say, when marketing invests in a new marketing automation tool—what if the initiative impacts multiple teams, processes, structures and technologies, as it does with enterprise software delivery? A standardized procedure won’t work; there are just too many variables to consider.

    And as organizations continue to provide digital services and products for their discerning customers, the number of variables will only increase as enterprises look to ramp up their software delivery to gain a competitive edge in a digital world. How do you manage all this change?

    Moreover, what if this change disrupts some of your best teams, many of whom who are fiercely protective of their own unique processes? Much time and thought has been committed to hone a process that is right for them. Who are you to tell them to pull up the floorboards and start again? Sure, the wider organization may want everyone operating from within one end-to-end system, but that’s just not how software delivery works. Nor, for that matter, is it how practitioners think.

    You Can’t Please Everyone — or Can You?

    Very rarely do practitioners look beyond their core function and specialism, unless it truly impacts their job. For instance, developers want clear requirements to write accurate code that is tested, validated and out the door. They have to write and maintain reams of code, meaning they have little time to think about the rest of the value stream. Typically, if you’re not a business analyst, tester or in ops, then you’re unlikely to be on their radar. They certainly won’t welcome any interruption or change to the way they operate from someone “outside” their world.

    This dilemma is exactly why organizations need to think long and hard about how they deal with these differences within software delivery value stream. Not only can practitioners be hostile and resistant to change, but it’s extremely complicated to deconstruct or adjust these processes. They’re highly detailed in practice (although rarely documented due to the frequency with which they’re modified!), covering:

    • Work items to utilize/prioritize
    • How backlog items vs. issues are represented on their backlogs
    • How items flow through day-to-day processes
    • Whether they use Scrum and/or Kanban
    • The required information that developers need to submit to management level
    • The person responsible for submitting certain elements of the management report

    When Standardization Isn’t Enough — How to Accommodate the Cowboys

    While standardization is possible (and preferred) across organizations, e.g., ITSM for managing multiple systems for multiple functions from one centralized point of control, unifying teams across the software value stream isn’t so simple. There always will be one or two rogue teams that will reject any new process because they know better and only want to do things their tried-and-tested way. We call these teams “cowboy teams.”

    Cowboy teams, while problematic, are a force for good as they can be leaders in experimentation and innovation: Consider Alan Turing and his “Enigma” team. Nor are these teams stubborn sticks in the mud. Often it just boils down to the fact that introducing a new process comes with a lot of baggage that people are naturally going to want to avoid, including:

    • Financial cost (new tools, staff and accompanying training)
    • Time cost (training etc.)
    • Reduced productivity during implementation period
    • No guarantee of success
    • Potential of negative impact on function
    • Detrimental influence on employee satisfaction
    • Unforeseen complications and conflicts such as mismatch with tools used by the team

    Last but not least, haphazardly introducing a new process can undermine your software delivery value stream. We know that large-scale software development and delivery requires all teams, tools and disciplines within the value stream to be connected for end-to-end visibility, traceability and governance over the whole process.

    And in an ideal world, the process would be underpinned by a single cohesive system. But in reality, this is not the case. Teams work in silos because their purpose-built tools aren’t connected to other stages in the value stream since these tools are unable to automatically flow information between systems. Not only does this state foster siloed thinking, but there always will be one or more teams that will resist any wholesale change to their way of working, even if they’re told it will help the organization meet its business objectives.

    Fortunately, there’s a way to unify and connect your value stream while simultaneously accommodating these cowboy teams, and that’s a modular tool chain.

    Modularity — The Backbone of Autonomous Teams Functioning Within the Bigger Picture

    The software delivery process isn’t a conventional manufacturing process. It’s more like a network of thousands of people with different functions, tools and processes that work on different components of the same project at the same time. And these components simply must communicate in real time to share collaborative data. Supporting such a system is complex, because all the best-of-breed tools for planning, building and delivering software do not naturally integrate—there’s no interconnection, the lifeblood of any network.

    However, you can connect these tools via model-based integration through a modular value stream; i.e., not point-to-point integration, but an adaptable, integrated network that communicates through a model in the center of this complex universe. Not only does this account for all different tools, teams, disciplines and processes, but this paradigm enables organizations to plug new elements in and out without disrupting the all-important flow of information across the value stream.

    This means any information that is shared throughout the value stream is done so in a normalized format—a common language, if you will—that allows teams to operate in their preferred tool and methodology. For example, if your management wants to know the number of tickets/defects submitted per program during each release, they don’t want to know there were 10 “high priority” ones from one team and 15 “important” from the other team. If “high” and “important” mean the same thing, priorities should be normalized and reported back to the management in a standardized fashion.

    Thanks to the automated flow of information into a language everyone understands, the whole value stream, even the cowboys, are on the same page without the need for laborious time-consuming manual forms of communication, such as email threads, status meetings, phone calls, spreadsheets and duplicate data entry. Not only does this improve the working conditions for practitioners, enhancing employee engagement, but it also can save up to $10 million a year in productivity-related savings.

    So, the choices for organizations are either to:

    1. Force all teams to use the same system, creating a litany of individual, team and organizational problems due to disruption, or
    2. Use a modular value stream method that maps each team to the standardized model, while at the same time allowing teams to continue working in their preferred system using their carefully devised processes.

    Change is constant, inevitable and vital for progression and innovation. At the same time, change can be a threat to those important parts of your business model that are working and delivering business value. With value stream integration, you can have the best of both worlds: Your pioneering cowboys can continue to work in the ways that make them happy and productive, while the rest of the stream can continue to collaborate, evolve and adjust to the fast-paced digital landscape.

    About the Author / Mara Puisite

    Mara Puisite is a Pre-Sales Engineer at Tasktop, bringing with her years of industry and technical experience. Prior to her current role, Mara worked as a Product Manager running Tasktop’s connector program and managing the development and maintenance of 50+ integration systems. Today, she helps companies solve various bottlenecks in their software development and delivery process through the power of value stream integration. Connect with her on LinkedIn.

  • DevOps in the Age of Digital Transformation

    DevOps in the Age of Digital Transformation

    Digital transformation is one of the hottest buzzwords in the technology industry today. While it tends to be overused, the term does represent a widespread, ongoing movement that will set a standard for the next generation of enterprises.

    Digital transformation is all about keeping up with the pace of innovation and using technology to achieve business goals. A key differentiator in the age of digital transformation is customer experience. Consumers are increasingly engaging with brands on digital platforms, whether it be a website, social media profile or mobile app. The foundation of all these platforms is, of course, software.

    Agile software delivery is key because it helps organizations innovate faster and gets new software in the hands of consumers sooner. This requires new, more productive ways of working for enterprise IT teams. Development teams have already undergone several “transformations” in recent years, from the siloed waterfall approach to agile methodology and now DevOps. Software is the true differentiator in the age of digital transformation, and many companies are using DevOps to ensure their software meets the standard.

    Here are a few best practices for using DevOps to keep up with the pace of digital transformation:

    • Automate wherever possible. We no longer collect the work of multiple engineers over multiple sprints into a release. To out-innovate the competition in the digital transformation era, a team must release the work of a single engineer as soon as it is ready. This is usually accomplished through a CI/CD pipeline directly from the source repository through automated testing and then deployment into production, preferably without any human intervention. Choosing the right tools for your IT environment will cut costs, time and room for error.
    • Align the goals of development and security. DevOps isn’t limited to just the development and operations teams. Without security, all progress made in the digital transformation era is at risk to cybercriminals. The accelerating software development life cycle means little time for security analysis or penetration testing when the release candidate is ready to deploy. To ensure a piece of software is secure before pushing it to market, security standards must be included in the definition of “done.” Preventative scanning will not only train developers to write secure code, but will allow the software to pass the assurance tests included in any good CI/CD pipeline.
    • Measure ROI. Measuring the impact of DevOps can be extremely difficult and up to interpretation because of the focus on culture and processes. However, it’s important for DevOps teams to gain continued executive buy-in and dedicated resources by proving their value. The value of DevOps is determined in terms of achieving improved business outcomes. There are specific questions to ask to help determine ROI: How long does it take to release a code change? How long does it take for a product to reach a customer’s hands? The ability to continually deliver quality software faster results in a positive customer experience, ultimately improving brand reputation and revenue.

    While keeping up with the competition is necessary in the digital transformation era, putting customer experience first is how the true leaders succeed. By shortening the software development cycle, DevOps speeds the pace of innovation for an organization and helps earn customer trust and retention. Implementing these best practices can help a business use DevOps to place software and customer engagement at the heart of its digital transformation.

    — Pete Chestna

  • Building a Services and IoT Platform with DevOps, Part 3

    Building a Services and IoT Platform with DevOps, Part 3

    Business needs and IoT demands are taking new dimensions in connecting millions of devices, people, process, tools and systems. With endless possibilities of creating new IoT solutions, DevOps teams are the key players who handle the challenges in successfully rolling out a IoT solution while handling the business, development, operations and infrastructure demands in the background. This article focuses on some of the DevOps best practices to adopt during IoT development, enabling faster time to market.

    DevOps practices to adopt during IoT development

    1. Adopt Security by design – Teams need to be educated and made aware of security threats. Use threat models mitigation techniques such as using authentication; storing secrets separately and protecting those secrets; using tamper-resistant protocols, digital signatures, timestamps, audit trails, encryption, authorization policies, filtering; and running services with least privileges during security design and development.
    2. Shift left security analysis and security testing – Integrate security analysis tools, customize security compliance rules and run security testing as part of continuous integration pipeline, generate security threat reports on vulnerabilities and act on these threat reports to fix issues early in the development phase and minimize the security risks.
    3. Follow security standards during development such as security development life cycle (SDL), which has guidelines and measures for building the software for devices and application components of IoT platform.
    4. Perform code reviews for device software, application software, PaaS rules and configurations, as quality assurance can become a huge risk given the complexity of the infrastructure, millions of devices connecting and dynamic environment configurations. Code review tools need to be integrated to the CI pipeline with pull request code review.
    5. Use the right branching policies in a version control repository, including precommit/preflight builds, pull requests for merging the code changes and access control for maintaining branches and using the right branching strategies, as there will be multiple fragmented development and deployment pipelines for devices and application developments to reduce the overhead. Use distributed repository/central repository with traceability and auditability based on the requirements.
    6. Automate deployments and create deployment pipelines for device development, application development, infra-automation scripts development with build and deployment pipelines targeting for different target endpoints.
    7. Customize the builds and release pipelines to pull the packages from multiple build and deployment pipelines to integrate and deploy as units of deployment.
    8. Plan for frequent release cadences—say, monthly—for application rollouts. Release cadences for firmware update rollouts can be planned for three to six months, as device updates cannot be pushed so often.
    9. Continuously monitor deployments – Use a release management tool for orchestrating the releases and release coordination activities, with gated checks and approvals with a view of what is getting deployed to each environment, as well as traceability and audit.
    10. Enable feedback loops and automated alerts if firmware deployments or application updates fail.
    11. DevOps teams can define key tenets, criteria to be met and standards to be followed for the devices; infrastructure to be provisioned; device protocols usage and standards in connecting to existing/new devices and services. This can reduce the complexity in development and deploying to multiple varied devices by following the same protocols for connectivity and communication.
    12. Train the team of developers, QA and hardware developers on how to do continuous integration for IoT development, follow agile and lean practices and ensure security criteria for all layers of the application and in process.
    13. Adopt user-centric test automation and end-to-end testing approaches and build robust test cases in perspective of testing a complete flow, with devices/services that may not be in your scope but will be part of your overall IoT platform ecosystem.
    14. Create/utilize container based test environments and device simulators coupled with service virtualization for functional testing.
    15. Automated infrastructure provisioning – Use the right configuration management tools to automate the infrastructure along with dependencies to create environments through code instead of provisioning basic VMs.
    16. Use container and cluster management tools such as Docker Swarm or Kubernetes for service discovery, auto-scaling, self-healing and scheduling.
    17. Use RBAC, service accounts and security access controls in the infrastructure templates/scripts that are created instead of individual user credentials to limit the risk of unauthorized users provisioning the environments using scripts. Build security in devices, cloud security, application security and infrastructure automation templates. Use secrets, key vaults, encryption methods and certificates to secure the credentials and access control.
    18. Configure individual build and deployment pipeline jobs for application development and infra-automation development, as there will be a huge development effort involved in automating the infrastructure.
    19. Create infrastructure verification tests with scripting tools such as Python or use testing frameworks such as Pester or any other open-source tools and integrate the infrastructure tests with the CI/CD pipeline. Ensure to run these tests every time the infrastructure is provisioned.
    20. Version-control the infrastructure templates, scripts, user profiles, environment configurations and device configurations apart from source code.
    21. Set up a centralized dashboard of monitoring tools to monitor the clusters, nodes, firewall rules, VMs, applications, devices and services. Feedback should flow back to developers/QA/DevOps teams.
    22. Configure applications to provide logging about exceptions, memory leakages and response times and push the logs to the monitoring tools or the dashboards in monitoring tools.
    23. Use the telemetry from the applications and devices to derive the analytics graphs/trends and set up KPIs/metrics to measure application performance/availability, as well from derive business metrics to set SLAs for DevOps and operations, to improve productivity.
    24. Ensure DevOps teams have close coordination with dev/QA teams of both software and hardware teams, as managing IoT platforms need more skill and expertise in hardware and software in the IoT domain.
    25. Manage legacy and cloud infrastructure with multicloud management platforms, and monitor and optimize the infrastructure usage.
    26. Create a DevOps governance plan/guide, with clearly defined access control policies, access rights for devices, control limits on infrastructure provisioning in different clouds, limits on PaaS/IaaS services to be used, etc., and standardize the process to be followed in DevOps/development/testing/operations, tools, etc.

    Following DevOps practices for application development has become quite streamlined in recent years. However, in IoT, where traditional methodologies and practices are followed in industrial enterprises, adapting to agile methodologies and following DevOps practices coupled with right DevOps-skilled team, tools and expertise can streamline and simplify IoT developments.

    About the Author / Lavanya Subbarayalu

    Lavanya Subbarayalu is Senior Architect working with Technology Office in HCL Technologies. She has expertise in IOT, Azure, DevOps consulting & Microsoft technologies. She is associated with DevOps COE, working on design and Development of DevOps solutions and consulting tools. Connect with her on LinkedIn.

  • Event Management: Let the Noise Wail Without Going Deaf

    Event Management: Let the Noise Wail Without Going Deaf

    In part 1 of the blog series “Putting the Ops in DevOps,” by James Moore, we discussed the awareness and anticipation of operational management and the best practices that can improve the app at every stage of its life cycle. In this blog, I would like to cover one of the event management discipline maturity and share some best practices.

    If you are an operations professional on a team that’s beginning to embrace DevOps methodologies, you probably are facing some significant challenges.

    You know the business is applying pressure to get to continuous integrations/delivery, where release cycles can be measured by value delivered in days or even hours rather than weeks or months. Your Dev teams have embraced agile development, and are producing (what should be) production-ready code in short iterations. Your combined orgs are working toward implementing an integrated delivery toolchain that can build, test and deploy a new release version at the touch of a button. Your Dev teams are leveraging cloud technologies and architectural patterns that enhance their agility, auto-scaling microservice architectures of unprecedented scale and modularity. They are producing, as a matter of best practice, highly instrumented code that provides a dense trail of data relating to the state of the applications deployed on runtimes that constantly report their own state. You may be responsible for physical and virtual compute, network and storage infrastructure that itself is monitored with tools that spew a continuous stream of state information.

    In other words, you find yourself faced with continuous change (both automatic and human driven) and a barrage of potential noise. If you are a seasoned operations professional, bitter experience may have lead you to see change as the enemy—as change tends to zero, then so does operational risk. Now, you may to have to deal with continuous change as an inevitable force for advancing your company’s business goals. How will you separate the signal of service status from the noise of service state? Doing this successfully will be the difference between knowing quickly that there is a problem with an application or service before your users notice and being told about it by your users. It may also be the difference between getting a good night sleep and unnecessarily responding to a page indicating a benign application state.

    Enter event and incident management. The discipline of event management has matured, and has continued to mature, over decades as a mechanism for determining the status of elements of a managed environment from the state. Best practice in event management consists of:

    • Filtering out events that are not likely to be service affecting. A trace message from an app log is not worth your attention, unless you need to view it as a part of a diagnostic procedure. A synthetic user transaction timeout may require immediate investigation.
    • Correlating events that are likely to be related, so you get one notification per true incident rather than, say, 20.
    • Enriching events with context, so if a single service instance fails in a redundant array of five instances, route the event to the operations console but don’t wake anyone up unless the service is affected.
    • Implementing X-in-Y policies. In a large and complex system, a single microservice-to-microservice HTTP timeout may not be a huge problem. But you may want to investigate if you start getting 20 per second.
    • Implementing runbooks for common failures. Collaborate with development on the definition of those runbooks. Tie those runbooks to incidents as they occur so that the first responder has a process they can reinstate a service or prevent an outage in the first place.
    • If possible, automating those runbooks. If the problem is a failed process, then restart it. A disk is full? Free up some space.
    • Leveraging analytics and machine learning to gain insights from the reams of data your tool collects. Can you learn from event history to suggest correlations or areas for improvement to ops efficiency?

    With rapid delivery of new features and capabilities, the Dev team should already be mindful of the operability of the software they produce. Shift awareness of the event management tools and logic to the left. Have development use the same management tools that Ops use in production, but in pre-production. And then learn from what they see in pre-prod to improve. This should be done in combination with systems failure testing. Perform the test and see how the operations tools responds. Ask yourself, “Would I have been able to fix this if it had happened in production? Would I even have known what to do?”

    As is obvious by now, successfully operating an application or service in a modern business requires unprecedented co-operation between development and operations teams. Event management as a discipline and the tools that support that discipline are as critical now as they have ever been, if not more so.

    Listen to my recent podcast where I spoke about the common operational challenges many DevOps teams are facing today and how the traditional IT Operations best practices could be leveraged for use in a DevOps methodology.

    Also, download this white paper, which includes best practices for DevOps transformation and improving event or incident management.

     

    About the Author / Dr. Kristian J. Stewart

    Kristian Stewart is Architect – Hybrid Cloud Event Management and Analytics at IBM. He currently leads architecture for IBM’s Netcool Event Management offering, and is part of the team providing as-a-service capabilities to IBM’s clients with Cloud Event Management. He has worked in Systems and Service Management for 18 years. He lives in England with his wife and two daughters, two cats, and five Raspberry Pis.

  • The Future of Continuous Testing: Fail Faster

    The Future of Continuous Testing: Fail Faster

    In the early days of Agile and Lean development practices, a very noticeable gap appeared between dev teams and ops and QA. Development was accelerating at a lightning-fast pace, but testing processes could not keep up, slowing down the entire life cycle and preventing organizations from achieving continuous delivery. Traditional testing methods, which rely heavily on manual processes and frequently updated GUI tests, proved too cumbersome and inadequate for our new lifecycle timelines.

    The era of testing as an afterthought is dying out, and continuous testing has emerged as the new standard. The idea behind continuous testing is pretty straightforward: Implement a systematic approach towards improvement that incorporates not only automation, but also all of the other tools and processes that will help reduce risk before software progresses to release and production. Organizations embracing this are rethinking testing as a continuous process that starts from the sandbox, rather than a precursor to release.

    Continuous Testing: Achieving ‘Fail Faster’

    At xMatters, we strive to a testing strategy that supports our goal of committing to production multiple times per day—one that we’ve been diligently moving closer to, having progressed from releases every quarter to every month to every week to now, twice per week. Our approach is to conduct unit tests at the team level, code quality, sonar and static analysis, and then deploy to production at limited percentages that we bump up in stages. Our overarching mantra is “fail fast,” because the faster and sooner you fail, the faster and sooner you can fix what’s broken, and the less resources and time you will spend troubleshooting and resolving issues. This, of course, translates to real cost savings.

    Correlating failure to actual events is the biggest hindrance to the continuous testing dream, as pinpointing root causes is an incredibly time-consuming process. This is where automation will take us to the next level, if implemented in a smart way. The future of continuous testing will be adaptive so as to determine the causes of failures faster. We need to automate as much as possible the process of predicting where code quality issues are and identifying the precise data correlations that will enable us to fix issues rapidly.

    Part of this adaptive testing approach will include automating intelligent regression testing. We don’t need to run a black box test in every instance, for example, which can take hours every time. We’ll save incredible amounts of time, money and developer resources if we design tests that can detect new changes and only test those. Smarter regression testing will result in precious time saved that ultimately impacts—and can even make or break—the speed of innovation.

    Another critical consideration to smarter testing is making sure to account for a comprehensive understanding of risk. We need to incorporate real business considerations into our understanding of risk and bake those into our tests as well. We should hold our software to not only standards of code quality and integration success, but also to meet real business expectations for areas such as security, compliance and reliability. Testing from the bottom up must be done in tandem with top-down analysis to account for the full spectrum of potential risks that have the potential to impact the bottom line. Machine learning systems can also be extended to learn new business applications as new functionalities are added and assist in creating test cases that serve to enhance the quality of the application.

    Developing these intelligent automation tools remains our biggest barrier to achieving the continuous testing dream, and while many organizations are gunning for it, most are still mired by manual processes. A global study conducted earlier this year by CA Technologies, for instance, demonstrated that while 75 percent of organizations identify continuous testing as important, just 20 percent report a high quality of test automation coverage.

    It’s worth noting that not every aspect of testing can be successfully automated. The vast majority of functional tests will almost certainly not be manual processes—but what about user experience testing? We have yet to conceive of an approach to this that can truly be automated. Because nothing beats a real human’s assessment of experiential quality, this will be one of the areas of testing that will likely remain manual. Thus, while our goal is to automate 100 percent, realistically this won’t be the case.

    The end goal here is not only to achieve the dream of continuous delivery, but also to eliminate distractions as much as possible. The more repeatable processes you can automate, the fewer distractions your team will encounter, and the more they can focus on creativity, strategy and building new features and capabilities instead of fixing old ones. This is what will ultimately determine your ability to innovate, as you’ll no longer have to sacrifice either time, scope or quality.

    About the Author / Deepa Guna

    Deepa Guna is Senior QA Architect for xMatters. She has been working in technology since 2003. Connect with her on LinkedIn.

  • SMEs Can Benefit from DevOps, Too

    SMEs Can Benefit from DevOps, Too

    The DevOps approach has several clear-cut benefits with the value centered in several key business areas: improved market agility, increased quality and revised culture of cooperation and effectiveness in staff operations. By promoting and implementing a DevOps culture in your SME’s business, Dev and Ops teams align much closer together and can better share in-between knowledge. This lets you create products more fluidly and increase deployment rates. The time for evaluating the business idea, development, testing and moving the finished product into the operations department is reduced dramatically. Quality margins improve, and this feeds back into the ability of your teams to continually fine-tune the products you offer.

    Businesses see a point in adopting DevOps only if it is directly contributing to the company’s increased effectiveness, productivity and, of course, profitability. The only way that it is possible for small and medium enterprises (SMEs) is when their IT and DevOps teams are working in sync and streamlining the provision of tech solutions that solve the business needs. And only a successful and timely DevOps adoption inside your organization will help your company beat competitors and stay afloat as the development across the industry speeds up.

    In the last years, we’ve seen a tremendous application delivery shift in businesses. We’ve moved away from the old ways of having large-scale system implementations based on one single project and its continued maintenance. SMEs now perceive application delivery as a continuous evolution. DevOps plays a leading role, as this software engineering trend ensures that such a major shift is possible. It brings all of the different parts of the enterprise together: business, development and operations teams collaborate on a different, more in-depth level with a goal of automating processes. This helps eliminate the usual constraints and takes the time-to-market issues off the table.

    In the latest ECS-Digital research on adopting DevOps in businesses, 57 percent of SMEs have partially implemented DevOps practices in their daily routine. The key benefit of DevOps for them is improved inter-departmental collaboration. But for the 43 percent that haven’t yet adopted DevOps, the collaboration issues are among the last priorities on the list.

    Step-by-Step Guide to a High-Level DevOps Life Cycle

    According to IBM Cloud Director, the end goal of a relevant DevOps practice is to cut the development time and improve enterprise’s efficiency. A growing business has to start from the “business needs” of the company and go down the road to make it come to life. The goal of adopting DevOps in your company is to push your business needs into production at a quicker pace more reliably. The goal in any DevOps practice is to cut the time and increase the efficiency of processes. You need to move from the “business need” to the “it’s live!” stage.

    Business Needs are a DevOps Priority

    But does your business have to get involved? Of course, your SME leadership focuses on the “business needs” of your company. But when we look at organizations that have implemented proper DevOps practices, the internal structure of the company shifts to focus on delivering great business results across the whole life cycle of your product/services offering.

    DevOps also ensures that employees have the ability to correct their work direction during the whole lifetime of a project. Things and goals tend to change, competitors may roll out some features that may make some of your project’s parts trivial, and all of this makes the need to adjust your project accordingly. This is easily done when your business need is close to both the Development and Operations teams that are able to steer and drive this alignment of goals.

    Have a look at the infographic below that clearly shows how a DevOps delivery cycle looks like:

    The Clash Inside Organizations

    Measuring the impact of DevOps on the things that matter to business is vital. Most SMEs are experimenting with DevOps, and there are some within the company who want to prevent DevOps adoption. The culture within enterprises is shifting too drastically and dramatically, although the effects are mostly positive.

    Such a shift is impacting all operations, with software development impacted the most. SMEs have it easier to change and adapt compared to larger businesses, and this lets them move the workplace culture a step ahead of their larger counterparts.

    If we look at business, operations and developer teams from a historical point of view, it was never a goal to establish inter-connection between them. The teams started cooperating only when it was absolutely necessary to get the other team’s input. SMEs are still faced with such a separation, as most responsibilities are set in stone for each team and the individual employee. All business units are used to working in their closed-in niche, and there is a lack of will to leave the comfort zone and act outside the predefined roles. Such actions in the past could have been viewed negatively.

    While most businesses that want to implement DevOps have employees who want the business to prosper, it can be difficult to force people to act outside their duties. However, to reach the end goals of any business—namely, ensuring fast and quality product delivery—and solve issues on the go, people must interconnect their duties and reach outside their business unit. With proper DevOps application, such collaboration can be smooth and result in the improvement of cross-functions.

    DevOps Represents Change in Internal Business Structures

    Many SMEs are faced with internal structural issues that limit the company’s prospects: Engineers are not willing to be on-call, the Ops team has a negative attitude toward those who write code and executives are slow to embrace automation. Organizations must overcome the culture war to be able to approach the agility and productivity gained by a DevOps model. The faster they can get there, the faster these organizations can take the competitive edge away from traditional enterprises.

    DevOps culture looks very different from organization to organization. However, regardless of the business implementing a DevOps approach, the potential benefits are the same. From faster deployments to increased efficiency and cultural changes toward experimentation and away from rigid planning, a DevOps culture has the ability to transform an organization completely. Wholeheartedly adopting a DevOps culture has real implications on how well a business is positioned to take on the market. With many industries facing uncertainty and a host of upstarts disrupting the status quo, shifting to a DevOps culture can be an important weapon in repositioning your business.

    Empathy is the Core of DevOps Adoption

    One of the foundational ideas behind DevOps is mutual empathy. Having empathy from operations toward developers and vice versa, as well as empathy in other business-related and non-technical company units, remains vital. It’s not about patting your colleague on a shoulder. We are talking about the moral mandate of a developer who just creates their part of the software and doesn’t care about how it can be deployed in production. The goal is to push employees to think outside of their small task, and to take into account the outcome of their work: Is the developed app secure? How hard is it to deploy it? Is it easy to keep it running? etc. If those questions are not accounted for, the developer’s colleagues on the Ops side will pay the price if something goes wrong past the release.

    By ensuring that the SME has empathy for each other at its core, businesses will deliver better products/services. And doing just that is what DevOps aims to bring to companies. Until this idea is ingrained, DevOps will face a cultural war of sorts.

    Your Most Valuable DevOps Resource

    By considering to adopt the DevOps approach to running your SME, you can better rethink the ways your organization operates—how it deploys its teams across the enterprise and how often it addresses structural problems that appear over time. Now you can lay out a new foundation for your SME based on the culture of cooperation and experimentation. With proper guidance in the application of DevOps culture, you can address the waste of time, human resources and money in your business.

    Becoming a DevOps organization is no easy task and taking up on such a challenge requires faith that changing the existing processes will bring its benefits. Reworking and optimizing organizations is the new norm, regardless of their size, industry, and goals. The faith in DevOps culture is driven by the firm and quantifiable statistics, but the intangible benefits to corporate culture are just as compelling. Many businesses are looking at implementing DevOps, and even more, SMEs are in the active process of its application. When your company is delivering quality ahead of time, there is a strong chance your competitors will be left behind as you are getting the bigger piece of the pie.

    Key Takeaways

    • To stay current, businesses need to adapt to an ever-changing environment, respond to competitors and stay on top of the innovation cycle, increasing customer value via responsiveness to change.
    • Increased service quality depends on both the availability of the service and being able to restore the service to an error-free state. Thanks to fast feedback loops and high release velocity, service breakdowns can be removed much more quickly than in the past.
    • DevOps are built on the sound principle of waste reduction such wait times and process overhead due to continuous improvement. This helps to improve agility and has a positive impact on costs.
    • Fostering continuous learning and improving culture through efficient principles is what DevOps is all about. In a fast-paced, unpredictable environment, non-stop improvement is paramount for sustaining your competitive advantage. It is also important for attracting exceptional talent and keeping employee satisfaction at a high level.

    About the Author / Stephan Pushkarev

    Stepan Pushkarev is the Head of DevOps Practice at Squadex.com and CTO at Hydrosphere.io. Co-founded and managed engineering teams for eCommerce, IoT and Ad-tech companies. He is responsible for the full products stack: math models, infrastructure & operations, enterprise applications as well as recruiting, establishing engineering culture and delivery processes. Stepan combines strong technical and managerial skills, and entrepreneurial spirit. Connect with him on LinkedIn.

  • How an Integrated Tool System Helps Implement DevOps

    How an Integrated Tool System Helps Implement DevOps

     DevOps is the marriage of application development teams with system operations teams, their philosophies and actions.

    In an agile environment, development, testing and operations all must work together to meet frequent iterations, releases and delivery goals. This calls for a collaborative development environment that supports data orchestration with other lifecycle tools.

    The article will explain how multitool integration support can help organizations perform the DevOps life cycle, which includes continuous planning, continuous integration, continuous testing, continuous monitoring, continuous delivery and continuous feedback mechanism.

    The Drivers of DevOps

    Today, with the increasing competition and the need for an early market release, the software development industry is undergoing a paradigm shift. Agility has become an inevitable process across all organizations. In addition, shorter ROI cycle spans, frequent releases, increased CRs and different IT systems and tool technologies have made the situation critical.

    The industry demands higher transparency, maximum visibility, minimum turn-around time, lesser human intervention and efficient processes at every stage, from development to delivery.

    However, organizations that use specialized tools to manage builds, deployments and delivery processes continue to face difficulties when it comes to data orchestration and process automation across the tool chain.

    In an agile environment, developers and testers need to ensure not only that code changes work and integrate well, but also  that frequent iterations do not make the product unstable. Hence, seamless cross-tool collaboration is very important here.

    The process chain consisting of Code –> Build –> Provision –> Test –> Defect Fix –> Deploy –> Release needs to run continuously and smoothly without compromising delivery deadlines or the product quality.

    Automation is the Catch Line

    With the rising demand for continuous delivery and sprint-based development, manually setting up a test, build and deployment environment is burdensome and time-consuming.

    Software teams need to automate the entire cycle of build, provisioning and deployment of test environments, including the tools, scripts and test data to ensure rapid delivery. They also need to collaborate around the application architecture and monitor event-action-based mechanism for seamless data flow across the tool chains.

    Reports show the most important DevOps components are IT automation, agile development and collaborative teaming of personnel. Therefore, without centralized orchestration of tools, achieving DevOps is not a realistic situation. Since organizations spend around 73 percent of their DevOps budget in tool acquisition, it is important they know how to get the tools working together to overcome DevOps obstacles.

    In the process of connecting their existing and new toolsets, most organizations search for an integration methodology that is scalable, reliable and easy to maintain. Point-to-point integration between tools help, but to a limited extent. Even a single change in integration rules involves complex coding and high maintenance across development, test and deployment cycles.

    How ESB-based Integration Can Help

    An enterprise service bus (ESB)-architected integration hub connects both the existing and the new tools to support a seamless data flow between them across the DevOps life cycle.

    Once integrated, the data from both the development and the operations tools become readily available for use to every stakeholder. The benefit of using ESB-based integration is that you can add or remove any tool based on your connectivity requirements.

    In a typical scenario, DevOps teams use a series of cross-functional tools starting from project planning to delivery and operations. Neither of these tools comes with built-in integration features, which results in inconsistent flow of information among tool users.

    Project managers use application lifecycle management (ALM) or Agile planning tools to detail the scope of work and tracking progress reports. Upon unit testing, developers use a different tool to check in a code from their integrated development environment (IDE) to the source code management (SCM) repository. They also perform a code quality analysis before committing to the SCM.

    In such a scenario, continuous integration (CI) can be achieved only when developers bring these planning, unit testing, code analysis and SCM tools under one roof. That is, connecting the tools through a common integration hub. It also helps developers to manage everything from within the IDE.

    After successful check-ins, build engineers trigger the SCM tools for automated build and testing. Upon a successful build, testers engage in continuous testing using manual and test automation tools, followed by provisioning for continuous deployment. They also perform load testing, API testing and security testing using separate tools. An integration support helps to keep the real-time data flowing between the build and the testing tools uninterrupted and seamless.

    A DevOps system also includes application performance monitoring (APM) tool for continuous monitoring of memory consumption, CPU usage, database health and release tracking. Operations team use help desk/ IT service management (ITSM) tools for continuous feedback generation and customer support. And delivery managers use continuous delivery tools for defining and tracking release pipeline through graphical interface.

    When all these tools are connected to a central integration hub, product release and help desk operations become faster and efficient. The integration between development and ITSM tools facilitates continuous feedback generation, which helps to improve the product quality.

    Through an integrated tool ecosystem, project managers can create a DevOps workflow based on business logic and automate the data movement across tool systems. Business analysts, developers, testers and delivery managers can also get real-time update on development progress and keep track of actionable items. Supervisors can route cross-tool data to a central repository and generate meaningful reports and analytics before taking business decisions.

    Fig: ESB Integration Bus Facilitating Adoption of DevOps

    An ESB-based integration tool helps organizations to implement and leverage the best DevOps practices by establishing connections across all participating tools. An integrated tool ecosystem helps achieve the following:

    • Real-time collaboration between development, delivery and operations tools
    • Continuous planning from requirements capturing and review to design and code analysis
    • Cross-tool traceability for defining relationships between various data objects
    • Test strategy implementation for continuous testing
    • Continuous integration through automatic triggering of build on successful completion of code check-in
    • Continuous testing through workflow based automatic triggering of both manual and automated test cases
    • Scheduled test automation script execution enabling continuous delivery
    • Continuous monitoring of release quality through reports and dashboards
    • Automated defect identification and resolution for faster help desk response
    • End-to-end traceability providing better release predictability and change impact analysis
    • Meaningful reports, metrics and KPIs for quick decision-making
    • Continuous delivery through tracking release pipeline

    How Inter-tool Connectivity Brings Continuity

    To understand the stages of engineering practice, let us consider a sample DevOps scenario in an IT service organization.

    The organization uses an ITSM tool to manage support tickets submitted by customers. On submission of a ticket, it is automatically passed on to an ALM tool as user stories or defects for internal development.

    On allotting to a sprint, developers and testers view the user stories or defects from IDE, SCM and test tool. Once the coding is complete and codes get checked in at an SCM tool, an automatic build gets triggered using a build tool. Upon successful completion of the build, tool provisioning is done through a virtual machine.

    The successful build can be automatically deployed using a deployment tool and automated tests can be executed through a test automation tool. The test results are then captured and linked with test cases and the source requirements for traceability.

    The defects that are raised in the defect tracking tool for failed test cases can be automatically routed to developers for fixing.

    Fig: DevOps scenario achieved in a collaborative tool environment

    Once connected to an integrated tool system, users get a complete visibility of the tool records and their relationships from within their own tools. Developers, testers and help desk managers can get complete traceability view between development artifacts and change requests or defects.

    When all the tools participating in DevOps sync with each other, developers can easily view the support tickets reported by the operations team right from their own IDE.

    The help desk team also gets a real-time update whenever a change request gets implemented or a defect is resolved by the development team. It eliminates the latency in communication between the Dev and Ops teams to a great extent.

    In addition, customers get frequent updates from the help desk team, which makes them happy and confident about the product performance.

    Conclusion

    Implementation of DevOps is not a “Do once and forever” type of task. Just deploying the right set of tools to the right users will not serve the purpose. Proper connectivity between and across the DevOps tools chain is necessary if you want to create a collaborative work environment around the Dev and Ops teams.

    An integrated tool system saves considerable amount of time and effort, which would otherwise be wasted on manual execution, monitoring and reporting of data during DevOps implementation.

    About the Author / Sanat Singha

    Sanat Singha is a senior technical and web marketing writer. He takes special interest in ALM process, technologies and tools integration as an industry. Sanat does content marketing, professional blogging, social media promotion and website analytics.

  • Building Security into Code and Culture

    Building Security into Code and Culture

    Organizations tend to have a very predictable approach to security: reactive. Most don’t really care about security until something bad happens. But with data regulations and requirements becoming more rigid around the globe and cybercrime only continuing to escalate, the notion of security as an “add on” or an afterthought is quickly becoming outdated. Today, an organization without adequate security measures is like a skydiver without a parachute—sure, the parachute doesn’t guarantee a 100 percent safe experience, but wouldn’t you rather have one than go without?

    A big problem, however, is that the modern approach to security remains inadequate. Most companies simply layer piecemeal measures over their existing infrastructure, not realizing that this isn’t an effective way to mitigate risk. Instead of adding on bits and pieces of security such as firewalls and antivirus programs, organizations should strive to incorporate security principles into the very foundation of their IT, in both the code and the culture.

    This is what Microsoft sought to do with its SD3+C principles, e.g. Secure by Design, Secure by Default, Secure in Deployment and Communications. While all of these are designed to impose better security measures throughout the development process, the first two arguably provide the highest security benefits. This is because they prevent the introduction of vulnerabilities in the first place while minimizing the potential exposure of software—so-called “attack surfaces.”

    Security and safety by design has thus far achieved greatest maturity in the automobile industry. Modern-day cars have more than 100 different safety and security features, including redundancies, and are rigorously tested for verified assurance. While crash tests destroy vehicles and take time to conduct, they ultimately teach us invaluable lessons that make them 100 percent worth the investment.

    Baking security measures into design and development is likewise a better approach when it comes to code, but it presents a problem: Developers, by nature, don’t want to take the time to build safety nets. A major criticism of SD3+C is that it slows down innovation by forcing developers to make more considerations than “make something really cool at lightning speed.”

    This reaction isn’t surprising when you consider the culture of coding, including the process by which we teach new developers. Hacker culture has long carried a certain kind of allure, romanticizing the role of the developer as a creative, clever and adventurous rogue. It elevates those resourceful individuals that can overcome software challenges in the fastest, nimblest, slickest way—not necessarily the securest.

    It’s never been the standard to teach the morality, ethics or laws of coding; instead, we teach people how to code and let them take off running. But the modern digital age has required us to put the brakes on and rein in that spirit. It’s like teaching someone to drive a Ferrari at breakneck speeds but not about the rules of the road, and then later expecting them to steer within the lanes, stop at red lights and not exceed speed limits.

    Bring Order to Code Chaos

    Our culture of coding inherently perpetuates chaos, but now we need to implement some degree of order, and this is a tough challenge. We need to drive a risk-based approach to development that introduces order into chaos without hindering innovation.

    How do we begin to accomplish this? The first thing to consider is changing how you approach code in the first place by making it more robust. Typically, code can’t be easily changed once it’s written; a single line may be easy to manipulate, but at several million lines, you risk severing the ecological connections that make the app work, and changing any one piece could break the entire application. With your code in such a susceptible state, it’s far too resource-intensive to maintain.

    The solution is to make it more mature in the first place. Make your code modular enough so that it can be amended in part when necessary, and then you can easily bake in additional security measures and eliminate dependence on firewalls and antivirus as your first (or only) line of defense.

    Second, consider the privacy law and contractual requirements of your organization, and address them directly in your code from the start. Understand that different types of privacy data will need to be handled differently and require different levels of protection across technical, physical and administrative dimensions. Whether you deal with payment card industry (PCI) or protected health information (PHI), you should be intimately familiar with the standards governing the protection of data your organization deals with.

    Now, what about culture? In its simplest essence, we can think of culture as comprised of three basic factors: rules, tools and fears. Where rules exist, you should apply them; where tools exist, you should use them; and as an organization, you should be “afraid” of the same things, because common fears tend to be strong motivators for groups of people or the masses. The only re-transmission of culture is through awareness, training and immersion.

    An important point I invite you to consider is that human beings won’t do anything without a reason, whether real or imagined. Humans are experienced-based learners not knowledge-based learners. For this reason, we learn valuable lessons from mistakes and failures. An important aspect of this is timely communications. When something has gone wrong we need to be able to get the right people on task to work toward planning mitigations, learning lessons and making things better.

    One way to effectively change or reshape your culture is to enforce the rules—for instance, the new General Data Protection Regulation (GDPR) mandates severe fines and consequences for PII data breaches (which is, in fact, similar to penalties enacted by the auto industry years ago).

    Another is to provide better tools and processes that essentially “force” (or, more kindly, compel) your team to use the right approach or method.

    Finally, you can employ fear, uncertainty and doubt, otherwise known as “FUD.” Though it may sound a bit sinister, FUD can be a very effective way to govern—although on its own, it’s a very tenuous and fragile kind of power. This is why you balance it with rules and tools, so that the overarching objective will resonate in both the hearts and minds of your team: Keep your organization happy and healthy.

    Because this is the reality that modern digital organizations must face: It doesn’t matter how innovative or bleeding-edge you are unless your business stays healthy! A tree that is well-rooted and cultivated to grow properly and upright will weather the worst storms, and ultimately live a long and prosperous life. Remember that Ford once had to introduce critical safety measures to the Model T, and nobody was worried about hydraulic brakes, seat belts and padded dashboards slowing us down.

    About the Author / Robert Hawk

    Robert Hawk is Resident Security Expert at xMatters. He has extensive experience in Information Systems Security, Computer Security, Cyber Security, Information Assurance, as well as Governance, Risk, and Compliance (GRC) Management. He specializes in frameworks and standards from: ISO/IEC, NIST, IEEE, IETF, ITU-T, Common Criteria, AMI-SEC, NERC, CIS, DoD, ANSI, PCI, and ISECOM. Robert is a lifelong researcher, innovator and instructor. Connect with him on LinkedIn.