Let’s continue with our Software Architecture Journey: Key lessons learned series. This month Apiumhub team has interviewed Eoin Woods – Global Software Architecture SummitSpeaker and CTO at Endava, where he leads the technical strategy for the firm, guides capability development and directs investment in emerging technologies. Eoin is a widely published author in both the research and industrial communities and a regular conference speaker. His main technical interests are software architecture, distributed systems and computer security. He was the recipient of the 2018 Linda Northrup Award for Software Architecture, from the Software Engineering Institute at CMU. And today we will cover key software architecture insights.
I define software architecture as the design decisions that are hard to change in a software system, which usually means trading off between different stakeholder needs and making sure the system achieves an acceptable set of quality attributes – again a set of tradeoffs.
Diplomacy, leadership, communication and listening. (Sorry, that is four!)
People interpret the role differently, but in my opinion they are to understand stakeholder needs, take responsibility for achieving the quality attributes of the system, and to provide technical leadership.
Software architectures need to be fit for purpose (i.e. solve the right problem), as simple as possible and widely understood.
Honestly I don’t think we have very many good ones. The obvious ones are complexity, coupling, cohesion and other structural metrics. They’re fine, and easy to measure, which is why we use them. But they only measure a small part of the problem. All of the quality attributes, including things like cost to build, can be measured and they are measures of the effectiveness of the architecture, if not measurements of the architecture itself.
They are two different models for how to think about systems. They are complementary rather than in opposition. Critical thinking leads us to question our assumptions and initial reactions when considering a situation. Systems thinking leads us to consider the entire system that we are designing, including its environment, which is often a socio-technical system-of-systems problem rather than just a software structuring problem.
Pragmatism is what allows innovation to be effective and thrive. Without thinking about the tradeoffs and practicalities of an innovative idea, you are probably dooming it to failure. However exciting an idea, it has to be practical and useful.
Achieving intellectual control over a system is probably the most important overarching responsibility of a software architect because no one else is likely to have it.
You can write a lot about system performance, and many people (including me) have done so. Summarising it to a couple of points, I think that reducing the amount of work the system has to do, avoiding contention between system components, and keeping the system as simple as possible are some generic tactics which are valuable in achieving good performance.
What are your expectations regarding software architecture events, do you think in 2021 everything will be online?
Sadly I think things will be online until at least the summer of 2021. That’s what we’re planning for at Endava anyway. I’m hopeful that by the Autumn we might be getting back to face-to-face events.
More emphasis on cloud-native systems and use of cloud services (such as cognitive services or PaaS database services). Some interest in modelling seems to be coming back. Event-driven architecture seems to be re-emerging in some places, but in a rather “anemic” form where it isn’t much more than message-driven processing.
No, sadly not.
I don’t think it is “vs” I think elasticity is a very valuable mechanism for achieving scalability.
Architecture styles and patterns are a really valuable way of codifying knowledge and having clear discussions about design options. Whenever I look at a system, or think about how to design one, one of my first questions is “what style is that?” or “which style would work here?”
What recommendation would you give to big international companies in terms of software architecture?
Don’t try to do architecture (or software engineering in general) at big international scale. Agree on some basic fundamentals to allow interoperation and then let the teams working on each piece of your enterprise architecture to choose their own approach. So some shared data modelling is useful to allow interoperability, telling every team to use the same CI tools isn’t.
Do just enough so you know the tradeoffs in your architecture. Make sure you know what decisions you have made and make them intentionally. This allows you to know what is possible and what isn’t possible when you come to pivot commercially in search of success.
The main problem is people not doing it and thinking that (for example) Domain Driven Design is “architecture”. I love DDD and think it is a really effective design technique for application code. But it doesn’t solve most of your architecture problems. Software architecture is so much more than the structure of the code.
Get to know your stakeholders, keep learning, challenge your assumptions, be respectful, avoid overconfidence in your own abilities, use the right tool for the job, not the last one you happened to use, obsess about quality attributes because no one else will.
Eoin Woods is CTO at Endava, where he leads the technical strategy for the firm, guides capability development and directs investment in emerging technologies. Eoin is a widely published author in both the research and industrial communities and a regular conference speaker. His main technical interests are software architecture, distributed systems and computer security. He was the recipient of the 2018 Linda Northrup Award for Software Architecture, from the Software Engineering Institute at CMU
The post Software architecture insights: interview with Eoin Woods appeared first on Apiumhub.