Using DevOps to Avoid Building Software Slums

The U.K. high-rise tower blocks built between 1950-1980 were heralded as architectural wonder. Large concrete towers accommodating the same numbers as the post war government-owned houses they replaced. Big rooms, excellent views and surrounding open spaces —low cost and futuristic.

Yeah, right.

But due to cost-cutting, substandard materials, demanding deadlines, and rushed construction practices, these modern-age housing miracles soon became slums de jour. And, by cookie-cutting across the country, town planners unwittingly replicated bad designs everywhere. The results: undesirable housing and elevated crime levels - urban decay. Even the surrounding open areas were neglected because no one had ownership over maintenance and supervision.

There many similarities between 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 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— a collaborative Dev and Ops love fest underpinned by agile and lean principles to ensure the rapid delivery of  high quality digital services. That sounds great on paper, 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 transitioning from set-in-stone architectural designs to a fluid mix of continuously evolving decisions. And, if EA can’t adapt, self-managing agile teams are increasingly empowered to make these calls.

But great developers aren’t necessarily brilliant architects; they’re not hard-wired that way. Without architectural guidelines and guide-rails, they could be charging down a development path and making quick-fire tactical decisions that compromise program-level objectives. For example, the performance requirements needed to support a business strategy of tripling the customer base while maintaining satisfaction scores could easily get lost in the rush to deliver 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 new-normal of a software-driven business will only further isolate the practice.

The Quest for Fluid Architecture

 The role of EA in an agile context is up for debate, but this shouldn’t hold us back. By using fluid guidelines 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 a debt resulting from bad architecture.

But even in minimal mode EA can still help developers during design phases; guiding developers on what architectural elements contribute to 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 today will probably comprise both commercial and open source software. All good, but beware of anything unsupported. Just as the cost of maintaining tower blocks reached unsustainable levels, so too, will the support burden on an organization if software isn’t commercially backed, especially in production. Also, work with development to understand where constraints lead to testing compromises—the “construction shortcuts” - 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 made things worse. Enterprise architects can make the same mistakes—for example, laying down crazy edicts that everything must be containerized, even some legacy apps. Sure, you've achieved runtime independence, but that only extends the life of problem applications and provides no incentive to drive improvements by clearing existing application slumware.
• 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 never forget that cloud doesn’t mean relinquishing ownership of application performance, security and the end user experience. To this end, architects must act as cloud-brokerage advisers—for example, working to ensure any cloud service provides open APIs so that security and monitoring can be seamlessly incorporated.

The DevOps inspired innovations of today will become legacies of the future. It’s essential, then, that architecture covers two essentials: working in minimal mode to ensure fast construction of quality services, and applying flexible standards and governance guidelines when systems change.

No matter how good your app designs look on paper, failing to incorporate modern architectural practices means just building and maintaining more problematic systems. Fuse EA into DevOps and build systems we can be proud of and your customers love. Fail, and we can add 'application slum landlord' to our job titles.