The U.K. high-rise tower blocks and built circa 1950-1980 were heralded as architectural wonders—large concrete towers easily housing the same population as the smaller houses they replaced. With large rooms, excellent views and surrounding open spaces, they initially were popular residences—low cost and futuristic.

But looking futuristically sometimes has a habit of coming back to haunt you.

Due cost-cutting, substandard materials, demanding deadlines and rushed construction practices, these modern-age housing miracles became the new slums of the day. By replicating tower-blocks across the country, town planners unwittingly replicated bad designs everywhere. The results: undesirable housing and elevated crime levels, leading to slums and urban decay. Even the surrounding open areas were neglected because no one had ownership over maintenance and supervision.

In IT, we have our own design and architectural calamities.

There are many similarities between existing IT apps and decrepit old tower blocks. IT monoliths can be hard to scale, requiring costly maintenance to avoid disrepair. They’re also tough to police, with vandalism and theft being a constant problem. Add to this integration issues (IT’s version of unsupervised open spaces and pathways), and we’re left with systems inadequate to meet the needs of modern digital business.

Enterprise architecture must change with the times

DevOps, with its focus on operations and development collaboration across the entire service life cycle, is now seen as the answer to some of these problems—an approach underpinned by agile and lean principles for rapidly delivering high quality digital services. That sounds great, but let’s not forget enterprise architecture (EA), because without it we could still be building IT slums—only more of them and much, much faster.

Of course, many DevOps stalwarts may argue (with some justification) that heavy EA practices and frameworks haven’t evolved to match the pace of agile. Iterative-style development means where you start isn’t necessarily where you finish, necessitating a transition from set-in-stone architectural designs to a fluid mix on continuously evolving decisions. And, if EA can’t adapt, autonomous and self-managed agile teams increasingly are empowered to make architectural calls.

But great developers aren’t necessarily brilliant architects; they’re not hard-wired that way. It means they could be charging down a development path without architectural guiderails, or tactically making team-based decisions that compromise program-level objectives. For example, the scalability and performance needed to support a business strategy of tripling the customer base and increasing satisfaction scores could get lost because development focuses myopically on delivering more functionality.

However, we can’t just lay the blame on developers. Enterprise architects must recognize that any misalignment between their processes (especially the rigid and static ones) and the vision of an increasingly software-driven business will only further isolate the practice.

Architecting new fluid guidelines and principles

The role of EA in an agile context is still up for debate, but this shouldn’t hold us back. By using architects and fluid guidelines means we can maintain the pace of delivery while preventing chaos. The trick of course is to limit architectural over-engineering while providing developers with a minimum set of EA to avoid technical and architectural debt.

Even in minimal mode EA can still help developers identify quickly what should be considered during design. The aim is to guide developers into understanding what architectural facets make up a successful application, and more importantly, how new ways of thinking can support longer and more sustainable software innovation.

Interestingly, these practices can be presented in a “slum avoidance” context:

• Avoid substandard or unsupported materials – The tool chains being used will probably comprise both commercial and open source software, but beware of anything unsupported. Just as the cost of maintaining tower blocks reached unsustainable levels, so too, will support burden on an organization if software isn’t commercially backed, especially in IT operations. Also, work with development to understand where constraints lead to testing compromises—the “construction shortcuts” syndrome, resulting in more defects and technical debt.

• Never use new technologies to rehouse old problems – As tower blocks degraded and vandalism increased, many local authorities tried to contain the situation by housing “problem groups” in the same block. But that just increased problems. Enterprise architects can make the same mistakes—for example, laying down crazy edicts that everything must be containerized, even some legacy apps; not understanding that runtime independence only extends the life of problem applications;  or providing no incentive to drive improvements and clear existing legacy IT slums.

• Monitor and manage your sub-contractors – Whatever cloud model you adopt, abstracting away the infrastructure or application stack frees development to focus on coding. That’s great, but don’t forget “PaaS-ing” apps to the cloud doesn’t mean relinquishing ownership of application performance and the end user experience. To this end, architects must act as cloud-brokerage advisors—for example, working to ensure any cloud service provides open APIs, so that monitoring can be seamlessly incorporated into a unified solution.

Of course, architecting great new digital services with DevOps is only part of the answer. The innovations of today may become legacies of the future and many new apps must also integrate with existing systems. It’s essential, therefore, that architecture covers both bases: working in minimal mode to ensure fast construction of quality services, but also applying standards and governance when needs dictate and systems change.

No matter how good your app designs look on paper, bad architecture just means building more problematic systems and never clearing the existing slums.