Someone needs to build them, improve them, live with them. Observable systems are crucial for a healthy business and platform so they need to be considered from the beginning and, as much as possible, treat observability as non negotiable.Īrchitectures hardly appear spontaneously. Observability is a CFR that is important enough to consider it as a different question. Usually you will answer yes if your business doesn't need to understand how the system is behaving to fulfill business requirements. It's a set of systems, and defining how these systems behave is important for the delivery of new functionality. Your architecture is a technical outcome. For the sake of simplicity, I'll keep the details out of this post. That's why practices like Domain Driven Design focus on mimicking the business boundaries and language for writing software. It has been proven that the divergence between the language we use for business and the language we use to solve the business problem affects negatively the development process. If your architecture does not actually fulfill any business case, it's just a fancy image.ĭoes my architecture resembles my current business? Your organisation fits a purpose, this area states that your architecture needs to be useful to whoever delivers valueĭoes my architecture resolves the business functionality? There are three main areas to consider when you decide to design an architecture: What is a competitive advantage, and we will see why, is optimising the process of understanding, defining, building and improving your architecture.īut first we need to talk about requirements.Īs stated before, usually when we design architectures we just consider CFRs (performance, scalability, budget, security.), which are really important, but not everything. On distributed organisations, a single point of decision is a single point of failure, and throttles the whole organisation.Your elite team is not going to follow up on all the requirements, as they depend on feedback from delivery teams, and on any communication, part of the information is lost.If you let just an elite to define the architecture, you are just building not motivated teams with lack of autonomy.If you define an architecture alone, or in a group, you become a silo of knowledge, with huge and dangerous consequences.This is most of the times short sighted and troublesome in the medium term, for four main reasons: Architectures degrade a lot, and even more on big organisations, so just buying the architecture is a patch (and technical debt). Having an architecture that you can showoff on twitter or your teammates is not a competitive advantage. It's important to note that architectures are not important. Usually, what happens in most companies during their transformation to a more modern architectures and processes, is that they build, or hire, a group of experts that will lead initiatives to build the new architecture or design new processes. Or defining it in another way: how is the architecture going to work and how much money I'm going to spend on running it. The most prominent requirements when talking about software architecture are cross functional requirements and budget.

If you design a software that needs to be really fast, hardly you are going to take into consideration scalability, consistency of data, or even security. Hardly we are going to find a design that works like a charm for more than one type of requirement as the combinations are mostly infinite. This happens because requirements are always changing, so no design is perfect. Eventually, software will become a problem to the company if it's technical debt is not managed as a first-class citizen on the design, delivery and business process. We can make efforts to delay the inevitable, but software is full of technical debt, even on it's sources, and team need to keep an eye on it so it can be improved and fixed. The reason behind iterating your software architecture This is a summarised subset of what I call Organic Software Architecture, that I think can be useful as a checklist and as a set of patterns to apply for building architectures. Which made me decide on spending some time on writing how iterative software architecture works for me. I think the responses were quite interesting (it will take a few minutes to have a look at them, totally recommended!) and I really enjoyed the discussion in this thread. However, within the lack of time that I have due to spending a lot of my efforts on two very important projects and my family, I found this tweet: I wanted to write about this topic for a long time, but honestly, structuring how I've been working for the last few years is sometimes complicated.

Software design architect