Marc calls Bullshit on (perspectives on) SOA (service oriented architecture).
“in the end, it’s about delivering value to the customer, isn’t it?”
I’m having problems with the “Architecture” metaphor applied to software for exactly this reason – software architecture often detracts from delivering value to the customer.
I think it would be wise for those discussing “software architecture” to take a deeper look at architecture than the unthinking stereotype that results from “just using the metaphor”, thereby transforming the metaphor to a (perhaps useful) analogy. Writing this post is my attempt to deepen my own understanding a bit, maybe it will do the same for you 
So far, the use of “architecture” seems like a vain attempt of a young profession to borrow credibility from a much older profession. I believe it is time software development learns to stand on its own two feet.
The one thing I’m missing most in discussions and descriptions of “software architecture” is context and history. Building architecture has many “schools”. Each school puts emphasis on other values. An architect, or a team of architects can belong to one or more schools, at the same time, or over time. Or they develop their own style.
Building projects and architects are driven by many factors. For some it seems to be mainly aesthetics:
the piramide @ the Louvre
For others it may be research into new materials:
Eiffel Tower
For others it may be adapting to traditional buildings in the environment:
Shanghai
For some projects (e.g. hanging a photo on the wall) using an architect would be somewhat of an overkill. Using an interior designer might be a good idea in some cases, in the Netherlands they are called “binnenhuis architecten”, meaning “inside (house) architects”. For other projects, an architect is not enough, and an urban planner may be needed:
Scheveningen, the beach front of the Hague
Delft city centre and some of its edges
Other architects, in the vein of Christopher Alexander and Frank Lloyd Wright take a fractal view of architecture. They pay as much attention to why what lamp is hanging where (interior) as to how buildings fit in the (urban) landscape around it:
Monona Terrace Community and Convention Center parking lot overlooking Lake Monona in Madison, Wisconsin, designed by Frank Lloyd Wright
Inside of the convention center, also designed by Frank Lloyd Wright
I used to like the “architect also implements” pattern. Johanna Rothman’s Architects Must Write Code seems to be a more prescriptive variant of the pattern – I’m missing the contexts in which it applies, and contexts in which it doesn’t. Reading Architect as Consultant? it seems Johanna believes architects who don’t program on “the project” can’t work. In Rotterdam we used to say “Kan niet bestaat niet” (‘Can not ‘ exists not). Rotterdam was re-built from scratch, after the city-centre and more was destroyed in a blazing fire, resulting from a bombing in the second worldwar.
If you’re building just a house, “architect also implements” might be feasible, or maybe it is the master builder that also designs. If you’re re-building a city, having the urban planner run around with a hammer and a box of nails would be seen as micro-managemement.
To me the main question is: how does the “architect” know the influence she has on the project, and how does she receive and learn from the feedback about the thing as it is (being) built? For a small project, actually participating in the implementation may be a good idea. I like to pair program with others, and collaboratively develop the (technical) architecture. For a larger project, being present at stand-ups, temperature readings and retrospectives may be a good idea.
We shouldn’t forget that building software is not only about technology. A good “architect” also takes into account the landscape around the software and the people living in it. Diving deep into software development may make one focus on the hammer and nails, and forget about the landscape.
I’m currently involved in an architectural project for a Really Large Corporation that is more comparable in scale to “urban planning”. The role of me and my colleagues is more that of city planners, determining which buildings fit where, and where buildings have to be demolished to make place for highways (I’m consulting on fits and misfits of existing software, software under construction, and assessing the way(s) in which they are constructed and hosted by vendors, internal suppliers and customers).
Actually implementing things, and having done that in the past gives me a perspective that makes it easier to call “Bullshit” on this project. For instance, when SOA related performance issues come up, I can use my experience on implementing a similar system to provide a perspective.
“Implementing” for this particular project wouldn’t make sense to me; I would lose the perspective I need to participate in “urban planning” of multiple (software and organisational) systems.
To me, developing software is about providing value to the customer now and in the future. I prefer to think of “software architecture” as a fractal, taking into acount which types of events have to happen here, placing a lamp if appropriate, and at other times looking at how the buildings fit in the landscape; if and how “architecture” and “architects” provide value depends heavily on the context.
Ever since reading 
.
Recent Comments