Let’s Finally Put the Build Versus Buy Question to Bed

With another ONUG Fall in the rearview, it’s a worthwhile exercise to look back at the topics and innovations discussed and consider what they mean for the biggest questions IT leaders face.

This year, network complexity continued accelerating, with multi-domain, multi-vendor, and multi-cloud management taking up a growing slice of mindshare for enterprises large and small. We learned that security challenges won’t take a back seat while we pursue digital transformation goals. We also saw that M&A activity, which is likely to accelerate throughout the ongoing economic turbulence, presents a huge hurdle in terms of combining and standardizing operations. The list goes on, but the point is clear – these are big challenges that require intelligent, agile solutions.

But what do these conversations mean for IT leaders planning budgets and initiatives for 2023? Ultimately, it means that these challenges are too large to be addressed manually. Automation is the only way IT teams can keep the lights on, networks secure, and operations compliant. However, we also have to consider the growing gap between what network engineers can do and what is being asked of them. Enterprises have the option of devoting resources, engineers, and time to building this automation in-house or bringing in outside help to accelerate the process. I contend that this is no longer a realistic question – unless your core business is network automation software development, it is impossible to beat the flexibility, time-to-value, and cost savings that commercial tools are now capable of providing.

Setting Realistic Expectations

Recent research from EMA found that more than 63% of IT leaders surveyed are developing some data center network automation software internally, and another 24% said this is their primary means of automation. However, the same research found that only 51% expect to earn an ROI within two years. The key word there is expected. Having been on the front lines of many automation initiatives for multi-national organizations, I can say that expectation is not reality. Reality is employee attrition and the associated institutional knowledge that can disappear overnight, setting projects back months. Reality is the technical debt that compounds with each change in direction due to new leadership, evolving company priorities, or outside acquisitions. Reality is developing some automated processes but relying on manual data collection to feed that automation. In the end, it’s unsurprising that 35% of companies say that the implementation of data center network automation is taking too long.

Perhaps the biggest challenge facing in-house development is acquiring the right talent. Networking experts know the network, but they typically aren’t programmers. Programmers can code, but they struggle to grasp the complexities of today’s networks. With job vacancies for both job roles at high levels already, finding engineers that fit this niche is especially difficult, and keeping them around at reasonable salaries is a whole challenge unto itself.

Meeting the Challenge

The decision to go with a commercial solution over in-house development has not always been as clear-cut as it is today. Networks are inherently complex, and their lack of standardization, tendencies for rapid evolution, and shouldering of mission-critical operations created a particularly high barrier to entry for commercial service providers. However, I joined Gluware after years of developing in-house solutions at Fortune 500 companies precisely because I saw that the tide had turned – customizable, pre-built solutions are the future.

Gluware has demonstrated it can support and accelerate the key elements of any network automation program, including full observability, configuration management and validation, intent-based networking, and declarative provisioning. These foundational capabilities alone save network engineers countless hours that would otherwise be spent identifying and resolving basic network issues.

Gluware 5, which was announced at this year’s ONUG, takes these capabilities to the next level. Gluware Topology enables teams to visualize enterprise networks from a global perspective down to specific device connections to unlock new levels of detail, accelerate troubleshooting, and facilitate compliance document exporting. Its API Modeling capabilities enable intelligent southbound communication between the Gluware Intent-Based Networking Application Suite and API endpoints, extending the same guided experience available for CLI modeling and removing the need to manually program device discovery, audits, configuration changes, and automation across API-based controllers, including Cisco Meraki. Gluware Service Connectors then facilitate northbound communication between the Gluware Intelligent Orchestration and Automation Engine and API integrations on the management plane through pre-built API integration packages such as ServiceNow. On top of all of this, users can leverage Gluware Network RPA for no-code, drag-and-drop process automation of tasks across APIs to eliminate the need for hundreds of manual API calls across the network.

The Bell Tolls for Build Versus Buy

What was once a worthwhile discussion is now an easy decision. The shortcomings of in-house development of automation solutions, including higher costs, longer ROI horizons and lack of tailored talent, can all be overcome through commercial solutions. Platforms like Gluware can solve network challenges in weeks as opposed to years. These capabilities radically increase the speed and agility of network management efforts and free engineers to focus their efforts on advancing operational efficiencies, business services, and customer satisfaction.

By putting this issue to rest, we are taking a step as an industry to unlock networks as the platform for digital transformation. These capabilities will only continue to improve, and the cost savings, flexibility, and power of this automation will be a growing competitive advantage for those that implement it into their operations sooner than later.

Author's Bio

Ernest Lefner

Gluware

Gluware