Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] The architecture council identity crisis....

It feels good to read your note and feels even better to comment on your ideas :)

My own view on how to make the AC effective is to start by reviewing its charter; this should be a document where shall' or 'may' will not have a place.

I assume that every member of the AC is either the AG lead for the project it represents or a technical lead of the project. So at the AC level, it is not about guiding their team but working with the rest of the technical leads and guide the Eclipse project community as a whole.

Two of the AC imperatives to be added to the charter ( this is an incomplete list but it covers the most important things as I see them )

- cooperate at a technical level to impose good integration between projects; report back to AC on their execution
The catalog of reusable assets is a good fit for this. Any other integration issues should be brought up, reviewed and have recommendations on how to fix them.

- based on technical decisions made at the AC level, provide technical guidelines to their own projects; report back to AC on their execution
Basic samples : jarred plugins, plugin manifest files, string properties to use NLS bundle and be removed from the

- technically mentor new projects

I see AC being no different than the AG leader of an Eclipse project contributed to by different groups. At the end of the day, the mission of the AG lead is to guide the project in such a way that the functionality offered by the project satisfies all groups while integrating with the rest of the project's capabilities. The end user satisfaction is the main goal.

Thank you,
Valentina Popescu
Senior Advisory Analyst
IBM Toronto Labs
Phone:  (905)413-2412         (tie-line  969)
Fax: (905) 413-4850

"Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>
Sent by:

12/07/2006 11:20 PM

Please respond to
""        <>

"Scharf, Michael" <Michael.Scharf@xxxxxxxxxxxxx>
[] The architecture council        identity crisis....


At the last architecture council face to face meeting, we
came up with the idea to create a forum called "Ask the
architecture council". I was supposed come up with a plan for
such a list. I have been thinking a bit further and I think,
unless we have a clear vision and mission as architecture
council, such an effort will not really take off.

I ask some fundamental questions about the architecture
council. I describe what think (thought) the architecture council
should be. Finally I collected a very incomplete and biased
set of questions. The hope is to start some discussions.

The fundamental questions

The fundamental questions we (the architecture council)
have to solve are:

- What value do we add to eclipse?
- What *is* the architecture council?
- Why do we meet?
- How to get the architecture council to do something useful?
 The mailing list is still pretty dead and it seems non of
 us really spends a lot of time or energy on it.

I think we should either come up is a clear vision and
mission of what the architecture council is or cancel the
architecture council.

The rest of the mail are some of my thoughts and questions
about the architecture council.

What I thought the architecture council is

When I first came to the architecture council, my
expectation was that this is the group that consciously
thinks about the architectural principles behind eclipse.

I often have the problem that I am not sure that the
architecture principles I extract from looking at good
eclipse projects like the platform are the "right"
principles. This makes it hard for me to "enforce" those
principles in the projects I am working on. I thought this
is the group that distills and spreads the principles. I
find it very hard to "enforce" or "require" anything in a
project, when I am the lonely fighter. I ask myself:
 "Is it just my idea?"
 "Am I pushing people into the wrong direction just
  because I think this is 'right'?"

My hope is that the architecture council becomes the group
that looks at eclipse from a higher level and gives eclipse
a technical direction. Working on a project that has a
certain "culture" it is often very hard to step back and to
see the project without bias. My hope is that the
architecture council can help me to eliminate the blind

When I study excellent software systems, I ask myself what
are the principles are practices behind the system that make
the software successful. Over the years I came to the
conclusion that it does not matter too much what the
principles are, as long as there are used consistently
within the project. I wonder if eclipse still has a set of
principles that are used everywhere and if they are strong

Some ideas and questions for the architecture council

I collected some random questions that came to my mind when
thinking about the architecture council. I tried to put them
into different categories, but there are really a kind of
brainstorming with myself.


- What are the principles that worked in the projects you are
 working on?

- How are those principles defined? How are they maintained?

- Where is the knowledge encoded? At the moment it seems
 that the platform guys are the "gods". Where are the
 "gods" in the architecture council? Why are they not coming?

- How can architecture be maintained and increased in
 highly distributed software development?

- How can we achieve consistency across the projects?

- We think the platform is a good "blueprint" of how to do
 things. How can we spread this knowledge?

- What is the "eclipse way" of doing design and architecture?

- Should we give a talk at eclipsecon about "What is the
 Architecture Council?"

Structural questions

- How does your project split code into eclipse projects and

- How do you deal with massive code contributions that have
 little functionality?

- How to drastically reduce the massive amount of code?

- How to structure my code into projects?

- How to reduce cross project dependencies?

- How do we enhance cross-project communication?

- How to avoid duplication of code?

- What should become base technology usable by everybody?

- How to find out what's code is out there?

Technical questions

- What is your biggest technical challenge?

- Are there threading concerns in your code?

- What caused performance problems in your code? What can we
 learn from that?

- I want to learn about the process of defining good APIs.

- How to define stable APIs and to keep the code flexible at
 the same time?

Social aspects

- How to deal with team-blindness?

- What are the principles behind decision making?
 I believe that communities are very powerful in making
 decisions. However often technical decisions are
 made somehow randomly (the one who speaks loudest or
 implements wins).
 - Should there be a process to think at a higher level
   about what is going on?  
 - Who is reflecting about the technical decisions?

- How to deal with Concerns on how something is done?
 I have often seen that people have valid concerns but dare
 to speak up. Can we as the architecture council help to
 get a process in to place where technical issues are
 raises? Maybe by allowing to get anonymously in contact
 with the architecture council?

- How to motivate people to do things of technical importance?

Do you think it's worth thinking about those questions? Are
they relevant for the architecture council? Did anybody read
this mail to the end???

_______________________________________________ mailing list

Back to the top