Design should be a developer’s bread and butter. Changing how we talk about software under development is the start of building better software systems. We must stop calling everything architecture, make design more accessible, and resist the urge of focusing on technology.
Design is how, who and when…
Design is how we use the system. This can be users or even systems via APIs. We can call this who. Think of this as the behaviour of the system. It can also be when - in terms of order of a process, or schedules.
Typically, though when is part of a design, it can be constrained by the architecture or engineering. For example due to data rate limits or costs.
Design isn't a set of requirements or a schematic, it is an iterative process where what is possible and thought best is improved, iterated, and captured through discussion. Not only is design a shortcut to the system that stakeholders want, design is a magic door to the system that stakeholders didn't know they wanted.
Now that we are in a post-digitisation world, more and more of what used to be design has become simply analysis, used to verbatim reproduce an old process or interface within a replacement system.
Engineering is what and how...
Engineering is the what and how (inside the system) - things like technology, algorithms, and design patterns. Also, generic resources such as databases, proxies, and compute platforms. These are implementation details. Deep dive topics which ARE useful for developers or operations in the right context, but can easily be separated from your architecture.
Engineering details matter for some stakeholders such as security or DevOps engineers, but they are a distraction in more abstract contexts such as when you are developing your application. Flagging a few of the highest level engineering concerns is a good compromise, and is something the C4 Model has handled well for structural diagrams.
Architecture is where…
Architecture is where things live (akin to city planning). This is the structure of the system, at a higher level of abstraction than engineering, thus why I describe the database as engineering. It is encapsulated within the architecture. It organises the engineering so that it effectively implements the design.
We are also making the overall picture coherent - across lots of different axes. Architecture references detail from the design, engineering, and the application's context.
Architecture is also why…
Architecture is also why we are doing things. Knowing why enables us to make decisions to change things. If we don’t know why something is in place we need to discover and assess what it was doing. For some things you will find there is no reason why, it just happened like that.
The question of why often involves the non-functional requirements of the application - the “ility” words. Reusability, modularity, testability, scalability, etc. These lead to choices in terms of engineering. Architecture is the decision, not the definition of those choices.
In architecture, we are solving problems at scale, determining approaches that usually minimise engineering while maximising value.
We are also affecting or enforcing policies, which can indeed add complexity or cost, but the policies have desirable properties such as security or availability. When architecture is successful these benefits are coming through automatically. When we are lucky, simply choosing the right tools will offer some of this value.
Iterating and capture…
Architecture benefits from fast feedback and conversations, just like design, and we capture those designs with artefacts. The same artefacts are the foundation to both design and architecture, and additional stages of enrichment can then provide additional insights in both areas. Our efforts avoid rework and allow better choices. Iterating (redrafting) and capturing (writing down to share and recall) has the same improving and accelerating effect on solutions.
We are talking about choices, and if you have fast and expressive conversations you can make a lot more choices than if you don't.
State of Play
Over the years I have seen many teams producing a lot of engineering artefacts, but much less design and architecture. People use engineering to bring favourable traits to their system, but they also use it as lipstick for a bad architecture, or to bamboozle stakeholders who never got to be involved in a design.
You can't make informed decisions around architecture without a design. When somebody asks you to “show me the architecture” of your system you need to start with the high-level design.
Teams have taken the view that by regularly releasing software they don't need a design. Regular releases provide all the feedback they need.
I hate to be the breaker of bad news, but there are much faster and less expensive ways to get a good idea of what people want, you need to move to validating through releases rather than designing through releases. So many times I have seen a development team implement a feature or functionality, and then the stakeholders just accept or tweak it due to it being "too late" to change anything. I have even seen when a feature is implemented and then after it is deployed to production the feature is then rolled back, due to it disabling important functionality that users relied on. We need more design conversations with users.
We can develop ideas faster than releases
Agile isn't about stripping the development process down to coding in small chunks, lean of everything but code. It is about feedback loops - and those small loops go all the way back to stakeholder conversations. We are once again seeing the weight engineering has acquired over design and architecture, where the majority of the feedback loops end up accumulating in operations.
Analysing the trend
First of all, there are many factors at play here. One of which is the agile manifesto, which has a blind spot in the "over" statements regarding the importance of design. There are lots of clues there - "Individuals and interactions", "Customer collaboration" - but it isn't explicit. There is also a problematic statement:
Working software over comprehensive documentation
Teams regularly misinterpret this as meaning design and documentation are not part of the process, we should only code - working software INSTEAD OF comprehensive documentation. It was further exacerbated by "Clean Code" evangelism, which explicitly demonised commenting code - it is clear how this reinforces the INSTEAD OF misinterpretation above.
A further problem is cloud certifications. We have already touched on the common misunderstanding that infrastructure is architecture. There are now many people who think a solutions architect is somebody who helps you integrate with a large cloud provider's platform, rather than integrate an application or system into your broader enterprise.
Add to that Most Valuable Player and Community Builder awards/hats and this brings further focus to engineering-focused patterns and practices. If a software engineer wants to learn for free, they will likely be attending a product-focused community, which may well have developer relations or developer advocate speakers delivering the content.
We have barely touched the surface, in that all of the above context leads to further knock-on factors within organisations, the jobs market, and even social media and conferences.
Fixing the trend
We need to get to the point where people are happy to design software, and that means to collaboratively design software, having rich conversations with stakeholders about how the software should work. The term user story does not describe a work item, or even an "as a" statement. The idea originates from the user telling you what excites them, and you exploring the design together. Collaborative design.
The only way to make a seismic change in our industry would be something of the same magnitude as the original agile manifesto, but there is a reluctance to redefine what is already there. Many people have already tried, and are just seen as trying to self-promote. This may well be the case!
The closest thing we have to a solution is domain-driven design, which emphasises the importance of stakeholder conversations, and how that feeds through into design, code and architecture.
But domain-driven design is a prickly pear, with difficult terminology, and practices that have evolved significantly over the last 21 years beyond their origins. These points came up in conversation on the fringes of Kandddinsky '24 and is a real blocker to us solving the broader software design problem in our industry.
You don't need a cutting-edge system to deliver most software requirements
Right now, until something with more magnitude is possible, my best advice for you is to invest in quality using proven products and tools. You don't need a cutting-edge system to deliver most software requirements. Use low volatility and reliable components to avoid engineering distractions. By focusing on your design and architecture instead you will create better business processes, improve your agility, and increase your solution longevity.
I have seen designed systems last 20 or more years with relatively lightweight maintenance, and they still remain evolvable. I have seen undesigned systems cancelled or declared legacy within years.
Like we have had #nosql and #nouml we need #yesdesign. We are not talking about heavy-weight model-driven development. We are talking about a sensible middle position where we evolve a solution and talk to our customers. #yesdesign
©️ Read the Architecture Ltd.
Top comments (0)