The Case for Software Architecture Makeover

A few years ago, a friend of mine shared with me a white paper that he thought would interest me. This paper described the concept of distributed application architecture through small self-contained application components deployed across a larger corporate network. Eager to impress my friend, I put down the article and exclaimed: “I know where this is going, microservices.” He smiled and replied, “Look at the published date.” To my astonishment, the white paper was published in the late ’90s on the subject of the then relatively new technology called Enterprise Java Beans (EJB).

Sometime later, I hosted a technology leadership forum at a major insurance company in New York. One of the key discussion points included emerging technologies, and of course, microservices. I used the “EJB” anecdote with a profound (sarcastic) conclusion that software architecture styles and patterns do not drastically change, but rather evolve, while software reference application architecture based on a particular technology stack has a lifecycle of emerging, mainstream, and legacy.

In this article, I would like to demonstrate a few software architecture concepts in order to build a case for software architecture makeover.

I will start by presenting an example of how architecture styles might have been perceived and applied differently a decade ago vs. now, largely influenced by the technology reference architecture of its day. I will use a process engineering use case for the insurance sales value stream for a fictional insurance company (Figure 1).

Figure 1. Insurance Sales Value Stream.

Let’s take one of such architecture styles called Layered Architecture. Layered architecture style suggests the separation of application components into logical application layers deployed on dedicated infrastructure known as tiers, hence the name n-tier architecture. Layered architecture has the benefits of making application components more manageable and reusable while making a business application easier to maintain and extend, hence increasing software lifecycle, ROI and reducing maintenance costs.

Layered Architecture Then

The typical layers in an n-tier web application are presentation, business services, data, and integration (see Figure 2). The drawback of “application layered architecture”, or what I like to call “micro layered architecture”, is that the benefits of this design are bounded vertically by the application context. This design may improve the software quality of that application, but not much beyond it. Even if this architecture style, along with the DRY (Don’t Repeat Yourself) design principle is uniformly applied across the application landscape, there will still be plenty of redundant code and tech debt replicated within the company’s business applications. This would be due to common and overlapping data elements and business logic, as demonstrated below in Figure 2. The diagram below deserves a closer look. Although the business applications depicted in the diagram may support various business functions performed by various users, some data entities such as policy, products, and benefits are common across most insurance applications. This is likely to result in redundant data CRUD and business rule code replicated across the application. The most immediate consequence of such redundancy is a higher operational cost for data management and application development.

Figure 2. Micro Layered Architecture.

Layered Architecture Now

Now, I’d like to demonstrate the concept of macro layered architecture where the entire enterprise application landscape is partitioned into the following layers: channel, process management, API & data (Figure 3) as a whole, rather than each application individually. In this design, each application layer is managed independently and will only have a loose dependency on the layer(s) below.

Figure 3. Macro Layered Architecture.

For example, the channel layer for the insurance sales value stream may include custom-built web and mobile apps used by brokers or a third-party SaaS application used by the sales ops. All of these channels will rely on the common security and integration infrastructure and protocols such as OAuth & REST to integrate with the process management services. The process management services may be managed by a BPM platform that further promotes the reuse of workflow, business rules & integration components. This architecture significantly increases consumption and reuse of functional and data APIs by various channels, process management services, and other APIs, considerably reducing insurance company’s application, data, and infrastructure footprint, technical debt, and therefore cost of ownership.

Conclusion

Now, what is the case for software architecture makeovers?

Software architecture is a fascinating, mature discipline that has been around for many years. Unfortunately, there is a common perception that software architecture similar to traditional project management is a “legacy” discipline. The discipline promotes outdated software design styles and excessive content, which may impede fast-to-market, POC-centric Agile software delivery.

To some extent, this perception may be valid. I believe that software architecture needs a major makeover in order to make itself more relevant and “value add” in today’s world of continuously emerging application and technology stacks and SCRUM teams that have a short attention span. If software architecture is to survive as a discipline rather than being rolled up in solution architecture, I believe that it must shift its focus to enabling Agile application development and DevOps. One way to do that is to add Agile and DevOps enablement to the list of required software quality attributes.

When done right, at the right time, with the right content, using the right technology stack, software architecture can be a great empowering tool for software developers to produce better software and minimize delivery risks.  

I welcome your comments and feedback. If you like this article, please share it to spread the word.

References:

ACORD Reference Architecture

Microsoft Developer Network - Software Architecture and Design

Software Architecture Wikipedia