advantages, they also present challenges. Managing them at scale is particularly complex because it requires translating an organization’s structures and rules into security rules in the cloud. This comes even before optimizing the platform from a financial perspective, which has become a discipline in its own right (FinOps). Skills in the cloud space also tend to be cloud-siloed, which means advice and architecture are not necessarily neutral but heavily influenced by the cloud provider.

Another challenge is regulation. OSS & Network platform owners have obligations and requirements that they cannot easily outsource to a public cloud. In these environments, moving to the public cloud is a complex endeavor. BSS systems owners also have their own regulatory and legal obligations that can add complexities, though they are usually less related to the properties of the cloud itself.

Standards won’t save you. Telcos are used to well-defined standard architecture frameworks. These work well as process/functional placement models, but managing cloud-native software (in a private cloud in many cases) creates a lot of additional complexity. When architecture is dynamic, the challenge is managing automation and deploying the infrastructure and applications, which is not defined in the standards.

Scale and & Skill Sets

Iterative approaches to project and program management have become commonplace in most industries. Although there are many variations, these methods view production as a decentralized but industrial process.

In the modern landscape, favored skill sets include DevOps cloud-native practices and agile methodologies. These approaches typically emphasize smaller, tactical teams engaged in custom development and code packaging.

In many projects, however, the definition of “done” becomes elusive, as solutions and functionality may lack clear definition initially. In technical, infrastructure-centric environments like networking, there is significant risk due to minimal input into requirements, often with few or no direct users. These large, capital-intensive projects result in extended timelines and feedback loops. Additionally, solutions such as those for network switching tend to be complex and abstract.

Having enough constraints on teams to ensure standard approaches and consistency is better than allowing total freedom. Platform engineering has evolved as an approach to putting guardrails on DevOps to do this.

Architecture and Scale

Architecture should be a key concern in large projects as without a solid approach to architecture, the definition of "done" needed for program management does not exist and is not verified and re-verified.

Moreover, the massive emphasis on application architecture can lead to the neglect of higher-level architecture because it's not mapped to features for individual products in the program. The dangers of this might not be immediately apparent. While using program-level architectural principles and approaches can help, there still needs to be a strong architecture team.

Highly structured environments like telco networks did not tend to have much need for Enterprise Architecture (EA), because transformation programs are moving to environments where standards do not address many aspects of EA.

In the case of agile projects, project management rather than architects usually ensures the execution of the delivery process. This can lead to little time for architectural work. Also, the roles of lead engineer and architect can become confused. On a small scale, engineering skills are more important. However, in a large project, this can become a huge issue.

In modern projects, architecture is not static; it needs to be regularly revisited and revised. Paradoxically, this can get neglected, especially at a program level in these kinds of projects.

Pitfalls and Program Management

Domains in telco and other industries have become very similar, and there is a much more significant technology overlap than existed previously. New technologies require new approaches to managing them. But while adopting new methods, architecture management at a program level still needs to be maintained and aligned with program management.

New environments and methods can be complex to manage, and it can take time to understand how a project is doing. Some things to watch out for are: 1) Technical discussions dominating program-level discussions signify that large-scale architecture and operations management still need to be fully considered. 2) Activity and progress towards completion do not sync. Progress and targets appear just within sight but are never quite achieved. Again, this can be a symptom of a disconnect between architecture and program management.