O’Reilly Software Architecture Conference — from a developer’s point of view
I have been at O’Reilly Software Architecture Conference at London couple of days ago. As a developer and a potential future software architect I naturally approached every presentation with double standards and assessed every talks via two different, some time contradictory lenses. The developer and the architect lenses.
As a developer I always need examples, runnable code, github links, things I can easily connect to my daily work, what makes my life easier or more efficient. Those things tend to be low level, closer to the code. From an architect’s point of view maybe they are just implementation details but as a developer I feel them to be important part of my daily life. I hoped the conference can show new technological trends and potentially code examples and if it is possible some more code examples :)
As a software architect apprentice I desperately need clarity about the role itself. What being a “Software Architect” means? What skills make a “Software Architect” be successful? What is a “Software Architect” role at all? Assuming I have a bit of clarity about the role I also need hints, ideas, guidance about the process of becoming a “Software Architect”. Things which might help to grow into this position tend to be more abstract and higher level and not necessarily technical. There are some nice articles out there in this topic but I hoped the conference can also shed some light on this topic as well.
Microservice talks are still dominating the space
It was bit surprising that almost every talk somehow touched microservices. There are places where they are just no brainers and part of the daily development process however based on the number of related talks the vast majority of the IT organisations are still struggling with agility, testability , deployability, scalability and availability. According to Mark Richards these are the main drivers where a microservice architecture/modularity can be a superior over a monolith.
Agility: The ability to respond quickly. Low agility requires loads of coordination between multiple teams meanwhile modular application has more flexibility via isolated changes and independence.
Testability: Changes limited to individual isolated units result in much higher testability since the scope is reduced therefore also helps to increase completeness of testing.
Deployability: For a monolith we tend to group changes together and deploy the entire software as one piece which has significantly higher risk. As the result of this risk there are less frequent roll-outs but with more ceremony involved. However with a modular software the change set is isolated and risk is mitigated which leads more frequent releases.
Scalability: You can scale out the monolith but it means you scale out the entire application regardless of the real demand, however for a modular architecture you can achieve functional scalability.
Availability: If you have a malfunctional software piece that could bring down the whole application and your whole operation is impacted however the same misbehaving software piece will just affect only that one service.
If you are in the position where any of them is a pressing issue then you are better of breaking the monolith. However it is not something you can do from day 0. This is more like steeplechase.
- first you have to be able to sit on the horse sound and stable
- then start walking, galloping, riding fast
- finally steeplechasing
Breaking the monolith is a hard learning process!
Using this brilliant analogy the recommended first step in this journey is to split the monolith into ”service oriented components”
- use the same database for the new services
- use your old pipeline
- start experimenting and learning relevant technologies
This way of learning process doesn’t require Devops, neither requires any organisational change!
However, as getting confident with the first step you certainly have to consider organisational change! Conway’s Law also underlines the need of such a change.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
You have to move towards a collaboration model where different disciplines (developers, testers, devops, UX) working together in a mixed team towards the common goal. It helps to break down communication barriers and empower autonomous teams.
One common mistake usually made at this point is that “unnecessary” part of the architecture is converted to be a microservice.
Not every portion of an application needs to be migrated to microservices
When you decide on carving out a module, you have to answer the following questions first: Which are the areas where the above mentioned drivers deliver the most value? Your customer facing critical part of the monolith most certainly will benefit from being converting to microservices, however it is not certainly true for your administration pieces.
By this time you should have a very good understanding how to ride fast/split your monolith but you are just partially there, the hard bit is not solved. Data haven’t been touched yet! Services are still using shared database. This is the stage where steeplechase starts. Moving the data where it belongs to.
I really liked how this talk was built and presented. Since at my current position I daily have to tackle the above presented issue it found the message very practical. Despite the fact that there wasn’t any code involved my developer part still enjoyed it.
Thoughts about the “Software Architect” role
Given the fact that the conference’s title was “O’Reilly Software Architecture Conference” it is not surprising that there were couple of talks about the “Software Architect” role itself.
First of all, based in Wiki:
the “Architect” is responsible for planing, designing, and reviewing the construction of buildings, operating within a strictly regulated environment
They are responsible and accountable by law.
Using this analogy “Software Architect” is meant to build complex applications but actually most of the cases they/we are not regulated at all. As Nathaniel Schutta described the situation we just sweep things under the rug when something goes wrong…
Software architecting is more like trying than real engineering
But why we need a “Software Architect”?
From Simon Brown we know that every software team needs to consider software architecture. The opposite of a designed system is not a system without design but a bad design, bad software architecture!
Based on the attended talks, apparently there are two main areas where an imaginary, ideal “Software Architect” should excel! Not surprisingly there are technical and non technical skills what he has to master.
Technology related skills:
- Broad and deep technical knowledge
- Evaluate technologies and make decisions often quickly with incomplete information
- Provide continuous technical leadership for teams
- Dedicate 20–30% of your time for actual project coding. Spikes, POCs can be good but the real value lies in the project contribution
- Time to time participate in code review processes
Non technical skills are often underrated but in practice they are as important skills as technical ones:
- Have to be able to sell decisions to various audience. It can be extremely difficult since it requires different language, jargon, metaphors and approach. Stakeholders tend to vote with their foot. Worst case they want to leave the project or the company…
- Translation layer of the company.
- Good architect enables agility. Empowers teams to realise their full potential
- Be the institutional memory, kind of living document and story teller of the current architecture and its history.
- Coach and mentor
In summary focus on these 3 things:
Code, Coach, Collaboration
General feedback about the conference
First thing I have to share about the conference is the following:
“We’ll make the Keynotes available here as soon as possible after they happen. Video of the sessions and tutorials will be available a few weeks after the end of the conference.”
I have been many conferences recently. Most of them made the session videos available just immediately after the presentation or even providing on-line capabilities to follow sessions. I don’t know the real reason behind this decision which might be legal, financial, technical or mixture of all but I would expect O’Reilly as one of the biggest technology supporter to be able to publish videos within a day as they did with keynotes…
All in all we enjoyed the conference, we had a good time there but my developer part remained a bit hungry… I am not saying it starved to death but more details would have been good… Probably I just have to visit more themed conferences in the future. But the good news is that I am closer to understand what it is meant to be a “Software Architect”. :)
Credit goes to Mark Richards, Nathaniel Schutta, Simon Brown. I used loads of ideas and pictures from their talk to put together this post.
