Tag: DevOps framework

  • Why an Embedded Analytics Maturity Framework is Essential

    Why an Embedded Analytics Maturity Framework is Essential

    Contextual analytics, or embedding analytics directly into a business application’s transactional environment and core workflows, is the most sophisticated stage of business intelligence (BI) currently available to organizations today. It is one level ahead of the traditional integration of analytics, which is a standalone capability presented as a separate dashboard or reporting module.

    Today, there is an increasing shift among organizations toward embedding transactional analytics into their enterprise applications. Because contextual analytics is the most advanced option in the market, there is also an increasing need for assessing our analytics readiness first.

    The fundamental difference of contextual analytics lies in how it offers analytics to the user to explore data or derive insight within their transactional environment rather than accessed as an external tool. This approach requires a deeper evaluation of the product’s analytical maturity level using a formal framework. Having such a framework can act as a deployment guide for your developers for every stage of embedded BI implementation, including contextual analytics.

    But first, what makes contextual analytics so different that it necessitates a readiness evaluation?

    Contextual Analytics Vs. Embedded Analytics

    With contextual analytics, dashboards, reports and charts are no longer separated but are part of the main user experience. This integral change necessitates a closer look at your data and integration capabilities to align what it brings with all aspects of your software, including existing analytics.

    Embedding these elements directly into core software workflows isn’t a replacement for any existing analytics, but is instead another big step toward making data and analytics a more seamless part of your end users’ everyday work.

    It should be stressed that contextual analytics accommodates various levels of implementation and business requirements. Analytics can be embedded lightly, such as in the form of basic in-line charts and graphs users can see as they explore your software, or embedded deeper to offer AI-assisted insights and real-time alerts that trigger action from users while they work. It can be integrated with an experienced BI vendor partner or in-house if you possess the skill set internally.

    Avoidable Pitfalls of an Improvised Approach

    The need to assess your application’s analytical maturity and readiness for embedding analytics directly into the transactional workflow comes down to avoiding unnecessary BI roadblocks. 

    For many organizations, BI and analytical capabilities are traditionally lower in priority than other aspects of the software. Intending to add BI features later is well-meaning and understandable, but leaving developers to add in features intermittently and leaving it to your users to demand them when needed creates an issue of visibility. Vendors typically lose sight of what their application currently is capable of analytically, or what development needs to make the addition of a new feature not only technically achievable but worth the time and cost investment.

    If you take the time to reassess your application’s analytical capability, your developers and leaders can better understand that your product could be at an earlier stage of readiness than previously believed, and prepare accordingly before seeking out a contextual or other BI solution.

    For example, approaching contextual analytics ad-hoc could mean you find an unexpected older dashboard module, a cost that could have been accounted for in a formal maturity assessment. 

    What it comes down to is this: Implementing a basic dashboard module or data export feature, completely separate product features, is fundamentally different from fully embedded analytics in your users’ core workflow experience. Pursuing a formal evaluation to guide the introduction of contextual analytics—or even a form of embedded analytics at an earlier stage—means your users and product receive the best type of analytical capability your business is ready for today.

    The Five Stages of Embedded Analytics Maturity

    Based on our experience, there are five possible stages of product development, as illustrated in the embedded analytics maturity curve below. As contextual analytics is the final, most advanced stage of an embedded analytics integration available to product owners, the need for a formal assessment of maturity is most important, should it be the target state.

    Accelerating the implementation of contextual analytics comes down to your skillset, which will allow you to identify and evaluate your state of readiness accurately and determine a BI solution’s flexibility. If you do not have the internal expertise, implementing contextual analytics is easier with the help of specialized BI vendors that can help you in your assessment, and offer a contextual analytics platform built around openness. We recommend you look for vendors and partners that allow for:

    • Advanced APIs that lower total integration time and ensure the need to rearchitect the software is minimal to zero.
    • Customized experiences to make your desired contextual linkages, such as showing a user a relevant embedded chart when they click on a table of a client, possible.
    • An open platform that allows for options for on-premises, cloud, multiple operating systems that guarantee long-term security, scalability and flexibility with your analytics.
    • Rapid adaptation to your product development roadmaps with automated processes and administrative tools to lower total cost of ownership
    • White-labelling to make the rebranding and blending of the analytical solution and your native application components seamless.

    Ultimately, having an awareness of your product’s readiness and taking the time to examine your application’s current state means you avoid costly integration mistakes, save time and ensure developers implement the best solution according to your exact needs now.

  • Micronaut Taps Moderne to Automate Java Framework Updates

    Micronaut Taps Moderne to Automate Java Framework Updates

    Micronaut, a provider of a framework for building applications based on microservices and serverless computing platforms, today revealed it is allying with Moderne, a provider of a tool for refactoring code, to create a “recipe” that will automatically update the Micronaut framework.

    Moderne CEO Jonathan Schneider said the open source OpenRewrite refactoring tool for code, originally developed at Netflix, makes it possible to automate updates to codebases, remediate vulnerabilities and provide a foundation for high-level building blocks that will make authoring custom transformations simpler. That approach will eventually be embraced by other providers of application development frameworks.

    Fresh from raising $4.7 million in initial funding, Moderne makes OpenRewrite available via a software-as-a-service (SaaS) platform to enable IT teams to search and transform millions of lines of code in minutes. OpenRewrite currently supports Java, but the company is working toward adding support for additional languages, including infrastructure-as-code (IaC) tools such as Kubernetes, YAML and XML.

    Moderne has also developed “recipes” for common search and refactoring operations that can be assembled into more complex recipes for framework migrations involving, for example, an upgrade from Java 8 to Java 11. Micronaut is the first provider of a development framework to create a recipe for its own framework using OpenRewrite.

    At a time when applications are more distributed than ever, updating codebases is a major challenge. In fact, the manual effort involved in making those migrations is one of the primary reasons many organizations continue to employ older versions of frameworks such as Java 8. OpenRewrite is designed to automate that process at scale in a way that leaves it up to the individual developer to determine how involved they want or be or if they simply prefer to have a DevOps team manage the upgrade process on their behalf, said Schneider.

    In the longer term, Schneider said he expects recipes will be created to address everything from mass migrations to remediating specific types of vulnerabilities across an entire codebase.

    Too much reliance on legacy development frameworks generally stymies innovation. The latest versions of Java, for example, are designed to make it simpler for developers to build microservices-based applications.

    It remains to be seen to what degree DevOps teams will embrace automation to upgrade code. Many developers are hesitant to rely on automated tools of any kind. However, given the need for most developers to spend more time writing new code, it’s only a matter of time before most of them come to terms with automated approaches to updating existing code.

    In the meantime, the cost of supporting legacy frameworks should decline as organizations begin to migrate their codebases faster. One of the reasons there is so much technical debt in the enterprise is because different development teams tend to adopt different framework versions at different times. DevOps teams can find themselves being asked to simultaneously support multiple versions of the same framework. There may always be multiple versions of those frameworks, but, over time, DevOps teams should eventually see the bulk of deployed applications all using the same framework as the upgrade cycle becomes more automated.

  • Cycloid Brings Open DevOps Framework to the US and UK

    Cycloid Brings Open DevOps Framework to the US and UK

    Cycloid, a Paris, France-based provider of an open framework for implementing DevOps best practices, today announced it is expanding its operations into the U.S. and United Kingdom.

    Benjamin Brial, founder of Cycloid, said the Cycloid framework provides a lightweight approach to striking a balance between enabling developers to employ the tools they prefer and the need for centralized governance. The framework allows roles and policies to be pre-defined to ensure governance while service catalogs are used to deploy software using a set of drag-and-drop visual interfaces. There are also a set of management tools and features that provide additional visibility, automation, monitoring and financial controls to DevOps workflows.

    In effect, the portal that Cycloid provides to manage those workflows also serves to make DevOps more accessible to a wider range of IT professionals, added Brial.

    Cycloid

    Many organizations that embrace DevOps wind up building their own custom portal to achieve that same functionality. Rather than devoting resources to building and maintaining such a portal, Brial said Cycloid maintains and updates a portal platform that can be employed across any combination of tools that developers prefer. Other DevOps frameworks are often rejected because they require developers to adopt a specific set of tools, noted Brial. Without support from developers, it becomes nearly impossible to adopt DevOps best practices at scale, he added.

    After more than a decade of advocacy, adoption of DevOps within most organizations remains spotty. A significant factor in the lack of adoption is cultural issues involving skillsets. Many IT administrators lack the programming skills required to programmatically manage DevOps workflows. Cycloid is trying to establish a middle ground that enables IT operations teams to manage and govern DevOps workflows without having to acquire programming skills. The goal is to make it simpler for developers and IT operations teams to collaborate, said Brial.

    It’s not clear to what degree such an approach might increase adoption of DevOps best practices within enterprise IT organizations. However, it’s already apparent that the cost of hiring and retaining, for example, a small army of site reliability engineers (SREs) to manage IT environments at scale is often cost-prohibitive for many organizations.

    There’s no shortage of DevOps frameworks, but most organizations generally wind up crafting their own as part of an effort to tailor a DevOps workflow to meet their specific requirements. However, if there is a readily available framework that is highly customizable, Cycloid is betting more organizations would rather buy than build and maintain the entire framework themselves. Otherwise, DevOps teams would spend half their time performing the same repetitive manual tasks over and over, said Brial.

    One way or another, DevOps as a methodology for building and deploying applications needs to become more accessible. Proponents of DevOps have made a case for the methodology for the better part of a decade, with mixed success. The challenge continues to be finding a way to scale DevOps processes across the entire enterprise versus allowing each individual development team to define application development and deployment processes that, today, vary widely in terms of efficiency.