Is your software Architecture Modern?

?If your software is meeting all the business needs and works flawless on technical parameters, shouldn’t you question the need for “modernity”? ?Or not yet?

In all facets of life, humans replace working items. The need of new things (a car or a phone for example) is not often the weakness of the very equipment or an idea but more towards the human willingness to experience contemporary aspects. Users simply get used to the new way of living. They seek change. Software demands, is not going to be different there.

I try to answer two fundamental questions –

1.?????? How to determine if software architecture is still relevant and has some more “life” span?

2.?????? How to change “architecture”? Isn’t that static as in backbone?

For a purist, software architecture is not a physical entity but an abstract arrangement of software components. ?Architecture affects outcomes of the software in functional and non-functional requirements. Architects worry about how components are layered, coupled, exchange information, how can they be independent, replicated, administered – to name some of the prominent concerns. These principles do not change, but the very software components that realize the goals of architecture will. ?Sometimes in number, sometimes in style or in functional capability.

Over the years, the most prominent “change” according to me, is in the increase of software usage and dependency on software to lead life. A few decades ago, usage of software was limited to a certain set of people on a select devices on few projects. Now, software is omni present and is inevitable to human and devices. Nowadays, the level of software functionality in “abstract” does not know the target devices, does not assume the application use cases, assumes a large user base and assumes a whole lot of citizen cases. Put simply, change in life styles beg for modernity of software too.

That is why “cloud” computing, ready integrations, scalability have taken front seat in the modern regime. ?They are already there to be used, relatively cheap and most important- they work for many consistent and in expected response times! ?So what makes a modern architecture cater?? I did spent some time in noting the modern cloud software. I could list five characteristics of modern architecture. ( By the way, GCP, AWS, Azure, oracle, apple – ?the general practices and software components at disposal made my references to assess a modern software)

1.?????? Separation of concerns is distinctly visible. (set of loosely coupled “fully functional atomic” units make multiple lanes of delivery)

Taking a random example of an architecture diagram, I wish to highlight this point. This one is from Microsoft Azure site : https://learn.microsoft.com/en-us/azure/architecture/example-scenario/data/real-time-lakehouse-data-processing taken on 11th June 2024

Please note the right-hand side “line of business outcomes”. They cater to distinct use cases of different genre. At the same time, even though functional components are reused liberally, they do not intermix the resources to cater to each of them. You could more lines at will and all new developments shall come as “incremental” without disturbing the existing ones.

?

2.?????? Configuration and storage are distributed.

Again, picking up a random architecture diagram for a specific solution (this time from AWS site : ?https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/?did=sl_card&trk=sl_card ?taken on 11th June 2024 )

Modern architecture moves configs and storages to the component layer and typically not at the solution level. At times, we may see a “zookeeper” like config repository applicable at solution level, but even then, individual configurations of components are storage are not uncommon for selective scalability and functional isolation. ?The distribution of storage generally bakes in a data model problem – what about data integrity in redundant copies data in flow? I think that is the price to pay, there seems to be no better answer than distributed tests to make sure of Data validity and integrity at each layer. The distributed nature also bakes in another problem – Every component needs to independently make sure of guarantee of process continuation, independent auditing and book keeping of operations. (Even in Micro services architecture, both flavors – orchestration and choreography alike, ?status and book keeping of ops are distributed)

?

3.?????? Data is assumed to be a torrent. And quite transient.

Modern architecture by default does not depend on characteristics of data. Character set immunity is generally achieved by Json/Yaml in data and config exchange. The data model treats data as pebbles, no software behavior is dependent on structure or content of data by and large.? The flow is assumed large, designed for large volume of transactions. Usually, shards of data are kept for better management and maintenance.

I have observed three patterns:

a.?????? There is always a “unit” or a “quantum” of data in transaction. The volume is either managed by multiple agents and replicated services in parallel, completed by load balancing and streaming invariably.

b.?????? Queues and pools are liberally used to balance out the speed of operations (aimed at real time use cases if needed) and to assist asynchronous operations. Also, ephermal.

c.?????? Service scheduling and playback(resume-from-interruption) is always at play.

???

4.?????? Deployment is automatic and monitoring is pre-provisioned. An ability to take one single line of service offline or online is important.

?

5.?????? Data security and access controls and privileges are strict and are uncompromised at each component. The governance of security is done by a uniform policy assisted by a dedicated module.

?

Invariably, modern software tends to be multi-tenant.? However, I have not counted this factor as a major characteristic of a modern architecture for a few reasons: Multi-tenancy is an aspect of a software application and not software itself. Secondly, ?all five characters above are equally valid for single or multi-tenancy. But on strict argument of an ability to serve multiple users of multiple groups (equivalent of multi-tenant system), it is fair, I may correct myself.

?

HOW TO DETECT THESE FIVE TRAITS?

A lot of theory is on using a “fitting” function to architecture and constantly validating the architecture. I would like to dilute this statement a bit and claim – true detection of five traits is in the way we test our software regularly and on each release. Architecture is not going to be obvious. If a test suite has classified tests and classified automated tests for each lane of service and can be tested in isolation to each other, I would think you have one strong criterion to claim #1 above. The second part is also equally important- presence of strong unit tests to prove the automaticity of functionality of each component (even if re used) would complete the detection of #1.

The distributed storage and configuration are easy to audit. ?Functionally mutual exclusive configurations in component level configs and application(solution) level config is desired and proves a point of atomicity of components.

Three things are needed to prove the software is large data ready:

a.?????? Presence of data policy that describes the transaction controls, data retention and eviction.

b.?????? Multi language test suite

c.?????? SLA and playbook of SLA adherence for various volumes of data classified as regular, stress and catastrophic are needed.

Dev Ops tool and documentation on how to isolate, upgrade or patching a single line of service as a whole and ability to resurrect, replicate or upgrade a single component in offline mode are the testimony for #4.

?#5 is distributed in unit tests and application penetration and wholistic security checks. A soft switch to turn off or turn on a feature is desired and is a good dip-stick test.

?

HOW TO “CORRECT” THE ARCHITECTURE?

This is hard and tricky. Often, the enterprise architecture is likely to advice no-radical change in software. Adopting modern architecture is simply not called for if there is no need of doing business differently or the business functionalities are stressed to a point of no return. Unless the ground rules of doing business or style of doing business change, I would recommend to chose “optimization” in existing architecture.

?

?But overall, at a high level there are two approaches to change architectures:

1.?????? Break down software components into functionally distinct units in the current fabric of architecture. This means, the storage and config will not change drastically, data security and privilege-based operation will need a facelift, data model will need to remain the same at large but with physical data model corrected liberally and may go polyglot. Inculcate the culture of functional units baking in test suites in the fabric and deployment architecture need to reflect. Freeze the mess into a bucket and introduce any new line of service as a fresh and integrated in isolation.

2.?????? Leave the existing system as is and rewrite all shiny new piece. All new development must piggy back on migrating the existing users seamless and religiously. Without the second strategy do not even attempt rewrite a single line of code. But in case of a rewrite, an intellectual and financial sponsorship is a must.

?

Practically, these are important:

a.?????? Get your functional and NFR test suites ready and spruced up. They are the life savers for a change in journey. Cannot stress more.

b.?????? There is nothing called “infinity” capacity planning of components or hardware. It is safe to design for 10X the volume of what you would reach organically in 3 years.

c.?????? Automate, code generate and repeat. Do not engage into any manual effort that begs budgeting more than 2 months.

d.?????? No “Big Bang” releases. Adopt to declare the arrival of a new/resurrected component once it successfully works for a month.

e.?????? Generally, take the approach of many commodity machines instead of BigIron servers. Use horizontal scalable principles.

f.??????? Keep the overall scheme of things drawn at high levels, all the time.

?

One last word on “fitting” functions. Generalizing the functions to test architecture is very hard and illusive. Please develop your own fitting functions as needed, else functional and NFR test suites are your best bet to make sure the goals of your architecture are not diluted or changed over the period of time.

?

?

?

?