Tag: APIs

  • WSO2 Advances Microservices Gateway

    WSO2 Advances Microservices Gateway

    At the Open Source and Software Development Conference (OSCON), WSO2 this week announced it has updated an open source microservices gateway to make it possible to expose multiple microservices through a single application programming interface (API).

    Additionally, version 3.0 of the WSO2 API Microgateway now includes the ability to automatically discover microservices and transform legacy API requests into a more modern format. WSO2 also added support for the OpenAPI Specification (OAS), formerly known as Swagger, to make it easier for developers to collaborate on creating APIs, and has separated the WSO2 API Microgateway toolkit from the runtime to enable greater scalability and smoother upgrades.

    Ken Oestreich, vice president of product marketing for WSO2, said the WSO2 API Microgateway is designed to accelerate the convergence of application development and integration into a single team. As part of that effort, WSO2 has been advocating the adoption of Ballerina, a general-purpose programming language designed from the ground up to make it easier for developers to integrate distributed applications on their own. For example, Ballerina makes it possible for developers to create and embed their own micro-enterprise service bus (ESB) within a distributed application, he said.

    Those integration engines then could be deployed and updated within any DevOps processes layered on top of a continuous integration/continuous deployment (CI/CD), Oestreich added.

    A WSO2 API Microgateway is designed to boot up in less than a second and provides authentication, authorization, rate limiting, service composition, discovery, transformation and analytics capabilities. It is designed to be integrated with the WSO2 API Manager, an open source API management platform that can run on-premises or in the cloud.

    As the number of microservices being created within organizations increases thanks to the rise of containers, Oestreich noted there is now a critical need for organizations to find a lightweight approach to building and managing all the APIs required to connect thousands of microservices. WSO2 provides a flow diagram through which organizations can visually manage that process, said Oestreich. As part of its support for containers, the WS02 API Gateway provides built-in support for container orchestration tools such as Kubernetes, which makes it possible to generate artifacts that can be applied directly to Kubernetes clusters.

    Organizations of all sizes are clearly struggling these days with API management. In theory, APIs should remain stable as the software components they connect to are updated. The trouble is, each new microservice generates its own set of APIs, and before too long, organizations find themselves trying to manage thousands of APIs that are all dependent on each other. The removal of any one API might not crash an application, but it could adversely impact performance as API calls are re-routed around the application.

    It’s not all clear these days who inside most organizations is responsible for managing APIs. Developers certainly create the APIs. However, once they are deployed in a production environment, their care and feeding often pass over to an IT operations team. Regardless of whom, however, once any of those APIs break it’s not long before the entire DevOps team knows about it. The challenge now is figuring out how to make the management of all those APIs as natural an extension of a DevOps process as possible.

    — Mike Vizard

  • Citizen Developers Drive Productivity and Innovation

    Citizen Developers Drive Productivity and Innovation

    It was once written that “software is eating the world,” “APIs are eating the world” and “APIs are eating software.” In 2019, a more accurate statement might be, “APIs (or application programming interfaces) fuel the software that’s still eating the world.”

    In today’s world, there is an ever-constant demand for software, enterprise applications and mobile applications, and most company IT departments can’t keep up. Enter the citizen developer. Citizen developers are helping organizations close the demand gap and innovate more quickly. But who are they and what role do they fill within an organization? And how do they contribute to overall technology innovation within a company?

    Citizen Developers and the Need for Speed

    The ongoing need to develop software quickly and efficiently has given rise to a new type of developer. A citizen developer is a non-professional developer who builds new business applications using existing tools, development and runtime environments sanctioned by corporate IT. They also can access various online tutorials to learn and master their application-building skills.

    Today’s software development environment, powered by APIs, is ripe for the citizen developer. APIs, mobile application development kits and the cloud have created a no-code/low-code, building block-like approach to building software. Less code and a more simplistic software development path allow citizen developers to create much-needed apps quickly. This building-block approach cuts development time, translating to faster time-to-value.

    Speed is critical not only in the creation of new apps, but also in the end user experience of these apps. With the building-block model, citizen developers use best-of-breed technologies for each block—making the resulting UX optimal (and fast) for an internal user or customer end user. Internal users are able to use fast, effective search within employee directories, company intranets and project management solutions, for example.

    For end users, this need for speed addresses their ever-growing expectations. When someone searches for hotel deals in Phoenix, for example, they expect accurate, personalized and fast results. Even a one- or two-second delay can translate to lost opportunity and revenue.

    The Workplace

    In the digital workplace, citizen developers serve a key purpose. For starters, they know firsthand about the challenges employees face at work; they also know which applications or tools are critical to getting the job done. These non-IT developers (perhaps in a business or marketing role) help create apps for timesheet entry, productivity tracking, project workflow reporting and more. In one study, 76% of businesses stated that at least some of their apps were developed outside of their IT department—and 20% even stated that most of their applications were created outside of IT.

    Citizen developers often use low-code tools or visual tools with some degree of coding required. Low-code allows developers to design and develop software applications with minimal hand-coding, while low-code platforms enable users to build applications with modern user interfaces, integrations and data quickly without writing thousands of lines of complex code. Also, citizen developers may work alongside software developers and database experts to develop apps with custom coding to meet specific enterprise or company needs.

    Citizen Developers and IT: Working Together

    When citizen developers work alongside IT, two things happen. First, by creating simple apps on their own, they enable IT to focus on developing more complex applications. Second, when building more complicated or customized applications, IT can use citizen developers to derive valuable insight. This data helps with testing or tweaking business app prototypes. With low-code, citizen developers with some technical skill start with a prototype and then can iterate with the IT team during the developer phase and later integration of systems, custom coding and security processes. Also, developers, who are often asked to understand more of the business side of the organization, gain this insight working with workplace citizen developers. And the results are promising: 82% of citizen developers said they witnessed a reduction in inefficient tasks while 71% reported an increase in team productivity.

    In the past, IT spearheaded application development projects from beginning to end. Now, with citizen developers becoming an integral part of the workplace, IT’s role changes a bit. While no longer in full control, IT does give recommendations to the business department and selects development components and building blocks.

    Just the Beginning

    When it comes to search software, citizen developers have the potential to create personalized and customized experiences. While some types of front-end search are simple to create, developing a personalized and customized search experience is more complicated. This is where the current work lies and in doing so, we can build a new community of search-focused citizen developers.

    This is only the beginning, as there will always be a demand for developers (both traditionally trained and citizen developers). In the coming years, we will see more citizen developers as there literally aren’t enough engineering schools to train students to meet business demand. They are helping to democratize application and software development across the board—and we can expect to see businesses and consumers continue to benefit.

    — Julien Lemoine

  • Adobe Aims to Build Developer Ecosystem

    Adobe Aims to Build Developer Ecosystem

    Adobe today outlined an approach to building a developer ecosystem that revolves around open source code, application programming interfaces (APIs) and DevOps processes.

    Matt Asay, head of developer ecosystem for Adobe, said in the last few years Adobe has increased its reliance on open source code to deliver offerings such as Adobe Experience Manager, a content management system that incorporates open source code for as much as 65% of its modules. In the course of that effort, the company has made reciprocal code contributions to a variety of open source projects being developed under the auspices of the Apache Software Foundation (ASF), including Apache Sling, a web development framework; Apache Oak, a content repository; Apache Felix, an implementation of a services gateway; and Apache Lucene, a text search engine.

    Adobe also recently launched Adobe Experience Cloud, which relies on a variety of open source technologies to create a big data repository on top of which Adobe is encouraging developers to invoke APIs to build applications. Rather than build their own big data repositories, Adobe is making a case for relying on a multitenant big data platform it manages on behalf of customers.

    Based on GitHub data, Adobe currently ranks as the 14th largest corporate open source contributor, up from No. 32 in 2017. One of the primary reasons Adobe was able to move up that list so quickly was its move to acquire Magento, an e-commerce platform based heavily on open source code. But now that the company has come to appreciate what can be accomplished by relying on open source code, organizations should expect to see Adobe accelerating the rate at which it will be making contributions to a wide variety of open source projects.

    At the same time, Asay said, Adobe is making major investments in developing microservices that it plans to make it possible for developers to consume via its APIs. The Adobe Experience Cloud, for example, is a suite of software-as-a-service (SaaS) applications that employ a common data model deployed on a set of Kubernetes clusters running in the Microsoft Azure cloud.

    Asay noted Adobe is trying to make it clear that it has a lot of empathy toward developers committed to open source code. Adobe is a provider of commercial software-as-a-service (SaaS) applications, but it wants to develop a developer ecosystem that consumes the data residing in those applications via its APIs. To foster the development of those applications, Adobe has already signaled it is willing to share best DevOps practices with organizations that commit to invoking those APIs.

    Adobe is one of many providers of commercial software that are increasingly dependent on open source code. It will be interesting to see where the line between the desire to use open source projects to build applications and actual open source applications lies in the years ahead. But the one thing that is clear is that without DevOps processes and a well-defined set of APIs to guide them, there’s not much chance any vendor would be able to build a meaningful developer ecosystem of any size.

    — Mike Vizard

  • SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    SmartBear Integrates Test Tools with Atlassian DevOps Platforms

    At the Atlassian Summit 2019 conference this week, SmartBear announced it has integrated the Zephyr test automation tools it acquired last year with the Jira portfolio of tools from Atlassian.

    In addition, SmartBear announced it has integrated Zephyr with the rest of the company’s SoapUI Pro, TestComplete, CrossBrowserTesting and LoadNinja testing tools.

    SmartBear committed to integrating its entire portfolio of tools with other Atlassian offerings as well, including the Bitbucket continuous integration/continuous development platform and Confluence content management software.

    In general, SmartBear views efforts to modernize applications using DevOps practices as a primary driver of increased demand for tools to test application programming interfaces (APIs). A recent global survey of 3,000 API developers, architects, testers and product leaders conducted by SmartBear finds nearly three-quarters of respondents believe that adoption of microservice architectures will drive the biggest growth in API adoption in the next two years.

    The biggest challenge faced by well over half the respondents (58%) is finding a way to standardize API development. In pursuit of that goal, the survey finds 69% of survey respondents are now developing APIs that comply with the OpenAPI Specification (OAS). That specification defines a language-agnostic interface to RESTful APIs that enables both humans and computers to discover and understand the capabilities of the service without access to source code or documentation, or having to inspect network traffic.

    The SmartBear survey also finds 76% of respondents say they already have a formal API monitoring process in place and that 76% of organizations are developing both internal and public-facing APIs.

    Daniel Giordano, associate director of product marketing for SmartBear, said these days there’s a lot more focus on trying to make it easier to discover APIs whenever possible by setting up API catalogs. Those catalogs are also now making it easier for organizations to reuse APIs rather than develop new ones for each microservice that gets developed, he added.

    In fact, Giordano noted that many organizations now define the APIs they are going to depend on to integrate their applications long before they begin to write application code. Those APIs are then reviewed by an architecture team to make sure they meet performance requirements while still being flexible enough to evolve consistently with the other APIs the organization needs to maintain, he said.

    Today, organizations make use of many more private APIs than they do public ones. APIs first came into their own as a means to expose applications to enable external applications to consume data from another application as part of the so-called API Economy. Since then, the number of private APIs that organizations rely on to integrate internal applications has exploded. In fact, building and deploying those APIs has become an integral part of any DevOps process.

    Naturally, the relationship between API management and DevOps processes is still evolving. But as DevOps processes within IT organizations continue to mature it’s only a matter of time before they are applied equally to both the applications being developed and the APIs relied on to integrate them.

    — Mike Vizard

  • Salt Security Unveils Platform to Secure APIs

    Salt Security Unveils Platform to Secure APIs

    Salt Security, fresh off raising an additional $10 million in funding, announced a platform that promises to advance the state of DevSecOps by making it possible to detect when application programming interfaces (APIs) are being probed by cybercriminals looking for weaknesses to exploit.

    Salt Security CEO Roey Eliyahu said the Salt Security API Protection Platform employs machine learning algorithms to first establish a baseline for how APIs are being invoked across an IT environment. The software-as-a-service (SaaS) platform then monitors activity to surface any anomalous behavior indicative of cybercriminals engaging in reconnaissance of API traffic flows, he said.

    Armed with that analytics, DevOps teams can then prioritize fixes to any potential security hole cybercriminals might be able to exploit. That approach advances DevSecOps because the Salt Security technology makes it possible to feed requests to address those security issues directly into a continuous integration/continuous deployment (CI/CD) platform—critical, he said, because all too often developers are unclear regarding what cybersecurity professionals are asking them to fix whenever a cybersecurity issue arises.

    Eliyahu noted that, in today’s business environment, security has become a major concern. According to the Open Web Application Security Project (OWASP), nine of the top 10 vulnerabilities in its current Top 10 report include an API component. Insecure APIs were ranked as the third most severe threat to cloud computing in 2018 by the Cloud Security Alliance (CSA), and Gartner predicts that by 2022 API abuses will be the most frequent attack vector resulting in data breaches for enterprise web applications.

    The challenge organizations face is each API is unique to each application and the organization that builds them, which means each has unique logic and, by extension unique vulnerabilities, said Eliyahu. Existing cybersecurity tools lack granular understanding of these because they are designed to protect organizations from known attacks. Attacks that target API logic go unnoticed by these tools because they appear to be authenticated use cases, and then employ subtle methods to probe each for unique vulnerabilities, he noted.

    To thwart those attacks, the Salt Security technology automatically discovers all APIs and associated functionality, said Eliyahu. That’s important because it’s not uncommon for organizations to lose track of the many that might have been exposed over the course of an application’s lifetime.

    APIs in general are often overlooked because much of the focus in any organization tends to be on business logic. But as the number of applications and services continue to proliferate across the enterprise, the number of APIs being exposed has increased dramatically. Those numbers will increase more as organizations embrace microservices to build applications that are more easily updated.

    The issue, of course, is how to secure APIs that often are developed and maintained by teams that weren’t involved in the integration of the original application. Because of that issue, API management has emerged as a discipline unto itself within many organizations. The challenge now is finding a way to ensure those APIs are employed as intended, versus becoming an avenue for data exfiltration that no one is aware of until it’s long too late.

    — Mike Vizard

  • SAP Adds SDK to ERP Cloud Service

    SAP Adds SDK to ERP Cloud Service

    When most IT organizations think about DevOps it’s usually within the context of custom application development. But thanks to the rise of application programming interfaces (APIs), packaged applications are now becoming a much bigger factor. SAP, for example, just made available a software development kit (SDK) for SAP S/4HANA Cloud, an instance of its ERP software hosted in the cloud.

    Christian Pedersen, chief product officer for SAP S/4HANA Cloud, says the company is encouraging developers to integrate SAP and custom applications. The company is unable to address every potential use case on its own, he says, and it doesn’t make much sense for developers to reinvent functionality that already is an API in a SAP packaged application. The goal should be to deliver a unified application experience made up of packaged and custom components that all are accessed via a common user interface experience.

    That approach, he says, will be critical as SAP continues to invest in advanced machine learning algorithms and digital assistants. Rather than having to develop those technologies themselves, Pedersen says it’s going to be a lot more practical for many developers to leverage capabilities that SAP will expose via APIs.

    SAP’s approach to custom applications is unique in that it makes available a separate SAP Cloud service based on the platform-as-a-service (PaaS) environment developed by the Cloud Foundry Foundation and the Kubernetes cluster platform now overseen by the Cloud Native Computing Foundation (CNCF). The best part about the SDK, says Pedersen, is that it includes sample code that developers can reuse in their applications. As far as DevOps is concerned, SAP is not driving any specific approach, preferring to work with a variety of continuous integration and continuous delivery (CI/CD) platforms.

    Some developers have historically viewed SAP and other providers of packaged applications warily. There is a tendency for vendors that sell packaged applications to continually expand the footprint of their software. SAP isn’t promising not to expand the footprint of its applications further, but, Pederson says, when it comes to crafting a unified application experience aimed at specific use cases, the developer community is essential.

    The biggest challenge associated with combining PaaS environments with software-as-a-service (SaaS) applications is getting the updates to the respective environments synchronized. DevOps teams don’t have any control over when a SaaS application provider chooses to roll out new capabilities. In many cases, the pace at which the SaaS application provider delivers those updates often sets the pace for the whole DevOps teams. In some cases, IT organizations will prefer to run applications on-premises just to exercise more control over the upgrade cycle.

    Whatever the approach, there’s clearly greater need for more DevOps sophistication now that packaged applications have essentially become back-end services that are invoked as a service via an API. The first order of business toward achieving that goal, however, may be informing the owners of those applications they are now part of a much larger ecosystem that needs to be considered every time anyone wants to update a module or add a new service.

    — Mike Vizard

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • Break the Rules and Win at Digital Transformation

    Break the Rules and Win at Digital Transformation

    The rules of the game have changed.

    In today’s digital world, it’s not about the big eating the small. It’s the fast that beat the slow and the nimble that outmaneuver companies constrained by old systems and business models.

    What’s more, the finish line is always moving. The rapid pace of innovation and disruption means businesses must continuously transform themselves to stay ahead of competitors.

    The takeaway for CIOs: Speed and agility are the name of the game.

    IT must respond faster than ever to shifting business needs. To succeed at digital transformation, companies must rethink how they design, build, deploy and source enterprise applications. They must adopt new approaches that accelerate delivery and anticipate, even bake in, ongoing changes.

    It’s time to update the IT playbook. Here are five best practices from digital leaders that are breaking with the past to deliver a successful future.

    Accelerate and Iterate Software Delivery

    Digital leaders outpace their rivals by adopting methodologies and mindsets that shorten software delivery cycles. They’re also really, really good at rapid, iterative change.

    Shift to Speedier Methodologies

    Digital leaders rely on Agile development methods—short sprints, scrum teams and user feedback loops—to accelerate the design and development of new applications. With its emphasis on rapid iteration and continuous improvement, Agile methodologies are a proven way for companies to churn out new innovations quickly. Studies show Agile approaches average 50 percent faster time-to-market than waterfall ones.

    DevOps is also a catalyst for speed. Automation and tighter collaboration between development and operations make it easier to put new code into production. Led by such companies as Facebook, Google and Amazon, the world is moving away from “that 10-year-old solution everyone’s afraid to touch” to flexible platforms that are updated multiple times a day.

    Adopt an Agile Mindset

    Of course, being agile requires more than just new methodologies. It also demands a willingness to take risks, learn on the fly and adjust continuously. Digital leaders don’t just respond to change; they embrace and design for change.

    Digital leaders test and then invest. They fail fast and then swiftly course-correct. The most successful experiment rapidly and incrementally so if they do stumble, they fall from the first floor, not the 10th. Digital leaders also think big. They don’t just digitize current processes. They completely re-imagine business models and technology systems—as Pitney Bowes did with its transformation into a digital commerce powerhouse or as GE did with its launch of the Predix industrial IoT platform.

    Adopt New Application Architectures and Infrastructure

    Digital leaders are building in flexibility with new application architectures and deployment models. They’re leaving legacy systems behind as they take to the cloud with microservices-based solutions.

    Move to Microservices

    Monolithic applications are hard to change, costly to maintain and ill-suited to today’s dynamic business environment. That’s why digital leaders are moving to an agile, microservices-driven architecture. Converts include Netflix, eBay, Amazon, Twitter, Gilt, Liberty Mutual and the UK Government Digital Service, to name just a few.

    Assembling applications from small modular services—each a self-contained building block—allows digital leaders to transform quickly and at scale. They can mix and match services to fast-track new digital offerings and processes. They can tweak and scale services to adapt to changing business models and customer expectations. And they can push innovation across the enterprise by reusing services—all without adding armies of developers or getting locked into any one technology.

    Step Up Cloud Migration

    The cloud is increasingly the preferred foundation for digital transformation. Digital leaders gain speed and agility by plugging into on-demand services and computing resources. They short-circuit long design and procurement cycles; focus on innovation, not infrastructure; and deliver differentiated capabilities and customer experiences at a fraction of the time and cost.

    Digital leaders are betting big on the cloud. According to IDC, at least half of IT spending will be cloud-based by 2018, reaching 60 percent of IT infrastructure spending and 60 percent to 70 percent of software, services and technology spending by 2020. Organizations across industries—such as Nike, Xerox, General Mills, Liberty Mutual, and the U.S. federal government—have migrated mission-critical workloads to the cloud to support new, more digital ways of doing business.

    Use Novel, Unexpected Sources of Innovation

    Digital leaders rely on open-source innovators and third-party collaborators to shorten development cycles. They’ve also abandoned long RFPs in favor of shorter, more effective proofs of concept (POCs).

    Embrace Open Tech with Open Arms

    Open technologies—including open source, open standards and open APIs—dominate the digital landscape. According to a study by North Bridge and Black Duck, open source software makes up more than 50 percent of the typical enterprise and application stack. Digital leaders including Ticketmaster, Box, eBay and Goldman Sachs rely on open-source software to speed solution delivery and draft off the innovations of millions of developers worldwide.

    Digital leaders also innovate openly with others. They hold hackathons. They crowdsource. They co-create with customers and partners. They also contribute back to the community with projects such as Walmart Labs, Ericsson’s open-source hub and GE’s Industrial Dojo for the Cloud Foundry ecosystem.

    Say RIP to RFPs

    Digital leaders have pulled the plug on massive RFPs for complex, multiyear development projects. Instead, they favor faster, more flexible procurement processes that reward innovation and accelerate vendor selection. They conduct POC tests to evaluate alternative technologies. They use iterative prototyping to refine requirements and determine the best solution for the job. They keep their options open with shorter timelines and smaller deliverables.

    Digital success calls for a more collaborative relationship with technology providers. It’s the whiteboard sessions, technical conversations and joint problem-solving that yield breakthrough results. That’s why progressive companies now approach the RFP like a “request for partnership.”

    Integrate Data and Systems in Transformative Ways

    Digital leaders use open platforms and APIs to integrate information, people and processes across their extended value chain. These connections lay the foundation for faster business flows and new digital products and services.

    Connect Quickly with APIs

    APIs (application programming interfaces) enable diverse applications to connect and share data. Digital leaders use API-led integration to combine services and expose information in ways that deliver unprecedented customer and business value. Within days and without lots of coding, they can roll out service innovations, revamp internal processes, enliven customer interactions, extend their digital reach and enable entirely new business models.

    This year, 2017, has been dubbed the year of the API economy. ProgrammableWeb lists more than 17,700 APIs and hundreds of digital leaders are opening up their APIs so others can easily integrate and innovate with their technologies. API marketplaces from Mastercard, ADP, Ford and FedEx are just a few examples.

    Achieve Digital Flow

    Silos slow the flow of business. Disconnected processes, departmental barriers and gaps in information all impede speed and agility.

    Digital leaders excel at silo-busting. They integrate disparate systems. They connect processes from end to end, across all customer touchpoints and organizational boundaries. They use open platforms to ensure that information—structured data and unstructured content—flows to the right person, at the right time, in the right context.

    The seamless integration of information, people and processes allows digital leaders to be much more nimble and responsive. They can also leverage these connections to make huge improvements in customer experience—such as the bank that slashed loan origination steps by 70 percent or the insurer that processes claims 25 percent faster.

    Bring Business and IT Closer Together

    Digital leaders treat digital transformation as a partnership between business and IT, with a shared focus on meaningful outcomes and better experiences for customers and employees.

    Engage and Empower Users

    Digital leaders put people—customers, citizens, employees and partners—at center of their transformation efforts. They prioritize design thinking, a user-centric approach that shifts the focus from adding features to adding value. They take advantage of platform tooling to involve users in solution design and invest in dedicated UX teams to deliver better experiences faster. Capital One, for instance, regularly solicits customer input at its three innovation labs. Other proponents of design thinking include Citrix, Airbnb, BMW, DHL and Procter & Gamble.

    Another winning strategy is to empower users with self-service tools that add business agility. Examples include self-service analytics for rapid decision-making and process services that make it easy for users to modify workflows as business needs change.

    Take a More Strategic Role

    Now that every company is a software company, IT is increasingly strategic to the enterprise. Successful CIOs have seized this opportunity and are making the most of it.

    Forward-thinking IT leaders have recast IT in the role of business partner and change agent for digital transformation. They look for ways to drive growth, deepen customer engagement and shorten time to market. They help colleagues understand and realize the value of digital initiatives. They build bridges and buy-in by adopting a service mindset—what one CIO calls “ego-free IT.” The new measures of success aren’t IT-specific metrics; they’re meaningful business outcomes such as dollars saved, customers added and market share gained.

    Conclusion

    Every digital transformation is different. But the underlying challenge is the same. How can IT accelerate the pace of delivery and change simultaneously? By following the lead of digital trailblazers, any organization can gain the speed and agility needed to compete in a digital-first world—and win.

    About the Author / Chris Wiborg

    Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.

  • Barracuda Networks Enhances API to Advance DevSecOps

    Barracuda Networks Enhances API to Advance DevSecOps

    Recognizing that DevOps teams deploying applications in the cloud need a more sophisticated approach to security, Barracuda Networks at the Microsoft Inspire 2017 conference unveiled an enhanced REST API for its Web Application Firewall (WAF), in addition to providing integration with the IT automation framework developed by Puppet Labs.

    At the same time, Barracuda Networks revealed that it has integrated all of it firewall offerings with the Microsoft Operations Management Services running on the Microsoft Azure Cloud. Finally, Barracuda Networks announced it is now including a software-defined wide area network (SD-WAN) capability with the Barracuda NextGen Firewall platform.

    Tim Jefferson, vice president of cloud for Barracuda Networks, says the REST API the company is exposing in its WAF enables IT organizations to better manage security within the context of larger DevOps environment. As part of that effort, Jefferson says, Barracuda Networks also plans to integrate its WAF offering with other IT automation frameworks.

    Jefferson says many IT organizations are discovering that public clouds are more secure than on-premises environments because of the level of security and instrumentation that cloud service providers now routinely include. For example, cloud service providers make it easier to track unusual API calls that might indicate an IT security breach or even an attack in progress. Those capabilities, says Jefferson, make it easier for vendors such as Barracuda Networks to provide more visibility into what’s occurring in a public cloud than what’s generally feasible on-premises.

    However, each cloud service provider has its own unique network stack that requires security tools to be optimized for each platform, says Jefferson. Because of that issue, most IT organizations have not had the security wherewithal needed to rise beyond adopting more than one public cloud service in their production environments, he says.

    In general, Jefferson says, developers are not likely to consume security technologies on a public cloud that can’t be invoked via an API. Because of that issue, many IT organizations are discovering that the security platforms they have employed on-premises simply can’t be lifted into the cloud. That issue, he says, creates a level of friction inside the organization that inevitably hampers usage of cloud platforms more than any other challenge an IT organization faces. Cloud applications require a DevSecOps approach that developers will view as a natural extension of existing DevOps processes, says Jefferson.

    To achieve that goal, organizations need to make it easier for developers to secure their applications and invite IT security experts inside their organization to participate in, for example, scrum teams that collaboration build, deploy and manage applications. In fact, Jefferson notes most DevOps teams don’t even want to talk to a vendor’s sales representative; they prefer to be able to download code that they can test and deploy on their own before committing to buying a license.

    It’s still relatively early in terms of appreciating the impact DevSecOps will have on improving IT security. But one thing is clear: IT security vendors that don’t make it simple for developers to invoke the capabilities they provide soon will be left behind.

    — Mike Vizard

  • Microsoft Woos Development Partners

    Microsoft Woos Development Partners

    If Microsoft has its way, many more DevOps processes will revolve around the cadence at which the company upgrades its applications. At its Inspire 2017 conference, the tech behemoth announced an ISV Cloud Embed initiative designed to entice more developers to add value by extending application functionality it has already developed and deployed in the cloud.

    Rather than reinvent the same functionality over again, Microsoft will provide developers with access to its application at price points that are as much as 50 percent less than what an end user might pay, notes Alysa Taylor, general manager for Microsoft Business Applications and Industry. In addition, the company is promising to help software developer partners reach 100 million commercial active users of Office 365 and Dynamic 365 customers through the Microsoft AppSource online store.

    The specific software modules the company is providing developers access to under this program include:

    • Dynamics 365 Embedded: a suite of business applications the company is hoping third-party developers will customize and extend across a variety of vertical industries.
    • Microsoft Flow Embedded: Makes it possible to customize workflows to automate business processes within their application.
    • PowerApps Embedded: Provides access to extensions that make it easier to deliver an application via a browser or as a mobile application.
    • Power BI Embedded: Allows users to easily embed fully interactive reports and dashboards.

    This latest initiative is a logical extension of the work the company has been doing to entice developers to employ Microsoft Office as the front end for accessing a wide variety of back-end services.

    The challenge IT organizations that go down this path will face is aligning the pace of DevOps with the rate at which the company is updating its applications.

    Microsoft is not the only IT vendor that presents this DevOps challenge. The more a software developer invokes APIs, the more complicated managing the DevOps process can become. The whole concept of continuous integration/continuous deployment (CI/CD) can get sorely tested when control over when the back-end services being invoked via an API are updated.

    In effect, software developers are being asked to make a buy-versus-build decision. To entice developers to make a buy, the company not only provides a common API framework, but also developers will be able to take advantage of any investments it makes in artificial intelligence across the entire Microsoft application portfolio.

    Taylor says Microsoft is committed to working with partners to eliminate any competitive friction. The company is in the process of implementing a massive reorganization under which the company’s core technology groups are being aligned around four technology groups: Modern Workplace, Business Applications, Applications and Infrastructure, and Data and AI. The rest of the company is then being organized around a go-to-market strategy that is focused on education, financial services, government, healthcare, manufacturing and retail industry segments. Microsoft is looking for partners that can apply their own intellectual property to extend its core applications into each of those segments, says Taylor.

    It remains to be seen just how well partnering with Microsoft can work on a practical DevOps level. But the one thing that is clear is that there will be no shortage of software developers who are about to find out.

    — Mike Vizard