Council of Prague Agenda: Ring of Ethereum Architects gathering


Representing the big system integrator and delivering a number of Blockchain projects to enterprise clients I regularly have a need to discuss and/or validate the solution architecture of my projects with someone experienced, someone who has different or broader view on the underlying (Ethereum) technology, its components or its future. I often need to check technology assumptions, discuss software architecture patterns and integration possibilities with someone who is proven to be an expert (and better with the group of experts). Also the presence of quality materials explaining the typical architecture choices, common patterns and guiding through a number of architecture decisions should simplify and speed up the solution delivery, increase its quality and standardization.

I see the mission of the Ring of Ethereum Architects (REA) in guiding the underlying architectures for Ethereum based solutions. At the moment I can see three aspects to this mission:

  1. to document and build consensus around principles of Ethereum reference architecture and to interpret and clarify these principles when necessary;
  2. to guide through solution design challenges involving general Ethereum architecture brought to the REA and provide a library of relevant design patterns;
  3. to help coordinate cross-technology architecture developments inside and outside Ethereum.
  4. To keep a list of the recognized Ethereum architects

No set of documents will ever answer all the hard questions, so interpretation and subsequent refinement of the Ethereum reference architecture will certainly be necessary. The REA will not just document what is widely accepted; it will also anticipate growth and fundamental interoperability problems. Elaborating the intended direction of the Ethereum reference architecture will help resolve issues when setting future directions, help establish criteria for starting new work, and help community coordinate its work with that of other organizations.

As a start of ring work I propose the initial REA meeting plan as follows:

  • The REA will hold a regularly scheduled distributed meeting (at least every month).
  • The REA will organize occasional face-to-face meetings (I can provide the office space in the Netherlands or Germany).
  • The REA may organize workshops to explore particular architectural issues.

Looking forward to the opinions, critics, support and also to see faces of people with similar needs in Prague.


BTW, If you are new here please, read the text
Forming a Ring of Ethereum Architects.
It explains what the Ring of EA is about.

My motivation is (additionally to @apitkevich) …

  1. to have an up-to-date overview about current state of Ethereum ecosystem, in particular for Frameworks and Tooling.
  2. I would like to be in short list of skilled architects available for work in corporate projects. (*)

I would propose the Agenda for the Meetup as following:

  1. combine all our needs and motivations in one list.
  2. understand our interconections to other Rings.
  3. define a roadmap
  4. define how and when we achieve next goals of the roadmap.

(*) P.S. Please consider “My Motivation” as an example UseCase. Implementation is to be discussed.
For sure it is not my goal to create a claim in the name of whole community to be the best guy.

@pet3rpan, @eolszewski, @MadeofTin, @a4nkit, @chris-remus, @atoulme

Are you still interested to take part in the discussion?
You are kindly welcome to add here more topics to discuss for coming meetup.

I’m fine with the proposed meet up agenda. Just small practical add-on

  1. agree on practicalities (communications, meetings, etc)

That’s a bit political, and I would argue unnecessary.

If you are doing the job of an architect correctly, your reputation proceeds you and I think any consulting work you wish to do would come naturally. I don’t think we need an actual list or endorsement to be successful.

Otherwise, it all sounds good to me

1 Like

Guys, please turn your plans for EA gathering into a structured session outline as described and sourced here: Ring Maker Toolkit: making meaningful gatherings

1 Like

yes, you are completely right here. It is not healthy to setup own list of skilled architects with founders on the top. It is not my goal.

Consider it as an Incentive and UseCase description. It is just a usual wording for UseCase Description “As X I would like to do Y”.
A corp like @apitkevich represents, wants to use the list. Architects have incentives to be in the list. I mean it is a valid UseCase description then. How this list can be set up and what does it mean, it is the second question and subject for further discussions.

Well, the list is still a distraction from the real work an architect can do, which is bring projects together and build foundations for successful projects.

The reality is you can claim to be in the REA. Anyone can. If someone is impressed with that and hires you, then so be it. If they are smart, they look into your history and see all the awesome things you’ve done, which hopefully speaks about your legitimacy. A list will not do that, at least not without major editing. A list of people’s names by itself means nothing without their project history.

Why manage a list of everyone’s resumes, when everyone can just manage their own resumes?

Well, the list is still a distraction from the real work an architect can do, which is bring projects together and build foundations for successful projects.

I would not see it so restrictive. The “real EA’s work” is not inside the Ethereum community only. They also act as an interface to corporate world, because that is what corps are looking for (read the post from @apitkevich). EAs help to adopt the technology by corps and collect requirements from them. It makes sense and win-win for all.

As I stated in Forming a Ring of EA post, the Architect role is aimed to be “financially self-sufficient”. Corps are ready to pay for the architect knowledge and it is how the EAs can earn some money. IMHO, it is important to give people a possibility to earn money with their skills.

The reality is you can claim to be in the REA. Anyone can. If someone is impressed with that and hires you,

Why manage a list of everyone’s resumes, when everyone can just manage their own resumes?

What you are describing is an example of some bad implementation. Let us find the better one.
What I have mentioned, there is a valid demand: сorps will find people, and people would like to be found.

Cooperation between REA and industry is important for both sides. I see the “List” as an interface between them.

a. Corps need to find people
b. People want to be found

So, we make a list. People want to be on the list because of a and b. Now there is incentivize to be on this list. Who manages the list? Well, if it is a person or group of people, they have direct control over discovery of these architects. If it is the entire REA, then the ring is no longer permissionless as we are gatekeeping. If there is no gatekeeper, then there is no list, it is just a participation badge (which is fine!)

You can get into something fancy with TCRs, but they haven’t really been proven widely in practice and it’s still a gatekeeper functionality at the end of the day, albeit a more incentive-aligned one. It is also a massive distraction, you are constantly worried about your position on the list as it directly affects your ability to get work. You could argue brand building is the same thing, but it makes the implicit explicit.

Good architects will be “financially self-sufficient” by being good architects. Participating in the REA and sharing your knowledge on how you can be most efficient and solve problems for corp clients is a sign of being a good Ethereum architect, because it’s a sign that you believe radical colloboration (not competition) gets work done faster and better. Your resume and the work you’ve done in the past fills in the rest of blanks.

A list either devolves meaninglessness (badges), or is a gatekeeping function that prevents others from realizing their own abilities and turns all of it into a competitive game instead of a cooperative one.

I don’t want to build REA as that system. You can feel free to, but I’d like to keep the ring permissionless and colloborative so we can all grow, do well, and help others.

I think that list bit sounds more argumentative than I meant it, but I believe colloboration and permissionlessness is a core strength of Ethereum.

If you want to talk about a reputation system, that is a different discussion I think

IMHO.The discussion about “The list of architects” is worth of separate topic because its importance and it is not about agenda any more.

Would you agree to extract it into separate topic?

1 Like

Absolutely haha. We can argue the merits in a separate discussion lol.

I think the list is necessary and we can discuss on 29th the various approaches how it can be created and maintained.
Please look at it now just like a requirements for the interface - the list of architects should be available for those who is seeking. How the underlaying data is collected is a separate question. Representing a big consultancy I can confirm that it is my requirement to have a simple access to the list of recognized architects…
And, yes, I certainly will look into the details of how this list is created and how credible the people there. And obviously I’ll form my own opinion trust or not the information in the list based on the multiple factors including the feedback loop. But all these is still needs to be designed, implemented and tested…
And honestly despite the fact the list is an important component I was hoping to attract people who are not only interested to be placed in the list but also are interested to work on architecture materials.

“The List of Architects” discussion is moved to the new topic Creating list of architects. Please continue there.

Here we are collecting topics for our agenda

1 Like

Done (to the certain extend), thank you :grinning:

Awesome! You are the best, @apitkevich!
For outputs, I would suggest you prepare the format in advance. This way it will be easier for participants to understand what they need to produce. It’s much easier filling in the existing format than coming up with the format and then filling it up, all during the workshop.
It seems HackMD or google docs are standard so you can use these, when you create the template, you can just add the link to the list of session outputs.