Hacksaw - The Blog

Legacy Software Architecture in Corporates

Yusuf Mayet -

In a previous post, I got started on Making Architecture Matter. Specifically in corporate enterprises, architecture is more about hand-wavy, fluffy things that has nothing to do with the real architecture. They care more about using more layers, which gives them more control, and no real thought is given to speed, HA, scaling, traceability, monitoring and analytics. More emphasis is put on having a smart looking "architecture" diagram with lots of boxes, and they favour a single style only, mostly synchronous API calls.

Chris Richardson argues that Let Architects architect:

An application has two categories of requirements. The first category includes the functional requirements, which define what the application must do. They’re usually in the form of use cases or user stories. Architecture has very little to do with the functional requirements. You can implement functional requirements with almost any architecture, even a big ball of mud.
Sadly, many organizations neglect architectural requirements unless they map directly to user visible features. For example, a typical product manager relentlessly focusses on features and schedule. As a result, they will often define performance and scalability requirements since those are visible to the customer. But development time qualities are often neglected.

The solution is for an organization to manage and prioritize architectural requirements, especially development-time qualities, in the same way as user visible features. This requires that Architects understand modern archiecturess, and different techniques, and know when to use each style, so that they dont only use one style.

Architecture Metrics

From DevOps for the Modern Enterprise, Winning Practices to Transform Legacy IT Organizations by Mirco Hering:

Traditional approaches accrued technical debt in the architecture, and changes became increasingly expensive. Hence, the performance of your architects should be evaluated on how flexible the architecture is becoming. For example, how do the architects make sure your architecture is future proof?

There are some aspects of architecture that you can measure, and I encourage you to find these measures so that you have something to help drive the right behavior: number of database access requests, data volume transferred over interfaces, stateless calls versus stateful calls , number of calls to external systems, response and CPU times.

Cloud

Cloud and cloud-native require new architectural styles. Migrating applications to cloud, even without significant changes (an approach known as lift and shift), provides organizations with the benefits of a secure and cost-efficient infrastructure. However, to make the most of the elasticity and agility that are possible with cloud computing, engineers have to evolve their architectures to take advantage of cloud capabilities. For new applications, cloud-specific IT architecture patterns can help drive efficiency and scalability. Whether you are rearchitecting the applications that currently run in your on-premises environment to run on cloud, or designing cloud-native applications, you must consider the differences between traditional environments and cloud computing environments. This includes architecture choices, scalability, resource types, automation, as well as flexible components, services, and databases

Learning new skills

I recently completed the AWS CSA exam, which covered the things that are important to an architecture of a system. I really enjoyed the emphasis on scalability, instrumentation, and HA. Corporates need make sure their staff do these courses, that will provide them with real world knowledge on how to build scalable architectures, rather that doing TOGAF and ITIL courses.

I have listed below some of the really good architecture material I have found valuable: