devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Provide Continuous Value with Product-Centric Delivery

    Provide Continuous Value with Product-Centric Delivery

    Software engineering and management has borrowed many practices over the years from traditional industries such as construction, automotive and manufacturing. One such practice is the notion of managing software development and delivery based on projects.

    According to the Project Management Institute (PMI), a project is defined as “a temporary endeavor undertaken to create a unique product, service or result. A project is temporary, in that it has a defined beginning and end in time, and, therefore, defined scope and resources.”

    Many enterprises today manage software delivery via a project-centric software delivery approach. New software projects are identified based on probable business cases. Business opportunities are identified and prioritized based on potential business benefits and estimated cost. This is done with the assumption that the exact market needs, the estimated cost, start and end dates, and potential benefits are certain and known up front. Once the business case is approved by senior management, projects are initiated. In an environment where the scope, schedule and cost of projects can be defined upfront, this provides a predictable approach for software delivery management and governance. 

    But, do we live in a world of total certainty? In the volatile and uncertain world in which we live—with the very fact that software is not a physical good—accurate predictions of market needs, cost, timing and end-user benefits are far from reality. In addition, companies are competing in the marketplace by exploring innovative ways to create and deliver new products and services.

    Why is the project-centric delivery approach used by so many IT organizations if it is a challenge? Projects can no longer be the vehicle for software development and delivery if enterprises want to stay ahead of the competition. Then, what is the alternative approach?

    Introducing the Product-Centric Delivery Model

    A product-centric delivery model is a new way of organizing people, and continuously delivering valuable software to customers.

    Let’s take a look at the steps an enterprise needs to follow in order to transition from project-centric to product-centric software delivery. 

    Identify Products Instead of Projects

    What are software products? Organizations across the world provide value to their customers in the form of goods and services. These goods and services are called products and are often driven by software and IT systems. For example, to a bank that provides digital banking services to its customers, its online banking solution is a product, not a project. Similarly, for a retail company, its catalog and product search becomes a product. These kinds of products are different from the actual physical goods that these companies sell.

    Organize and Fund Stable Teams Around a Product, Not a Project

    Once your products are identified, the next step is to organize and fund your software teams around these products. These cross-functional teams include members from business development, IT development, support and operations. This team must be empowered to build and deliver the product on their own and will collaborate, decide what to build, how to develop it and how to manage the product with frequent updates. The team must be outcome-oriented, long-living and cross-functional. They can be organized as a team-of-teams or squads, resulting in better collaboration, focus and ownership from any corner of the world. This will also help in scaling the overall capacity of the product. A common shared services team, supporting multiple products might be an added advantage. 

    Define Product Vision, Define Objectives, Deliver and Measure Value

    After the products and the teams are in place, you need to define the product vision. The product vision defines the reason for its existence and the long-term goal that it is trying to achieve. This also aligns business objectives with IT delivery and provides guidance for all decisions made regarding the product development and delivery.

    The business stakeholders define the product vision and derive the near-term objectives that will guide the teams to further decide the set of initiatives they need to work on.

    The teams then identify relevant product features, plan and deliver those in short increments or time boxes, thereby delivering continuous value to end users.

    At the end of each time-box, stakeholders will measure the product outcome with the stated objectives and changes in the market needs. The findings will help the business decide on whether to continue investing in the product or not.

    Conclusion

    Product-centric delivery paves a new way of organizing people and continuously delivering software value with more emphasis on outcome rather than the output. It provides a continuous flow of work to the product teams and continuous value to the end users. It aligns the business strategy to software development and execution, while empowering the teams to decide what is best for their product.

    — Prabhu Arumugham

  • Don’t Let ‘Hindsight 2020’ Be Your DevOps Strategy

    Don’t Let ‘Hindsight 2020’ Be Your DevOps Strategy

    The idea of DevOps originated a little over a decade ago with a desire to ensure efficiency in the overall software development and delivery process. Constant operational hurdles that have been hampering flawless and frequent delivery of applications have led organizations to think beyond and to come up with continuous improvements in their processes and tooling. Thus, DevOps has evolved into a solid practice to aid enterprises with an end-to-end feedback enabled framework that spans across various functions and stakeholders to design, develop and deliver quality software.

    The IT landscape over the last few years has changed significantly. Companies are building secure applications and large volumes of workloads are being transformed to the public cloud. Nowadays, firms are actively applying AI technologies to transform their businesses more than they were just a few years ago. Some companies are still investing heavily on building their own complex AI platforms involving expensive infrastructure, but most companies have realized the value in leveraging AI as a service offered by leading cloud providers.

    Digital initiatives and IoT have further increased the use of cloud-based services and the need for automated deployment and delivery of applications and services. Seamless integration of the CI/CD pipeline for on-premise or deployment to the cloud is possible only with a solid DevOps practice. For organizations that are ambitious and striving to get ahead of the game in order to accelerate the growth of their businesses, DevOps is indispensable.

    To successfully implement some of the current major trends in IT, organizations are required to have a mature DevOps practice in place.  In October 2019, Gartner published its predictions on technology trends for 2020. We’ll pick a few from those to discuss the crucial role that DevOps is expected to play in them, and the critical success factors for companies to be advanced forward.  

    Strategic Trends in IT and the Role of DevOps

    Hyperautomation

    Gartner’s analysis on strategic technology trends for 2020 has hyperautomation as the number one trend. Hyperautomation, which enables organizations to function as autonomous digital enterprises, will be leveraging latest technologies such as 5G networks, intelligent edge devices, advanced data analytics, expanding RPA with AI, etc. Firms aspiring to implement AI and ML on a grand scale will want to take advantage of the diverse range of complex machine learning algorithms implemented on scalable cloud infrastructure and offered as services.

    Instead of recreating everything from scratch, organizations will simply upload their data to the cloud and train algorithms based on their business processes and needs. For hyperautomation initiatives to be successful, organizations need to implement end-to-end fully automated DevOps processes with the relevant tooling to specifically address the varied needs from several perspectives. Speed, agility and ensuring an error-free repeatable process will be basic requirements for hyperautomation.

    On-demand deployment of transient infrastructure on the cloud, driven by infrastructure as code and configuration as code will be a primary requirement for rapid development and testing of artifacts that form components of hyperautomation. Fully automated pipelines for the creation and deployment of containers will become a core requirement not only for hyperautomation but in general for most applications. The involvement of DevOps to manage data virtualization, obfuscation and uploading data to the cloud will become more significant to increase the overall efficiency of the automated CI/CD pipelines for hyperautomation projects. 

    Democratization of IT

    Democratization of technology is about making technology more accessible to common people. Gartner has predicted this to be another major trend for 2020. Smartphones and the internet have already played a major role on this front and have enabled people with the technology, tools and data to help make better decisions. Democratization of technology in the IT world is about enabling the IT community and it gets more and more interesting day by day.

    With container technologies such as Docker Desktop that can run on a user’s laptop, a developer now has access to pre-configured container images of various operating systems and other platforms that can be pulled from container registries within seconds. Cloud services such as IaaS, SaaS and PaaS add to this by providing more independence to the development teams apart from making the entire process agile and faster. Democratization at these levels also leads to setting a different level of expectations on the overall velocity of development and delivery of applications. All these services in isolation, i.e. when not connected together through a strong DevOps process and toolset, will not produce the expected level of agility and speed.

    An end-to-end DevOps process works all the way: from triggering the build of a container image as the code is built, deploying an environment on the cloud, integrating with other components, testing artifacts with automated testing and finally to producing a production-worthy artifact. When IT teams get more democratic, they will run their domain the way they perceive beneficial and produce the best possible outcome with quality and speed to make their teams and the organization successful. DevOps will be the means to achieving that goal.

    Internet of Things

    Edge devices are getting smarter by the day. Mass manufacturing of intelligent controller boards, such as the ESP 8266 and ESP 32, is making it extremely cheap to build edge devices with data storage and processing capabilities locally within the device itself instead of communicating with a cloud based central system for command and control. However, such intelligent devices need to be kept up-to-date on security patches, bug-fixes, firmware updates, etc. A solid DevOps framework that integrates testing of patches/fixes, and deploys tested artifacts to remote edge devices is an absolutely essential component of an organization’s IoT ecosystem.

    Some controller boards run light-weight versions of Linux and have the capability to additionally run a Docker engine. This helps ensure consistency through deployment of updated containers via a DevOps pipeline to the edge devices. Convergence of cloud and digital transformation initiatives, especially in IoT over the last few years, has widened the scope of DevOps. Major cloud providers are already offering several services to integrate edge devices with a full-fledged CI/CD pipeline leveraging DevOps processes and tools. 

    Blockchain

    Application developers and IT managers spend a great deal of time either fixing bugs or recovering systems from breakdowns caused by bugs. If best practices, processes and tools are put to proper use, this wasted effort can be greatly reduced and the entire development and delivery process could be made more efficient. Blockchain demands building a strong foundation in IT and raises the need for higher quality in software development, delivery and IT operations on the whole.

    Organizations have to take a closer look at their current capabilities and process maturity before embarking on a journey involving blockchain. Firms that have faced failures with blockchain can certainly vouch for the fact that the failure wasn’t caused by the concept of blockchain or the algorithms that drive it. Rather they had resulted because the rest of the IT systems weren’t reliable enough to keep up with the strict demands of the blockchain systems. DevOps and automation will certainly help improve the security, quality, reliability and repeatable deployment of applications. When the systems that feed the blockchain application go through such increments of improvement, the net effect is that the organization is getting closer to implementing a solid blockchain solution.

    Success Factors

    Firms are moving fast toward the cloud for IaaS and PaaS services. As DevOps, CloudOps and SecOps are converging, CIOs are becoming conscious about building organizations that encapsulate these functions under one leadership in order to set shared goals and ensure synergies across these functions. Organizations with strict compliance requirements and governance would need to involve their operations teams to lay the rules regarding using cloud services.

    Application development teams and users are still dependent on several operations teams to design and implement secure cloud connectivity and to establish the rules around using cloud services. While a strong governance is absolutely essential, there is a high possibility for firms to lose their agility and get caught once again in a mess if these operational processes are not smoothen and streamlined. For the strategic initiatives on implementing the new trends to succeed, it is vital for DevOps to be able to operate without any hurdles.

    Below are a few critical success factors worth considering.

    Dev and Ops in a Box

    Organizational structure plays a key role in determining the success of DevOps. Keeping applications development, DevOps and infrastructure operations very closely aligned with overlapping goals, KPIs and roadmaps is a key to success. Companies that operate these functions independently without proper alignment fail to establish an organization-wide DevOps culture and rarely reap the full benefits of DevOps.

    Full-Stack Engineers for DevOps

    It is important to develop a DevOps culture across the company. At the same time, it is equally important to bring in experts who can evangelize DevOps and take a completely fresh look at how things are done. Experienced DevOps professionals can pin-point areas for improvement, and additionally help accelerate the adoption rate of DevOps. Settling for high-quality resources that have full-stack experience is absolutely essential if you are in for a long run with DevOps. Global companies should seriously consider placing such experienced resources close to the development and operations teams. While it may be cost-effective to recruit resources offshore, that may not be such a good idea if your active development and infrastructure teams are onshore. 

    Trained Internal Resources

    Training internal resources are extremely important in order to carry out the recommendations from experts and to make DevOps a habit. Trained resources have to be deployed immediately to work on DevOps initiatives alongside the experts. To establish synergy and increase collaboration, it is a good idea to send development and operations resources to some common training courses and sessions.

    Wrapping Things Up

    Research organizations are closely observing the direction in which most organizations are moving toward in order to improve their speed, efficiency, agility and their overall ability to provide services that are secure and reliable. Business strategy and technology feed each other and as a result, some key trends in technology emerge from time to time.

    We looked at some of the trends that are going to be prominent in 2020 and the role that DevOps would have in implementing these technologies. Regardless of any specific technology, it is important to automate the integration and delivery of applications. DevOps processes and tooling will help a great deal in accelerating the pace of implementing new technologies and leveraging them in business applications.

    The organization of IT teams and a focus on recruiting the right talents will determine the overall success of DevOps. Training internal staff would help sustain the culture of DevOps in companies and fuel further growth in this space. DevOps will not be an optional function any more. It will be an essential component of the culture, and firms that adapt themselves sooner to this culture will be the ones most successful in implementing the current and future trends in technology.

    — Sridhar Asvathanarayanan

  • Survey Finds IT Modernization Efforts Reap Significant Benefits

    Survey Finds IT Modernization Efforts Reap Significant Benefits

    When it comes to the state of IT, few questions weigh more substantially on the minds of CIOs and other business-technology leaders than the degree of success they see in their digital transformation efforts, and foundational to that their efforts to modernize their technology stack.

    In a survey recently released by market research firm IDG, and commissioned by services provider Insight, those enterprises that have managed to reach their initial modernization goals report (25% in this survey) success they say that they can quantify in such areas as cost efficiency, availability and customer experience. Sixty-seven percent of respondents said that their modernization efforts are essential to their digital transformations.

    There were 26% of respondents who said they are at the beginning of their modernization work. Even still, many reporting significant business benefits including improved quality of service (65%), better customer experience/satisfaction (52%), cost savings (50%), uptime (44%) and the creation of revenue-generating products and services (42%).

    The “The State of IT Modernization 2020” survey questioned 200 IT executives at organizations 29,000 employees on average and within a range of industries. The survey examined the maturity of efforts to mature IT operating environments, cloud strategies, applications and processes.

    Of those respondents who stated that they reached their initial modernization goals, 19% report having made moderate progress on those goals and 31% said their development has been significant. Twenty-five percent said they’ve hit their initial goals and are optimizing where possible.

    Despite 59% of respondents reporting moving forward with their modernization efforts, 41% said they have delayed or abandoned those efforts. According to the survey, they did so due to competing priorities (46%), poor roadmap (45%), concerns about data privacy and security (39%), lack of skills (38%), didn’t or couldn’t budget appropriately (30%), and unexpected challenges (30%).

    Not surprisingly, the vast majority of organizations cited cloud optimization as a central part of their modernization efforts and ranked nearly ubiquitous. These included application modification (93%), increasing public cloud workloads (92%) and private clouds (91%), and moving to multi-cloud (87%) or a hybrid-cloud model (89%).

    Further, and what highlights the difficulty some organizations have when finding the optimal home for all of their workloads, 84% said they transferred specific workloads from a public cloud to a non-cloud location. These transitions may have been driven, in part, by the 69% who found their cloud costs to be 62% higher than they expected. The underlying causes of those cost overruns range from “data egress charges for shared persistent data, unplanned cloud adoption, and mergers and acquisitions to failure to take advantage of vendor volume discounts, over-subscription and failure to optimize workloads to extract maximum value from cloud platforms,” Insight said in a statement.

    Finally, the survey found that 95% of respondents are outsourcing at least some facet of their operating environments to a managed services provider. Eighty-four percent said they are outsourcing cloud management.

    Going forward, the most commonly cited priorities include better managing workloads based on their use (39%), improved design to size services to need (38%) and the implementation of additional policies that will restrict the type and size of cloud services made available internally to their organization.

    — George V. Hulme

  • The Right Toolchain Is the One You Build

    The Right Toolchain Is the One You Build

    One of several iterations that IT likes to go through is corporate standards for technology versus best tool for the job. We like to have standardization because it allows staffing portability between projects, but we like right tool for the job because from the moment you choose a standard, competitive factors and changes in needs make the standard less of a big win.

    DevOps is still struggling through this process, particularly in enterprises where standardization bears a bit more weight on important projects.

    The fact is that DevOps is well suited to the idea of iterating standards–somewhere between a wild west of everyone using their “right tool” and an organization dictating the tool of choice.

    Most of us use Jenkins, because it does what we need it to do. What needs doing is different from organization to organization–some use it for continuous testing, while others go all the way through application release automation. But the fact is we could iterate and replace some, or all, of the functionality we’ve decided to use Jenkins for tomorrow. Kind of like a “We have a standard that is evaluated regularly” approach.

    For those new to DevOps, the array of choices is downright bewildering. Xebia Labs has a toolchain diagram page to help those already doing DevOps, and several sources have spreadsheets/PowerPoint templates to help you work through your existing environment. While all of the options these tools try to organize for you are great for the industry to find better solutions, it makes for a confusing mess. Your toolchain could be all AWS with some scripting, all Jenkins with plug-ins or 15 different apps working independently. A surprising number of organizations are even using Git for the bulk of their toolchain.

    What matters is that you know what you have, and know what your options are. Build the best toolchain for your environment today, and keep half an eye on it to be aware when something more suited to your environment comes along. We still maintain python scripts that do a fair amount of our automation, but several toolsets in place also.

    There are objectively better tools out there, but for our purposes they are almost universally overkill. So we go with what’s best for our environment. As time has gone on, we’ve integrated more and scripted less, but it will be a while before out toolchain is actually just tools–if ever.

    If your toolset is doing the build/test/deliver/deploy cycle well enough, you’re covered. If it’s not, you need to look for alternate solutions. Even if it is, make sure you’re aware of what’s on the market and not just what’s “hot” right now. Be aware of those companies that are up and coming, maybe in spaces that are already flooded. What differentiates them, and in our environment would that differentiation matter? That’s all you need to know–there is no need for a super deep technical evaluation, unless you’re actually considering them. Just enough to know if their differences add value.

    Keep cranking out the apps that make business run. Perhaps with an updated toolchain, perhaps not. In the end, what works for your environment is all that matters.

    — Don Macvittie

  • Why Enterprise Survival Depends on a Context Driven Approach to Data

    Why Enterprise Survival Depends on a Context Driven Approach to Data

    Enterprises are sitting on an enormous amount of data that could be fueling their automation journey. Much of the information needed to run a business is existing data. However, much of an organization’s data is inaccessible and unsearchable. This so-called “dark data” is hidden away in paper forms, spreadsheets, emails and literally billions of PDF documents. This dark data is locked away and mostly unusable by the systems and AI required to power the autonomous business of the future. Enterprises are trying to achieve 21st-century outcomes while being shackled to 20th-century data practices. 

    I recently read a report from NewVantage Partners on a survey they did concerning how big data and AI were driving digital transformation. While 92% of the survey respondents said they were increasing investment in big data and AI, there were some interesting findings that suggest organizations are not realizing the ROI they had hoped. For instance:

    • Only 31% have a data-driven organization.
    • Only 28% stated they have a data culture.
    • 53% are not treating data as a business asset.
    • 38% have not realized any measurable outcome from their investment.

    Now, there’s a whole list of reasons and hurdles that are preventing organizations from realizing better value and outcomes from their efforts to become data-driven. But, could the underlying approach to becoming data-driven be flawed? Could organizations be struggling because they continue to apply a legacy mindset and approach to data acquisition and storage? Could these challenges be a contributing factor in 70% of digital transformation projects failing?

    Just take a look at the growing number of stories, market reports and surveys on digital transformation and you’ll see a graveyard of failed projects, lack of success and high turnover rates. The current approach to digital transformation is not working. 

    In our push to become data-driven, we capture data and attempt to transform it into computable bits and then stuff the data into rigid structures. This legacy approach to capturing and representing information outside the human brain results in a proliferation of single-use data that doesn’t scale with the business. We always lose some of the meaning, relationships and context. Despite all the advancements in technology, we’re still trying to model the information based on how we’ve historically stored data. We’re still producing flat data.  

    In the autonomous enterprise of the future, and the digital workers that will run them will need rich, contextual data. The true power and value of digital transformation will only be unlocked by the adoption of a semantic data-driven approach. The future of work will be built on digital workers powered by machine learning, artificial intelligence and knowledge graphs. It’s not enough for an organization to be data-driven anymore–they need to become contextually-driven. We need to start capturing the meaning to achieve a better understanding of the data.

    “I liked the idea that a piece of information is really defined only by what it’s related to, and how it’s related. There really is little else to meaning,” said Sir Tim Berners-Lee, the inventor of the World Wide Web.

    Context is all about the meaning. Context is more than just a piece of data. Context is the background in which an event, task or process takes place. It is the deep, multi-dimensional understanding of data and the relationships between the entities. Understanding the context can lead to accelerated insight through AI and machine learning. To be competitive, enterprises need more than data; they need context to enhance productivity and efficiency. But our current approaches to capturing and storing data have historically failed to capture this valuable context. As the amount of data grows exponentially, organizations will realize semantic data is key to survival.

    — Kevin Harbauer

  • Does the Empire Strike Back When We Learn What Happens to the $10 Billion JEDI Contract?

    Does the Empire Strike Back When We Learn What Happens to the $10 Billion JEDI Contract?

    Microsoft scored a huge victory by sweeping in and taking the $10 billion dollar, multi-year JEDI contract for military IT services from AWS (owned and operated by amazon.com, its parent company). The backstory on this is that James “Mad Dog” Mattis, then Secretary of Defense, met with Jeff Bezos who tweeted about it on August 10, 2017 and it appears that Mattis decided to structure a request for IT services (now known as the JEDI contract) that all but led to AWS being crowned the winner by the way the bid was structured.

    However, this was not to be. Not only was Mattis gone by January of 2019, but President Trump and Jeff Bezos were having public squabbling matches regarding coverage of the Trump administration in the Washington Post (which Jeff Bezos had purchased in 2013). So tenuous is their relationship that Trump mocked Bezos on Twitter regarding his divorce which was precipitated by the leaked private messages and pictures between Mr. Bezos and his mistress.

    What does this all have to do with JEDI? Quite a bit, actually. Amazon has won a perhaps Pyrrhic victory by getting an injunction and getting any work to stop on the process of implementing the JEDI contract on Microsoft’s cloud. Amazon is posting a $42 million bond to cover any costs the government or Microsoft might incur if it turns out that this stoppage is unjustified—not small beans, but not a lot of money to either of these tech titans.

    Which way does this jump ball go now? It seems like Microsoft would still have the upper hand, because they as well as the U.S. government would have contemplated this outcome when they decided to switch to a Microsoft solution at what seems like the last minute.

    Amazon makes a compelling case as well: Because of the public animosity between two feuding billionaires, one a president, and one the richest man in America, government officials would be afraid to award a contract to Amazon’s AWS because they would suffer the wrath of Trump and his officials. The Trump administration has made it no secret that there is a revolving door for people who don’t get with the Trump administration and its policies. Sounds like a win for Amazon, right?

    At the same time, Jeff Bezos’s leaked text and pictures between his mistress bring up a larger question: How can the U.S. government trust some of its most precious data when the CEO not only leaks such personal information, but it is so public that Mr. Bezos himself discussed what he considered ransom demands from a tabloid that threatened to cover it on a blog post on Twitter. Even worse, supposedly the pictures and texts were obtained by the leader of Saudi Arabia, a foreign country, through a bug in WhatsApp that allowed installation of malware on Jeff’s phone that allowed all the data from his phone to be siphoned off to a foreign entity. It’s difficult for AWS to say they are the best solution when their own CEO admits that his most personal data (a secret affair with his mistress) was stolen. What would happen to real military secrets if Amazon’s CEO can’t protect his own?

    The fallout from all this is what you’d expect. More arm waving, conjecture and confusion. The reality is this opens up the field to other players such as Google and Oracle. At the same time, there are hundreds of other clouds that may be able to make a case that they are a best fit for certain applications since they may specialize in specific compliances, such as SOX, PCI or HIPAA.

    Ultimately, this calls into question whether the government should be putting all its cloud eggs in one basket. The longer-term solution is that the government needs to dictate a series of APIs that its developers and contractors use, and that all compliant clouds would be required to support. This would alleviate the problem of centralizing resources on a single vendor’s solution. 

    In the medium term, lots of fireworks, lots of drama and most likely Microsoft, the original software empire, striking back and keeping the JEDI contract—one that was Amazon’s to lose. But the story isn’t written so we all need to keep watching for the return of the JEDI to see where this finally ends up.

    — Marty Puranik

  • Observability-Driven Development: From Software Development to DevOps and Beyond

    Observability-Driven Development: From Software Development to DevOps and Beyond

    In today’s world of cloud platforms and applications, typically delivered as SaaS (Software as a Service), it is critical for organizations to ensure efficient collaboration between software development and operations teams. The software development team codes the software application or platform, while the DevOps team streamlines and automates the entire production lifecycle, from development and testing to deployment.

    Today, applications are updated anywhere from weekly to daily, requiring fast turnaround. In the old days, every change request would go to the different stages–software design, development, testing and release. This can’t be sustained in an agile environment where updates must be as close to instantaneous as possible. 

    How can organizations achieve this, and where does observability fit into it all?

    What Is Observability and ODD?

    Observability-driven development (ODD) adds another layer to software development by encouraging the development team to think about the application availability and uptime throughout their development process and similar to unit-testing development, wrap their code with more verbose logging, metrics and KPIs. This gives the IT operations team more data on the application and improves overall observability, allowing an organization to detect predictable and unpredictable permutations of failures that may occur in the future. ODD observes the behavior of a system throughout the entire development cycle in order to learn what behavior is normal and abnormal, and to detect potential weaknesses.

    Observability provides everything with a real-time status of a product–this includes software developers, DevOps and any other department that requires it. Each role has different needs. Software developers need to know why a certain feature has to be added or developed in order to understand its business value and prioritize it over other features or updates. If a certain feature is likely to require many future updates, this also needs to be taken into consideration in the development phase so that the code can be adjusted easily without negatively affecting DevOps teams when they test and deploy the feature.

    These are just examples of things that must be taken into consideration during the development process. Organizations must be able to create transparency and effective communication between the different departments and roles.

    Inefficient Collaboration in the SaaS Market 

    DevOps need to ensure zero downtime, fast updates, constant monitoring and more. This can be done by maintaining an operational mindset during the development process. Traditionally, developers write the code, QA do the testing and operations take care of deployment, but there needs to be more collaboration between these three stages with each doing their part with an understanding of everyone else’s roles and needs pertaining to the product. When this isn’t done, numerous problems arise. Operational inefficiencies can ultimately lead to a delay in delivery time and even affect system availability. When there are multiple teams involved, especially in different locations and even time zones, there can be ineffective communication and hand-offs, particularly between software development and operations teams.

    Meanwhile, ad hoc changes must be implemented, negatively affecting product stability and release cycles. Miscommunication and inefficient operations lead to confusion over who is responsible for what task, feature and target. These are all issues that can result in significant downtime, losses, wasted resources and frustration within the organization. Effectively streamlining the software development cycle using full transparency and seamless collaboration between development and operations solves these problems.

    ODD Can Improve Your SaaS Product

    A strong proactive observability platform can predict and address issues before they occur, thus increasing effectiveness and speed when it comes to updating and tracking changes, as well as releasing new features. It simplifies complexities and management, and allows to automate operations so that organizations can maximize efficiency.

    Benefits of ODD include:

    • Common goals.
    • Shared metrics.
    • Execute on goals and recognize results.
    • Performance guidelines.
    • Application governance strategy.
    • Alignment between IT and business perspectives.

    Employing ODD when developing cloud applications is critical. This is due to the highly distributed nature of cloud architectures, increasing the chances of a failure exponentially compared to traditional systems. As a result, developers should be educated to think and implement observability to create highly available and resilient applications and systems.

    How to Integrate ODD in Your R&D Practices

    Today, development teams and practices are under constant pressure to meet scrum deadlines and release features on time. They are measured on their code effectiveness and meeting deadlines, while ODD adds another layer of measurement of serviceability and observability metrics to their considerations. 

    Implementing such an approach requires organizations to provide their development teams with the right toolset and knowledge on how their code affects the SRE and IT operations teams. From a technical standpoint, development teams should be familiar with all levels of monitoring for application infrastructure (for example Kafka, RabbitMQ, Kubernetes), application performance metrics (user experience, transactions per second, etc.) visualizations and their respective remediation processes. 

    ODD culture changes the way organizations think about their development process, and essentially injects an operational mindset to their daily practices and processes which should increase the availability and performance of their cloud application while streamlining collaboration and work processes, and improving teams’ satisfaction and productivity.

    — Avi Shalisman

  • What Makes Digital Transformation a Success?

    What Makes Digital Transformation a Success?

    Despite more than $5 trillion having been spent on digital transformation efforts, survey after survey shows that successful digital transformations are far and few in-between. By many estimates, more than 50% of digital transformation efforts failed in recent years.

    While a recent survey conducted by Hanover Research and commissioned by AHEAD, the State of Enterprise Digital Transformation, found that 93% of enterprises are undergoing some digital transformation as they seek to cut costs (77%) and improve customer experience (71%). The survey found 42% of enterprises struggling to reach success as their efforts fall behind or stall.

    This survey found many challenges, both demanding and typical among enterprise digital transformation efforts, including hurdles created by legacy systems (36%) and technical debt (24%). With that in mind, it’s no shock that 67% cited infrastructure as a critical part of their digital transformation efforts.

    Additionally, the survey found that improving operational efficiency and cost-cutting are motivators in 77% of digital efforts. Those needs beat improving the customer experience, at 71% of enterprises.

    When it comes to results, this survey found more optimistic results. According to the survey, 58% of those surveyed said their digital transformation projects are on target or even ahead of schedule, with only 42% citing faltering progress.

    The State of Enterprise Digital Transformation survey found six core factors of success:

    1. Dedicated Leadership: The survey found that 83% of digital transformations that are on track or ahead of schedule are led by a CIO, CEO, CDO or CTO. As digital transformation touches every part of an enterprise, the company-wide buy-in is critical. While 27% of organizations have a CIO leading their transformations, only 8% of organizations have a chief digital officer leading the transformation efforts. Chief technology officers are leading the efforts at 16% of organizations.
    2. All-In Approach: Transformations that are on track are 30% more likely to be structured as full-scale change initiatives. Because digital operations are often so interconnected, piecemeal and partial transformations can often be siloed and result in limited impact on the factors driving the transformation.
    3. Defined Digital Roadmap: Ninety-two percent of transformations that are on target or ahead of schedule have a defined strategy and roadmap that includes IT infrastructure and operations.
    4. Alignment Between Infrastructure and Apps: Enterprises powered by an integrated DevOps approach are 43% more likely to see success in digital transformation efforts. To avoid bottlenecks, enterprises should audit DevOps functions before undergoing digital transformation.
    5. Platform Mindset: Businesses that include IT infrastructure as a big part of their digital transformation are 36% more likely to have a successful transformation. As the backbone of a digital change initiative, an enterprise’s infrastructure determines how far the transformation will go and its limits.
    6. Commitment to Intelligent Operations: Companies that monitor IT performance in real-time and remediate issues quickly are 24% more likely to undergo a successful digital transformation. Further, the survey found that enterprises are more likely to see success in digital transformation if they have confidence in their abilities to perform highly in areas of automation, monitoring, hybrid cloud models and integrated security.

    Last year, in Digital Transformation: Coming from Behind, we cited research from the consultancy McKinsey & Company found that less than one-third of transformations are successful. While this survey from AHEAD finds more optimistic outcomes, most previous surveys and our interviews with transformers echoed AHEAD’s survey findings, with the need for leadership, dedication to platforms, defined strategy and proper alignment all being essential to success.

    The State of Enterprise Digital Transformation survey was conducted by Hanover Research through September and October 2019. The survey is based on the responses of 293 IT decision-makers with a direct influence on IT spend at companies based in the U.S., and with more than 1,000 employees.

    — George V. Hulme

  • Collaboration Over Competition: How Companies Benefit from Open Innovation

    Collaboration Over Competition: How Companies Benefit from Open Innovation

    More and more technology companies are adopting open innovation initiatives. This is largely due to the realization of the benefits of working with outside experts to gain external perspectives and insights. This situation wherein an organization thinks beyond its internal resources for innovation and collaborates with external resources is known as open innovation. Open innovation is an opportunity for the company to utilize those external ideas and use them to develop innovative products and services. It may seem simple, but there is more to the collaboration process than just brainstorming.

    Open innovation is not easy, but the benefits are well worth the effort. Large technology organizations can establish a competitive advantage by partnering with promising startups. The startups benefit from this partnership by gaining access to venture capital resources, networking opportunities and the opportunity to reach a broader customer base, typically tied to a large company.

    Larger companies that typically change at a glacial pace can learn from their small yet evolving partners. Startup founders who are new to an industry can form valuable relationships and gain mentors with seasoned veterans.

    Overcoming Obstacles

    Technology organizations, large and small, should be prepared to make some changes in order to benefit from an open innovation environment. Indoctrinating an attitude of information sharing can be difficult in companies that have historically kept their intellectual property under wraps, and in many companies, even developing a collaborative environment across various departments can be an uphill battle.

    Breaking down barriers and overcoming this predisposition toward secrets is the only way to cultivate a collaborative environment. Ultimately, this effort begins in the boardroom. Once a large company has executive buy-in, the idea will begin to trickle from the top down, and over time it will take hold.

    The following steps will serve as important guidelines to tackle obstacles and sustain this synergy.

    Create Ecosystems Around Intellectual Property

    It is common for both parties to feel the need to protect their intellectual property, but that closed mindset defeats the purpose of an open innovation initiative. To overcome this obstacle, it is critical to emphasize the greater value and benefits that come from an open innovation ecosystem. All parties must realize that sharing their intellectual property into the ecosystem can accelerate the pace of innovation.

    Several companies have demonstrated the value of this approach. Tesla, for instance, made the decision to open source its patents a few years ago, recognizing that the company couldn’t make electric cars fast enough to slow the global carbon crisis. Elon Musk also pointed out that patents represented a small protection indeed against a determined competitor, and he thought the decision to open source would strengthen the company’s position.

    Assess Your Partners

    Adding a collaborator to your open network should not be a decision that is made lightly. The organization should be patient and cautious when selecting a potential partner. Weigh each company’s skills and capabilities and consider any disadvantages as well. Just because a partner is not perfect does not mean it is not the best choice, but knowing its weaknesses will help you address them before they become a problem.

    An organization should be assessing several prospective partners. Establish processes that ensure each potential collaborator is examined fairly, but critically so that the end goal to identify the companies that will not be a good fit is achieved. This practice is not just for your benefit alone—an unproductive collaboration can incur in heavy costs and wasted time to all parties involved.

    Adjust Business Models as Necessary

    Business models are designed to maximize benefits and minimize risks, but they should allow for some flexibility. In the real world, changes arise frequently, and business models must adapt. For instance, many partnerships established around open innovation initially began between two companies. Over time, it is a reasonable expectation to anticipate other players be added to the mix.

    A multi-dimensional ecosystem demands a different business model than a version that is two-dimensional because it may involve a different set of risks. It also has a more complex intellectual property pipeline where contributions and evolutions are more difficult to track and manage. As long as each partner is prepared to adjust business models, these changes can be effectively addressed.

    Foster a Collaborative Culture

    For the vast majority of companies, open innovation is not an organic process. Even within an organization, some departments tend to be closed off about their projects or even sharing information outside the company. An attitude of open innovation comes from internal change, and people are naturally resistant to change. To encourage a culture-shift, start from the top down.

    Support from leadership is critical for developing a culture that is compatible with open innovation. It is also important to identify the soft skills that a team needs to accomplish its goals. Open innovation itself is a skill that can be taught—problems arise when company executives expect it to be a trait that employees are inherently born with.

    There are numerous benefits of open innovation. Technology companies can produce more ideas in a shorter span of time mutually benefiting all businesses involved. There is an opportunity to create markets that did not exist prior to the development of the initiative.

    Of course, obstacles are also inevitable and more so because sharing valuable intellectual property outside the confines of a research and development department is always looked down upon. People, and business models, are naturally resistant to the significant change that comes with the open innovation approach. Whether a company can overcome these obstacles and see the many advantages is a matter of determination and a desire to adopt company-wide changes so that there is innovation across the organization.

    — K.R. Sanjiv

  • Why BizOps Is Becoming Important and How It Can Help Your Teams

    Why BizOps Is Becoming Important and How It Can Help Your Teams

    Every 20 seconds, $1 million is wasted on IT investments that don’t align with business strategy. How much is your business wasting? To align business, development and IT operations, your teams need to adopt a new BizOps approach.

    In this blog, we’ll take a closer look at BizOps and why it’s becoming so important. 

    Why DevOps Falls Short

    The lack of alignment between business, development and IT is one of the main reasons why digital transformation initiatives are failing. Why is this such a widespread problem? While Agile and DevOps take steps toward continual improvement, they don’t fully connect your technology investments to business outcomes. 

    Therefore, barriers remain between business, development and IT, which fragments decision making and introduces risk. In a recent IDC BizOps report, analysts share that “Alone, Agile and DevOps provide great advantages at the project level but lack an enterprise and strategic context: your organization might be building things faster, but not building the right things.” 

    As your modern dynamic environments continue to grow more complex, the lack of alignment between technology investments and business objectives only continues to grow more critical and costly. 

    What is BizOps?

    To meet their agility imperatives, technology and business leaders are adopting an emerging methodology called BizOps. Like DevOps, BizOps is an approach, not a product or technology. BizOps is a framework for optimizing software development and delivery to foster the achievement of business objectives. 

    IDC analysts define BizOps as a data-driven decision-support mechanism that connects business and technology functions together to drive business outcomes. 

    The Obstacles and Requirements

    Teams that employ BizOps practices need to create a data-driven decision support mechanism that connects business and technology functions together to effectively achieve desired business outcomes. This isn’t easy: Enterprise leaders that look to pursue BizOps objectives are stymied by organizational silos. The result is that the data required is also locked in silos—stifling collaboration, insights and innovation. 

    In a blog post, Andreesen Horowitz shared that, to overcome these obstacles, teams need to take a new approach: “To support this new style of decision-making, organizations need to store, analyze and report on data in a fundamentally different way.” 

    Teams need to adopt new AI and machine learning technologies that augment and even automate decision making within a BizOps framework. Through this approach, enterprises can establish the continuous insights and collective intelligence that optimize decision making. In these emerging BizOps environments, decision making sees fundamental transformation, growing increasingly event-driven and automated.

    The Payoff

    BizOps joins technology and business functions to improve an organization’s ability to speed and optimize digital transformation. Through BizOps, your teams can ensure that digital infrastructures and software provide the operational characteristics—including speed, scale, efficiency and agility—that business services require. 

    By successfully employing BizOps, your teams can build a new level of transparency, traction and trust that drives collaboration across departments. Through BizOps, your teams can apply maximum resources and efforts to achieving vital business outcomes, such as boosting business growth, enhancing the customer experience and increasing profitability.

    — Kieran Taylor