There are a lot of issues that network-management people worry about. We all have heard about faults, failures, breaches. But want to know what long-term problem is keeping the smart members of the network leadership of enterprises up at night? It\u2019s an empty chair. Their chair, at the table that makes the plans that set network requirements and directions today and for years to come. These leaders used to sit in that chair, but now they say there\u2019s no place for them.\nApplication designs determine network requirements\nWe used to build networks from primitive pieces, like digital trunks and routers. Then we built them from services, like IP VPNs. That transformation was jarring to many who\u2019d cut their teeth on real private-network technology, but they were still a big part of the game. Today, we\u2019re still building networks from services, but the services of today are application services that include implicit network features. The really new network is built from connectivity services that are included in cloud and even data-center hosting packages. Application planners design these services, and the decisions they make frame the building-blocks of the network. One chief network officer said he\u2019d gone from building technology to stocking shelves.\nIn some ways, more application centricity could be a good thing. Twenty years ago, companies\u2019 network budgets were roughly half dedicated to sustaining current infrastructure and half to support new business projects that brought their own benefits. Today, few companies get even a fifth of their budgets from new projects. Our chief network officer isn\u2019t just stocking shelves, he\u2019s restocking them. New applications could open new business cases, drive new budgets and new network plans.\nThey are doing that, particularly in cloud computing, but the networking piece of the new application paradigms is part of the cloud, and application design decisions are setting network requirements. Often they set requirements that can\u2019t be met. Several network leaders I chatted with in December told me about projects that built cloud software in a way that could not possibly have met either the cost projections or the quality of experience mandated by the projects\u2019 business case. They also said they would have recognized the problems immediately had they been in on the decisions from the first. \u201cA bunch of programmers put this together with state-of-the-art software techniques,\u201d one said. \u201cWe needed state-of-reality techniques.\u201d\nApplication planning needs input from network pros\nAnd here\u2019s the reality.\u00a0 Network professionals need to be involved, heavily involved, in the application planning decisions that are really driving network evolution for enterprises. They have a lot to contribute in the critical area of application architecture, the set of decisions that determine what an application does, how it\u2019s connected, and what it costs.\nThe reason for project failures that those network leaders told me about was simple: over-componentization.\u00a0 Cloud-development treatises emphasize microservices, meaning tiny, scalable, distributed, components. You can build applications that way and enhance how the cloud can make them available and scalable, but every such component you add also adds a pair of network connections.\u00a0 Latency goes up accordingly, and one enterprise found their cloud implementation delivered three-second latency when their old data center front-end introduced a third of a second or less.\nCosts also explode.\u00a0 It doesn\u2019t do any good to componentize the applications and then bunch them into a monolith when you host them, so each microservice component is independently hosted. That\u2019s not a path to economical operation, so it\u2019s no surprise that most enterprises say that their cloud costs have overrun, and often badly overrun, estimates.\nProblems with having application architectures dictate network decisions by default don\u2019t end with the cloud, either. More and more enterprises use containers and the popular Kubernetes orchestrator tool to deploy data-center components of their applications, including database access. Kubernetes uses virtual network technology and supports virtual-network plugins. So do the public-cloud providers, so the cloud piece of applications is based on virtual networks. If you have multiple clouds (multi-cloud) and also cloud-to-data-center (hybrid cloud) applications like almost all enterprises do, then you could have three different virtual-network models within your application platform, and probably a corporate VPN besides. It\u2019s not just ships passing in the night, it\u2019s whole fleets.\nFocus on information flows\nFor operations reasons alone, the multiplicity of network services that make up networks of the future would be a challenge, and network professionals are already meeting it. Network operations isn\u2019t the real problem, though. Even simple questions of how the elements involved in each information flow can address each other demands some understanding of both the rules of element connection and the way all these virtual service networks can be interconnected. Without some influence on how those network services and the application platforms that use them are combined and used, things can arise that can\u2019t be fixed. They have to be prevented.\nIn the world of the future, and even much of the world of today, applications and users float around in a sea of interconnected hosting facilities. We have the Internet, where most of a company\u2019s customer-facing activity starts, and that plays a growing role in employee access to information. We have the cloud, which is the front-end of applications pushed out of the data center and into a distributed, elastic, pool. We have the data-center network, used by data-center virtualization technologies to connect application pieces, and we have the corporate VPN, which is sometimes MPLS, sometimes SD-WAN, and sometimes both.\u00a0 We\u2019re not networking sites any longer, we\u2019re networking information flows. Application developers assume those flows exist, but network professionals have to assure them, and make them \u201cassurable\u201d.\nWe can\u2019t build applications without considering those information flows, without perhaps even being dominated in our thinking by those flows. We can\u2019t build networks without interconnecting services that are really designed to host application pieces. We\u2019ve separated things that, at some level at least, can\u2019t be separated. We need to get back the network professionals\u2019 seat at the decision-making table, but it\u2019s not just a matter of claiming a place, they have to claim a role. That means that there has to be a real exchange of views during application design, which in turn means that there has to be a basis for the exchange. Network people can\u2019t speak network to programmers, and the other way around won\u2019t work either. They have to find a common ground.\nWorkers aren\u2019t in fixed locations today, not after COVID and work-from-home, and network professionals have dealt with that. Information flows now accommodate worker mobility, and they can accommodate application-component mobility, too.\u00a0 If network professionals can claim the role of the information-flow architect, and learn the way application design impacts those flows, they won\u2019t have to slip into that seat at the planning table, and maybe participate in collective seat-polishing. They can play an essential role.