visit
In the year since I started as the Chief Architect for I’ve designed at least a dozen blockchain applications.Success is not final, failure is not fatal: it is the courage to continue that counts.- Winston Churchill
My first task when I was hired was to write an article about how to get started on blockchain as an architect. To date it still is my most popular article but now it is time to write a second part to it. That first article condensed 80 hours of experience, this one more than a thousand.
Please keep on reading to find out the skills that I’ve found most useful as I translated business ideas into technology solutions, in projects from concept stage to implementation.Some people think that the defining characteristic of an architect is that they know a lot about technology and has some leadership role. Knowing a lot about technology or about business always helps, but what an architect actually does is to understand and communicate. My solution design process goes like this:
Photo by from — I think I get it… You want to sell party hats… On the blockchain… As an architect for TechHQ, I happen to know a lot about blockchain, but for every project I have to learn several new concepts. This month I’ve learnt how the and how to do , for example.
Knowing a lot about technology or about business always helps, but what an architect actually does is to understand and communicate.
This constant learning and proposing process also means being wrong most of the time. Only after being wrong a number of times you will have learnt enough to propose a solution that actually fits.
If you want to succeed as an architect, you must focus on being able to learn on a broad range of subjects, understand anyone and make yourself understood by anyone.Photo by from — How I feel when you tell me you have your own consensus algorithm. Many of these projects never went past the concept stage, but all of them were useful for me. I’m quite a productivity nerd and always record the time for each task I do. What took me 24 hours of work with the first project I could do in 4 hours a few months later. The materials I had to produce were mostly text with a few diagrams and sometimes a code example. The text ranged from academic solution descriptions to marketing manifestos. To say that sometimes I was out of my league is an understatement, but anyway everyone is out of their league most of the time. Even Vitalik. Talented people don’t stay in their comfort zone. This broad focus was the best thing that happened to my training.
When I joined TechHQ I realised that the blockchain environment was so immature that I could get to the top of the learning curve within a few months. While that is still true, I don’t find it possible anymore to know everything about blockchain. In any project someone needs to know about these things:
Photo by Pixabay from — “Then you do truffle migrate — reset and on the other terminal tab yarn start…”
Blockchain infrastructure: I started by learning a lot about the blockchain infrastructure. Bitcoin, Ethereum, Hyperledger, Quorum, Corda and many other projects are in this space. However, for most of the last year I’ve worked on or , with the occasional project. Right now I think that it is enough to have a passing understanding of other platforms and having people to talk to at the infrastructure level. A lot will happen here in the next few years, so you need to be ready for an eventual major development.
Blockchain Development Tools: Here I’ve learnt how to work at a basic level with metamask, ganache and truffle, and that is about it.You need much more than that in a project and I’m grateful that I have that seems to know how everything works and never stops delivering cool stuff (, ). If you are going to code you need to fill this gap somehow, and it is a difficult one due to how fast the tools change.
Smart Contract Development: I learnt to code smart contracts and that allowed me to gain a deeper understanding of blockchain opportunities and development patterns. Software development is closer to the business side than development tools or infrastructure, so if you have to choose which one to learn more of, I’d focus on this one.
Other technology fields: Cloud Architecture, Networking, DevOps, Testing, Frontend Development, User Experience, Graphic Design. Sometimes you will need some help here, but most of the time you’ll be better off letting someone else do the very necessary work. Focus on where you add value.
Other project roles: If you suck (as I do) at project managing or team leadership, make there is someone else to do those roles. Startups are always strapped of resources and you will find yourself pulled towards these roles by their proximity to the architect role. If I have to help with a non-technology role I will always choose that of business analyst, since it allows me to understand the business better.
Still not sure about those asserts. A peculiarity of smart contract development is that it forces you to produce simple code, at least in Ethereum. In most blockchain solutions the smart contracts will be less than 10% of the code. What I’ve found is this makes coding smart contracts easier than common software because once you code a small core the rest is offloaded to the frontend. This is great for me as an architect, because I can code that implement the business ideas of a solution and that stay mostly unchanged in production. Coding is still very time-consuming, so I only do it when I have the time and when the project needs it. As an architect your hourly rate is quite high and you need to be mindful to provide value for it. However, coding is sometimes the best way to show what you mean to the technology side.
Smart contract development led me to understand staking patterns, tokenization, currency exchanges, payments distribution and access control with deep detail, and those patterns come up again and again when trying to propose solutions to business ideas.
I do blockchain. With blocks.
Breaking down solutions into general patterns allows you to think quickly about what the technology opportunities are for a specific use case and guide your discussions with the business owners. This is very important for the architect, you need to explain to the business side what your proposal is in terms that they understand, and breaking it down is helpful for everyone.
I would be kicked off to the street if I would write my articles with this. As an architect you are perceived as a leader, but this is not true at the start of a project. For the first few iterations you are learning from the business and technology sides so that you can propose solutions. You will need to be a leader when those iterations reach an end without satisfying everyone and you need to broker a compromise between stakeholders.. By writing frequently not only you refine your own thinking and arguments, but those articles also work as some proof that you know what you are talking about. You don’t want people to follow you blindly, and you definitely don’t want to use the argument that you know your stuff and others should shut up, but first impressions are important, and often what you write are those first impressions.
The other benefit that learning to write has on your job as an architect, is that all my projects are delivered in a written form. There might be code and there are lots and lots of talking, but at the end, there is always some text that is taken to far places. It makes it into the whitepaper, it gets distilled into two-pagers and pitches. I write a lot now, and it becomes easier and easier. It is definitely one of my main skills today.
As an architect for an up and coming software development firm I’ve designed dozens of blockchain solutions with different degrees of detail and success. It took me 80 hours to feel that I had an idea of blockchain and to start designing solutions. For the thousand next hours the learning pace only accelerated.
If you want my advice on how to become a better blockchain architect, I’d suggest you do the following: