3 outdated architecture practices that may be holding you back

Enterprise architects are facing a rapid rate of change in business and technology. This new normal requires moving beyond classic patterns and practices and embracing architecture principles better aligned with today's mandate for agility, reliability, security, and experience-driven systems.

With these fundamental principles in mind, here are three outdated ideas about designing architecture that may be holding you back.

Inside-out design

In the early days of my career, designing a new application often started with creating an entity relationship diagram (ERD). The database was essentially the centerpiece of the application, with business logic and the user interface assembled around it. This is a classic example of inside-out design.

Meeting the demands of today's experience-driven customers means starting with the endpoints interacting with our systems. This "endpoint" is often a human user, although it's important to consider cases where the primary consumer of your software is other software. In either case, it makes little sense to begin the design process with a static representation of data at rest. By doing so, you are immediately forcing your experience to adapt to this internal requirement instead of starting with the desired external experience and designing inward.

Businesses and users operate in real time and are in a constant state of change. We must design technology systems accordingly. This means focusing design efforts on the fluidity of the data involved in a business function. Designs must enable a seamless flow of data within and between functional components. Achieving this in a sustainable and scalable fashion means having fewer point-to-point integrations and more event-driven data streams. This type of data-in-motion architecture places less emphasis on creating the perfect data-at-rest schema. Instead, it facilitates real-time processing capabilities that can easily transform entities into various data-at-rest formats as needed.

Rigid architecture frameworks

As the rate of change increases in business and technology, architecture frameworks must also evolve. Classic architecture frameworks such as The Open Group Architecture Framework (TOGAF) and Zachman can be useful for modeling the complexity of businesses, but many of today's architects are finding they are either too complex or too abstract to drive rapid transformation.

[ Download the eBook: Modernize your IT with managed cloud services. ]

The Open Group has attempted to address demands for more overtly agile architecture guidance by introducing the Open Agile Architecture (O-AA) standard in September 2020. O-AA is positioned as complementary to TOGAF but more focused on helping organizations architect in an agile environment.

Regardless of the specific framework, the ultimate goal of designing architecture is to communicate effectively. This means capturing both the process by which you arrive at a design and the design itself. The process is critical because it communicates the key considerations that went into the design, including context, business requirements, and (most importantly) the trade-offs that you evaluated. These considerations are critically important to communicate in a design that will continue to evolve.

I recommend sharing the most critical architecture decisions with some form of architecture decision record (ADR). This is typically a document that captures when an important architecture decision has been made, along with its context and ramifications.

Developers code, operators run

My last outdated idea involves a key saboteur of reliable, secure, and agile systems. It is rooted in the classic bifurcation of duties in software engineering, where developers build applications and operators run them in production. In this model, developers focus on innovation and removing barriers to productivity (velocity), while operators focus on reliability and process (SLAs).

DevOps has been instrumental in bridging these two ends of the product engineering spectrum. That said, IT leaders still tend to focus more on the build side and less on the run side when touting the benefits of DevOps. This is driving an increased need to adopt site reliability engineering (SRE) principles across the full engineering lifecycle.

SRE is a discipline founded at Google in 2003 that focuses on building reliable systems. In the SRE model, creating reliable applications is a true engineering discipline, which means it must be integrated into the earliest aspects of product development.

SREs with software development skills are needed across the entire life cycle—from architecture to development and through operations. In essence, this extends operator concerns further left in the engineering life cycle and broadens developer responsibilities further to the right. This makes even more sense when considering that today's systems are increasingly designed with software-defined everything.

Wrap up

As John F. Kennedy famously said, "change is the law of life." Architects must continue to evolve to meet business and technology demands. This means letting go of outdated practices, injecting new innovation into existing sound practices, and committing to continuous improvement in architecture design.