Tag: integration

  • 2024: The Year of Testing

    2024: The Year of Testing

    Caveat: I currently cover DevOps – including test – and security – including the *AST. This does give me a viewpoint that others may not have, and also potentially gives me blinders that others may not have. I am not generally a predictor but a reader of direction. Proclamations like this are rare for me and are shorter-term/more tactical than the grab bag of predictions usually seen this time of year.

    I was thinking about this one this morning; the direction of travel of traditional and security testing is very similar at the moment. We are seeing the vast complexity of the overall space and the rapid growth of automation come together to once again make all testing a topic worthy of consideration.

    I loved test-driven development (TDD). I can’t speak for others, but RPC/API is just a cool way to implement centralized functionality, and TDD is almost mandatory to develop APIs and the clients that call them. There is no UI to distract or have separate requirements in API development; there is a stated function and correct or incorrect behavior. To a computer scientist, this is predictable beauty. TDD made it more than predictable—it made it a trail through the woods. “We know it needs to do X, Y and Z, with the only side effects being A,” can be detailed with tests to prove that is what it does, and then look to prove the “It doesn’t have other side effects” part. And you can do it all while developing—no need for dev/test iterations. Like any IT solution, it isn’t a great fit for everything, but even if it isn’t called TDD, it is nearly impossible to develop API-based solutions without some level of TDD.

    The thing is, TDD is absolutely a developer’s tool. Developers and DevOps pretty much must use it to turn out usable APIs. The test team only has a use for a subset of those tests. Because if the dev team did it right, they passed all the TDD tests, and the test team’s role in that scenario is to look closely at what the developers might have missed. Integration is often beyond the control of an individual dev and/or API, for example, because many different clients may be integrating with it. Test teams, in a true TDD shop, fill the gaps with meaningful tests that evaluate the overall application quality.

    Security testing—at least static application security testing (SAST) and increasingly dynamic application security testing (DAST)—are also becoming a core part of the development process. This is as it always should have been. It is far easier to fix a security flaw (or any flaw) at the design/early code stage than in a testing process after deployment. The quality of security testing inputs is also increasing, making it far more viable. And finally, the tools are being effectively integrated. Being a developer who did a lot of security work because we often needed it and had no one to do it, I will say I get a little rush about being told right in my IDE about the security risks in my code. I write, I see, I revise where necessary, and I turn out better code. All without having to pause for security or bang heads over policy.

    To date, all this testing is separate, but I suspect, having vaguely the same location in the process of development, that testing will all occur together and the markets may even start to merge a bit—though merger of security testing and functional/performance testing tools is a bit of a stretch, it is more possible than in the past. In most orgs, even though developers have an increasing stake in both sets of testing, the target purchasers are still two different groups—security versus test—with different priorities. That’s why I think they aren’t likely to merge any time soon.

    While AI in most technology spaces is currently experiencing the same level of FUD as XML, Java, JavaScript or low-code was in the past, all super-hyped tools in tech do have a sweet spot. Security and testing are in that sweet spot for AI. Both in test generation and in results evaluation, it does it better, faster and with more coverage while giving staff a concrete set of results to pore over and improve security posture and/or code quality. I cannot say loudly enough that in terms of enabling the steps in the SDLC that have suffered from a lack of resources and timeline to write, execute and evaluate tests, AI is a game-changer.

    So, all of these things together mean that 2024 is a good time to take a hard look at your testing environment(s) and architecture, both traditional testing and security testing. Now that AI has made advanced automation a fact, it is time to consider implementing the level of testing we always knew we should have but never had the resources. Build it right into the build process and make it part of the organizational DNA—just like Agile is.

    If you could hire a specialist who would paw through your code and give you a list of the 25 things you need to fix first, you would do it. That is, essentially, what modern testing tools are. They can do more tests, evaluate more issues and side effects and filter down to the “No—this is really important!” list without costing the team a ton of time.

    And keep rocking it. We’re all sitting on bugs and vulnerabilities. I do hope we are way past denying that fact. Apps are big old complex monsters; these days, sometimes built from generations of technologies cobbled together. Of course they have issues. Even yours. So let’s take steps to clean it up, just a little bit. And keep clipping along.

  • Atlassian Strengthens Jira Navigation and Integration

    Atlassian Strengthens Jira Navigation and Integration

    Atlassian today made it simpler to navigate the Jira Software and Jira Work Management project management applications as part of an ongoing effort to make it simpler for DevOps teams to collaborate with other stakeholders of application development projects.

    Megan Cook, head of product for Atlassian, said the ability to share release dates across multiple calendars, overviews that aggregate views of and summarize multiple projects along with command palette and importer tools make it simpler for, for example, marketing teams and other individuals outside of a DevOps team to keep track of application delivery schedules.

    In addition, Atlassian has tightened integration between Jira and Confluence, a wiki-based collaboration application, and a previously launched Atlassian Intelligence capability that infuses generative artificial intelligence (AI) capabilities will also soon be added to Jira Work Management alongside existing support for Jira. There will also be connectors for Jira Work Management to integrate with Atlassian Admin, Atlassian Analytics, Access and Data Lake offerings, along with advanced security features.

    Finally, Atlassian is adding support for a design tool developed by Figma that can now be directly installed in Jira.

    Collaboration between application development teams and the rest of the business is becoming more crucial as organizations increasingly realize how much they depend on software to drive revenue. One of the primary reasons Atlassian is investing in generative AI is to make it simpler for anyone to understand the status of any given project and the downstream impact any change to a delivery schedule is likely to have.

    Generative AI, of course, has already moved from being considered advanced technology to a set of capabilities that most end users will soon expect to be embedded within every application. One of the primary benefits generative AI provides is it makes a range of applications originally designed for specialists, such as a software engineering team, more accessible to a wider range of end users.

    It’s not clear how much generative AI will change the relationship between DevOps teams and the rest of the business, but with increased visibility, there should be a greater appreciation for the challenges developers and DevOps teams face. Any member of an organization should be able to plainly see, for example, why more resources need to be allocated to a specific project to ensure that an application is delivered on time.

    At the same time, application developers will find project management processes are about to become less disruptive as it becomes simpler to automatically import relevant data from the tools and platforms they use directly into a project management application such as Jira.

    One way or another, software engineers should expect that as generative AI continues to evolve, the divide between them and the rest of the business will narrow. There may be times when that level of additional scrutiny may feel burdensome, but on the whole, it should make it easier for DevOps teams to get the resources required to achieve any given goal. After all, the root cause of any given delay to a project will soon be plain for anyone to see.

  • Google Announces Availability of iPaaS Service

    Google Announces Availability of iPaaS Service

    Google today made available an integration platform-as-a-service (iPaaS) capable of invoking a range of methods to integrate applications.

    Initially developed for the Apigee application programming interface (API) management platform Google acquired in 2016, the Application Integration service can now, for example, also consume a publish and subscribe event or an event driven through a Salesforce platform.

    Amit Zavery, vice president and general manager for Google Platform, said the Application Integration service provides IT organizations with all the benefits of an iPaaS without requiring them to stand up and manage an integration platform themselves.

    The Google Application Integration service also provides access to a Visual Integration Designer tool that can be used to build workflows using a low-code tool. In total, there are now more than 75 connectors that can be used to integrate multiple Google Cloud services and third-party platforms that can run in either a cloud or on-premises IT environment, said Zavery.

    In general, visual tools are transforming how integrations are created and expanded within organizations, noted Zavery. Rather than using lower-level procedural code, a visual tool enables developers to employ low-code to create integrations. That makes it simpler to collaborate with business users that can now more easily participate in developing workflows.

    In fact, in some cases, business users, otherwise known as citizen developers, have enough technical acumen to create their own workflows using low-code tools.

    There are, naturally, going to be plenty of complex integration challenges that will require procedural code, but the bulk of the integrations required today are not especially complex.

    Regardless of who creates the integration, the number of them being employed across an enterprise organization continues to increase as more digital business transformation initiatives are launched. Developers are not going to be able to keep pace with the demand for those integrations if they rely solely on procedural code. The only way to effectively reduce the backlog for integrations is to rely more on visual tools to construct them. In most cases, the integration being created is relatively trivial. The only reason it wasn’t created sooner is there are not enough developers available to complete that task using procedural code.

    There are, of course, no shortage of iPaaS options available. As more workloads are deployed in the cloud, Google is betting the center of gravity for integration will shift toward the places where modern microservices-based workloads are deployed to reduce overall latency.

    It’s not clear whether organizations still view integration as an afterthought versus employing an integration platform around which all applications revolve. That latter approach tends to reduce the total cost of integration when compared to using multiple point products that are not managed via single framework, noted Zavery.

    Ultimately, IT teams that adopt an iPaaS are able to focus more on higher-value IT tasks. The issue is determining which integration projects really require professional developers with lots of integration expertise and which, via a low-code tool, can be handled by almost any developer.

  • Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere Adds Professional Services to Jumpstart Observability

    Chronosphere has added a professional services capability through which it will provide the resources and expertise needed to deploy and manage its observability platform.

    Ian Smith, field CTO for Chronosphere, said the Chronosphere Quick Start program will make it easier for organizations to transition away from legacy monitoring tools that only track a set of pre-defined metrics and embrace an observability platform that enables DevOps teams to surface issues before an IT environment is disrupted.

    The scope of the services provided spans everything from data ingestion to providing training so that management of the Chronosphere observability platform can eventually be handed over to an internal DevOps team.

    The professional services team will also guide DevOps teams through setting up data control mechanisms and retention polices in addition to crafting dashboards to monitor specific processes.

    Finally, there’s also a self-paced online learning platform, dubbed Chronosphere University, that provides a comprehensive curriculum to help DevOps teams navigate fundamentals, advanced features and best practices.

    It’s still early days as far as the adoption of observability platforms is concerned. But it’s apparent that as application environments become more complex, the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest technical obstacles are deploying and configuring the platform, loading data and managing the cost of storing all the data that is collected.

    In addition, DevOps teams also need to understand what queries to launch to investigate specific issues. Many DevOps teams lack the expertise required to frame those queries today, but it’s expected that machine learning algorithms and other forms of artificial intelligence (AI) will automatically identify issues that might lead to disruption.

    In the meantime, DevOps teams should be evaluating where it makes sense to continue to rely on monitoring tools. In many instances, an observability platform might obviate the need for that tool, but there may also be plenty of instances where a simple monitoring tool is sufficient for the task at hand.

    One way or another, however, more advanced observability capabilities will be needed as application environments continue to become more complex in the cloud-native era. Application environments now consist of a mix of monolithic and microservices-based applications that gain more dependencies with each passing day. An application may not be as prone to crash as it once was, but determining the root cause of a performance issue can still take weeks given all the dependencies that exist between various services.

    Regardless of approach, observability has always been a core tenet of DevOps. As organizations’ DevOps maturity increases, the greater the appreciation for it becomes. The challenge has been that observability is one of many DevOps things that are easier said than done.

  • The DevOps Journey: Continuous Mindset Starts With Cultural Change

    The DevOps Journey: Continuous Mindset Starts With Cultural Change

    DevOps is not just about technology. In many ways, the technology aspect of DevOps is finite but the people, organizational and cultural aspects are infinite. We see many clients get so focused on the tools and technology that they forget about the impact beyond the technology. An important part of building a world-class DevOps process is understanding the cultural and organizational changes that are required to be successful and making those a priority, as well. 

     Many organizations have still either not started their DevOps journey or are in the first generation of DevOps, which is creating a greater gap between elite and low performers. The business changes and delivery cycles are coming faster than ever, making it critical to use world-class DevOps. Pushing toward continuous flow requires technical, process, people and cultural evolution to keep pace. To achieve continuous flow, we need a continuous mindset. A continuous mindset requires new skills, new ways of thinking, new cultural norms and new responsibilities.

    Continuous Mindset, Continuous Flow

    Most companies don’t realize the cultural impact a fully automated pipeline and continuous flow will have on development and operations (and beyond). Change can be difficult and organizations are often met with FUD: Fear (automation brings fear that jobs will be automated away), uncertainty (the unknown creates anxiety) and doubt (needing to employ new skills and new ways of thinking can create doubt about whether resources can adjust).

    The rapid pace of business change requires more nimble, flexible and lean approaches to DevOps to meet tomorrow’s demands. This requires changes to structures, interactions, control, processes and expectations. All of these impact the culture and connections within the organization.

     Let’s start by defining a few terms:

    Continuous integration: The practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term in 1991, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day—perhaps as many as 10 or more times per day. Common continuous integration practices include maintaining a code repository, automating the build, making the build self-testing, testing in a clone of the production environment and more.

    Continuous Delivery: The official definition is, “A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing and releasing software with greater speed and frequency. The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”

    Continuous Deployment: A strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users. The logical next step after continuous delivery: Automatically deploy the product into production whenever it passes required validations.

    Continuous mindset is intertwined throughout all three of the above approaches. To reach the maximum value in each area, a continuous mindset needs to be enabled, matured and applied to disciplines in other DevOps areas. The changes are across people, processes, technology and culture. Like DevOps, gaining a continuous mindset is a journey that will take time, many steps and constant learning.

    Continuous mindset changes the way people achieve outcomes for your business. This requires an emphasis on changing the way people think at every level of the organization, the way people are connected and the way they work. Achieving true continuous mindset ROI requires significant cultural adoption and collaboration. A key component is leveraging strong organizational change management (OCM). Six OCM steps to achieving the cultural shift to a continuous mindset include:

    • Change management and readiness: Share with internal stakeholders where we are going and how we are going to get there. Set expectations.
    • Sponsorship: Create clear alignment and engagement at the executive level.
    • Stakeholder engagement: Get everyone on board. Identify who is impacted as well as who is responsible and accountable. Understand reactions and resistance and provide support.
    • Communication: Get the right information to the right people at the right time. Move stakeholders from awareness to buy-in, commitment and readiness. Communicate messages to multiple levels of the organization.
    • Capability development: Provide the education and training needed to be successful in the new culture.
    • Organizational alignment: Align roles, structure, processes, policies and systems with changes and desired business outcomes.

    Shifting Responsibilities

    Ultimately, a continuous mindset changes the organizational engagement model and requires organizations to align on how and when they will work together. This requires shifting responsibilities and empowering teams/individuals to contribute to the improvement of DevOps capabilities. Learning and knowledge transition is an important element to enabling the team long-term.

    The organization will need coaching as they begin to understand the concepts and adjust the way they work. Different approaches can be used depending on the overall needs. This purposeful DevOps learning approach will provide DevOps coaches to engage with teams along with DevOps subject matter experts to provide input in the preparation activities. Another option is to provide less formal DevOps coaching to engage with targeted teams. This approach is less structured and primarily relies on direct engagement with less focus on the training and scaling project approach.

    Transparency is Fundamental to a Continuous Mindset

    Part of creating a continuous mindset involves an environment where transparency is fundamental; where everyone feels committed to the results takes ownership and responsibility for improving them. Successful DevOps transformation requires a holistic approach that includes people, processes, technology and culture. Working in cross-functional agile teams; working with small batches; working in sprints; communicating and collaborating all provide the strong foundation necessary to create a solid continuous mindset. If done correctly, breaking cultural changes down into smaller changes can ensure a certain level of quality in the long term. 

  • How Integration Can Keep Up with Digital Demands

    How Integration Can Keep Up with Digital Demands

    Integration holds the key to accelerating innovation, but in many organizations, business systems and application integrations haven’t kept up with the demands of digital. Data still exists in a siloed blend of on-premises systems and unconnected cloud applications, and IoT has added another layer of complexity into the mix.

    Understanding the three trends below, and how to leverage them, will help organizations continue to drive innovation for years to come.

    The Rise of the Integration of Things

    It’s no secret that the adoption of IoT is increasing, generating massive amounts of data from devices and sensors. As the number of devices increases in response to the explosive growth of IoT, the amount of data increases exponentially. This explosion of devices–and its associated data–is driving the need to leverage that data for the benefit of the business, such as improved customer experience, cost and downtime reductions or efficiency and productivity gains.

    Integration is the key piece that will enable businesses to get control of this data and put it to work. Without the right integration tools, it’s only possible to leverage IoT at specific levels. Essentially, integration provides the ability to connect the data from IoT devices and enterprise applications, orchestrate workflow and enrich IoT data with contextual information from other systems for better decision-making.

    Organizations can even use integration to link IoT platforms together for a comprehensive view of data, analytics and actions–making it easier and quicker to analyze, draw conclusions from and determine how to use the data. On top of this, they can also create complex and sophisticated responses when something goes wrong by leveraging automated integration workflows.

    As we continue to connect our devices, the Integration of Things will be as important as the Internet of Things.

    Blurred Lines Between Application Development and Integration

    For cloud applications to survive and thrive, they require built-in integration with other apps and data sources. Otherwise, users are constantly switching contexts from one tool to another when trying to complete a task, and content is scattered across the organization in multiple applications and departments. Because of this, the lines between application development and integration will blur as apps are compelled to have integration embedded under the covers.

    There will be many benefits to this. First, organizations will easily create and deploy integrations directly within their products, fully baked into the user experience. These in-app integrations to third-party sources will unlock additional capabilities for users, empowering them to do more.

    Second, building integrations without the right tools and specialized integration know-how requires a lot of work. Embedded integration eases the pain of monitoring API changes and documentations so that maintenance is smoother and cheaper.

    Finally, business services can involve complex interactions with cloud apps and data that require ordering, have dependencies or may even need to be reversible on demand. Organizations can handle these sophisticated jobs by leveraging advanced integration orchestration to manage app interaction–meaning that instead of using manual code for complex data mapping, they can create a visual drag-and-drop data flow. 

    AI Powers Smarter APIs

    Businesses have already been leveraging intelligent automation to improve operations, drive innovation and personalize the customer experience. As we head into the new decade, API management will harness the power of AI with innovative ways of protecting and controlling APIs and the applications they serve.

    Service mesh, an increasingly popular way of discovering and observing services in distributed networks, will evolve into app mesh, an application-aware model of monitoring, managing and securing your APIs. API policies will be able to reconfigure dynamically based on traffic, security threats and identified patterns. Additional layers of defense will come from bots deployed in an organization’s network to constantly monitor behavior and these bots will use machine learning to improve automated threat responses for APIs.

    The integration landscape is changing, but understanding how to harness these trends will ensure organizations are well-equipped to take advantage of evolving technologies for innovation.

    — Ann Marie Bond