Home | Login | Recent Changes | Search | All Pages | Help

AnArchitectureSession

I hope you fellow architects are in for brainstorming possibilities for (AYE) sessions. What I have understood so far -from myself and others- are that the following sessions could be useful:

- TheInn: setting up its GroundRules - Satir 5 freedoms, McLendon 7 A's, open source development - TheInn: refactoring its architecture - Agile, XP, patterns, anticipating culture, introspecting organizations/structure - ProblemSolvingHologram: translating the Satir Iceberg for organizational purposes - Spell casting skills, organizational development, enterprise architecture - ArchitectsArtifactExposition: exposing our artifacts and discussing (re)usefulness - Diagrams, visual facilitation, spell casting skills Any thoughts on the above? What else? -- From NynkeFokma

JerryWeinberg

BobLee

Bob, where did you read about Conway's Law? (I thought I discovered it!) -- JohannaRothman 2002.05.09

JR - I thought I discovered it, too, but it's been around the fringes and April Fools issues of Datamation too long. I don't remember where I hit it first. Jerry or Jim Bullock might remember, they both have a pretty good catalog of "laws" and their origins. I keep about 3-4 manila folders labeled "Funny Money" stuffed with bits of computer humor with enough truth to fold back in later. Humor is the only way to I know to keep beating stress. BobLee 2002.05.11

One of the things I've seen going around is some tension between XP / Agile movement and Architecting [A.K.A. BDUF = Big Design Up Front]

My view is that XP et al work only as long as the team sizes fit -- about 10-12 people, probably 2-8 or so developer types. Projects too big for 8 developers blow the communications bandwidth that makes agile projects work.

Can you relate big projects through architecture to allow the agile to engage?

How do you, as an architect address this current "hot issue?"

Perhaps we get into the equivalent of Skyscraper architecture vs. Tract House architecture here. How does scale affect the architect & his tasks?

BobLee

The value of Architecture. Convincing others (i.e. non-architects) that this somewhat invisible, nebulously defined specialization of Software Engineering actually exists and is worth funding and nurturing. I raise this question at a time when the demand for experienced SW Engineers (i.e. Human beings with the life experience and professional experience to perform architecture well) is low and organizations instead choose new graduates or seek to match relatively inexperienced, low paid programmers to overly detailed job descriptions based on very specific and very exact technology and subject matter descriptions. Is there or isn't there a perceived value for generalists that can jump from one subject area or technology to another with ease and for someone who has chosen to master the skills of intra-personal and inter-personal communication? If so, why don't the Help Wanted ads reflect it? When will Software Architecture grow up?

IraWeinstein

Ira, I believe hiring managers do not know the value of architects or senior level anyones. I suspect that's because the managers themselves are not good at what they do. The other reason hiring managers don't know to advertise for architects is that they're too willing to hand over that part of the hiring process to HR, who has no clue what software architects do. I wrote an article about this for Stickyminds, using testers as an example. Maybe it's time to write an article using architects as an example? -- JohannaRothman 2002.05.09

I would very much like to sponsor an architecture session at this year's conference. And it seems that it is one of my life's ironies that architecting a session on architecture is hard for me to do. If one or two of you want to do this, I believe that I can ensure a spot on the schedule.

As a default, we could set up a session entitled "the architecture session". It will begin with no structure or expectations and will follow the energy of who attends. BobKing

The session will work on the following architecture problem:

Design a training program for system architects.

You have three hours, and whatever resources you can muster.

That's it.

You're welcome.

JerryWeinberg

Thanks, BobKing

Session presenters: Bob King, another presenter

Session wiki description

If you could create the ideal system architect, how would you do that? If you wanted to become an ideal system architect, how would you do that? In this session, we will design a training program for system architects. You will have three hours and whatever resources you can muster or think of to create the curriculum to create the ideal system architect.

Session learning objectives - consider what an 'ideal' system architect might be - consider how system architects become what they (we) are - find something that might help us work better with system architects or - find something that might help us work better as system architects

Prerequisites (anything required before this session?) none

Minimum number of people (what's the minimum?) 4

Maximum number of people (what's the maximum?) none

Constraints none that I can think of now

Track name

BobKing

The XP Mailing list was talking with Grady Booch about architecture, but floundered around defining "architecture" for a long time.

One definition of "architecture" was "the expensive design decisions", which led to characterizing XP as trying to delay making expensive decisions [do the simplest thing that works, until something more complicated is necessary], and characterizing RUP as trying to make expensive decisions early, after some analysis.

The last time I met someone with "architect" in his job title, I asked him to describe what he does. Essentially his job is Project Champion, getting support from the rest of the company for the project, and doing some amounts of prototyping, proof of concept coding, and production coding.

I'v heard of a few companies that are doing large projects with multiple XP teams. They haven't yet reported on their success or failures, but their organizing principle is that each project that depends on another has one of its team members as the Customer of that other project.

There's also one very large XP project that's been going on for about 2 years now, with more than 30 programmers, 5 or 10 business analysts, and maybe 10 or 20 testers. I'll try to look up recent reports on this project on the web later...

As for "limits of communication", I think that pair programming actually permits larger teams than 8 to work well, because a pair can hold more knowledge about the project in their collective head than a single person can.

I and other people have also seen that pair programming lets someone new to a project start contributing very quickly, to the point of allowing "drop-in programming" -- someone who contributes to a project for only one pair programming session. This "drop-in" effect was noticed at a open-team 'educational' project of BayXP called Project Bootstrap. Of course, one of the pair needs have experience in the project to keep the other from wasting time floundering around.

On the other hand, if you aren't communicating a lot and doing lots of pair programming, even a team of three can have problems with unfinished refactorings, unfinished code changes, and so on.

--KeithRay 2002.05.03

--KeithRay 2002.05.08

maybe that is it: (software) architecture is practice makes better BobKing

But this should not be surprising, as it exactly parallels the situation in BuildingArchitecture. There, though, they have examples that people can see, and point to and say things like "that's good architecture, but that's bad architecture." And then they can fight about examples, which puts them way ahead of the software field, where the discussion takes place somewhere in outer space, in a galaxy far, far away. - JerryWeinberg 2002.05.10

For instance, I expect most new large systems could use architecting, certainly to the point of partitioning it so that individual teams can work on it. I think it is often advisable to have someone with a technical background whose job it is to understand exactly what the customer wants and makes sure the system is structures so they get it.

I don?t see where the architect is the one who supervises or sequences construction. This is not the case in building construction. The architect?s supervisory role during construction is to be sure the general objectives of the customer are being met. Architects have little involvement in how the building actually gets built.

Architects release a set of blueprints which are actually high level schematics of the overall building design. Often these blueprints are not complete, and everyone knows better than to assume that a building will be built exactly as the drawings specify. There is nothing in the drawings about what sections of the building should be pre-fabbed, how to share a crane amongst trades, when to turn a floor over from one trade to another, how to be sure material is on site and other trades are done when a crew shows up. It doesn?t even say how to lay out tile or wood or stone to achieve a desired artistic effect. These details are left to the skilled trades to work out.

So let?s hear it for someone who will be sure the customer?s desires are understood and a structure is sketched and partitioned amongst teams who can build it. Let?s hear it for someone whose job it is to be sure that the customer?s ideas are deeply understood by the development teams. (Of course, this should be done by ?walking around?, as building architects do, not by documentation.)

But an architect doesn?t sequence work. Or supervise construction. Or design tests. Or train users. In these areas, the architect metaphor has, I?m afraid, gone too far. People who do not understand what architects really do are extending the metaphor in the same way that the manufacturing metaphor and construction metaphor have been extended. And unfortunately, another good lesson gets lost<sum>.

Mary Poppendieck www.poppendieck.com

The context shifts. If I say Architect, what context does my listener assume? For example, I believe a system architect is different than a software architect. It is a difference of scope and concern. The former has an outward focus and the latter more inward.

I had a cousin who was a "home" architect and I had an acquaintance in NYC who designed very large buildings. The two had very different perspectives as to who their clients were and what and who mattered in the long run.

Maybe we can't agree on architecture because we keep ignoring the context we place around it?

We assume that because we are involved in building automation to support human systems that somehow we all have a common understanding. To make matters worse people can fall in love with their words and debates may be fought tooth and nail over subjective definitions.

Jerry noted that building architects can debate good and bad from examples. It would be interesting to define an aesthetic for software and automated systems. One of my favorite books that touches on this concept is called "The Elements of User Friendly Software Design" by Paul Heckel, 1984. Paul Heckel was one of the designers of Visicalc. The book is as close to an aesthetic analysis as I've seen - BeckyWinant 2002.05.15

To me this was a confirmation of the notion of "elegance" and "good design" as being a pervasive concept regardless of what you were designing.

-BeckyWinant 2002.05.17

This doesn't mean that people who architected such software were necessarily bad architects (though, since all of them were human beings, I expect that a lot were bad at it, most were reasonably competent, a few were very good and a handful stellar). I mostly mean it to reflect a current view of what makes software valuable - accomodating change is one of these value criteria.

By architecting in a very general sense (and not just software) I'd want to mean structuring with itention, breaking down the problem into bits which are shaped and positioned in relation to each other in such a way that goals are facilitated. Then putting the pieces back together. Analysis and synthesis. I find myself most effective doing that with software when I use the technical parts of ExtremeProgramming (which itself has an architecture, i.e. is the result of having broken the software development problem into bits and having put it back together with the pieces just so).

LaurentBossavit 2002.08.08

At the top of this page, Nynke had written "Spell casting skills". Now I really want to understand what she's talking about!

(Maybe I've been watching and reading too much Buffy The Vampire Slayer.)

KeithRay 2002.0808

I don't slay Vampires. Do you think I should? I tend to simply avoid Vampires in an attempt to protect my energy ...<BR> In my perception, any architecture provides spaces in which realities can be built. It seems to me that discussions on what architecture really is, or on where exact boundaries of components (must/should) lie, are not very helpful for effectively bringing the system to life. In fact, those discussions I can perceive as Vampires.

I am willing to discuss instances and qualities of architectures, and tactics, and spell casting (articulation, not necessarily verbal) issues. Words are not only words. They invoke stuff in people. Visions are mere spells cast on stakeholders for the future, for example:

--NynkeFokma 10-8-2002

Do we want a house that we have architected to be admired for its beauty, its elegance, its uniqueness, the effect it has on humans -the spells it casts? Can we allow ourselves to be so greedy as to also want it to be admired for the simple and reliable way it actually shelters, serves and protects people - helps solve problems?

I feel I am not extending, rather shrinking some responsibilities. <grin> In my home niche, embedded (real-time) systems, architects are often involved from (before) the start and remain involved until the system is in maintenance state in the field (and some more). Responsibilities include maintaining the integrity of the architecture and trading off pressures in both hard and software, particularly in that vague boundary between them, in what I call The Twilight Zone.

So, is the ability to increase the probabilty of use of the things that we architect an important skill for an architect to have?

Bob, thank you for the wonderful reframe. I think it depends on what system we design in/for what business model in/for what niche and on our personal preferences as well: Does this envisioned system need support from a meaningful architecture in its ("fast changing") environment? Where meaningful means more than just customer perceptions and requirements, and more than a "divide and conquer" structuring approach. I would like it to mean "trading off pressures with a focus on congruence to increase the probabilty of use of the system architected" (again, thanks for the words)

And for me personally, if that is not allowed or considered necessary for building a particular product, then by all mean(ing)s let another more interested architect do it, because these are not the type of systems I enjoy architecting!

--NynkeFokma , 12 augustus 2002

I don't slay Vampires. Do you think I should? I tend to simply avoid Vampires in an attempt to protect my energy

The creator of the movie / TV show wanted to show that the petite blond girl, who would be killed by the monster in other horror movies, can take care of herself, and save the world if necessary.

I think you can take care of yourself, and your world-saving seems to healthy enough -- Buffy has died twice so far... but her friends bring her back.

KeithRay 2002.08.12

Hhhhmmm. And she slays Vampires. Not friends ... Are you sure? --NynkeFokma 2002.08.13