I got several interesting comments to “Who needs an architect” (both here and on DZone). Some of them said I don’t get the architect “role”, some said I am looking at things from the code level and don’t see the forest for the trees, others said that this whole “agile” thing is crap (admittedly not in so many words). Another one talked about the construction architect as a metaphor for software architect etc.
I started writing this post as an elaborate answer to these comments but something was bothering me. Something about the comments sounded familiar , yep you’ve got it – I wrote similar things more than 5 years ago (if you’re interested in the parallels between the presentation to the comments see below). When I originally made this presentation I had about 15 years of experience in the software industry and 5 years as an Architect (by title and role) where I designed, led, reviewed, consulted and what not quite a few software projects (including some very large scale ones).
However the point of this post is not to say “been there, done that, got the t-shirt to prove it” – Rather I’d like to point out some of my observations today, i.e. 5 years and several projects later
- The construction architect metaphor is flawed – I guess all metaphors are flawed by definition but the construction in general and buildings in particular are quite far from software in the sense that software is soft and changing. The building metaphor serves well to demonstrate size and complexity will need different methods but software is not build it is written and it is abstract and it changes. It is very presumptuous to think you can capture the right architecture for a project on the onset. Unless the project is either simple enough, in which case it would probably benefit from an off-the-shelf architecture just the same. A or the project is a well-trodden path being the nth in a series of projects. In the other cases software architecture will have to change and evolve with the project (you can read a series of posts I am writing on just that). Buildings don’t do that. That number of changing requirements that software projects need to endure is on a class of its own
- Enterprise architects are not software architects – After many years with a lot of debates on what software architecture is seems that most definitions today are in the IEEE-1471 area. Considering this definition is about the structure of software and not the constellation of software within an enterprise and their alignment with the overall business it should be pretty obvious that enterprise architects design the enterprise rather than software. This is not to say that it isn’t an important job just that it requires some different skills (like deep understanding of the business itself and less, for example, technological depth). project/solution architects and product line architects (to an extent) are software architects
- Architectural decisions are manifested in code and how it structured. The architect should understand the different needs of the stakeholder and base her tradeoffs. A UML drawing as nice as it is is not an architectural decision until it is actually implemented in the system. I’ve seen a lot of system that had elaborated architecture documents which had very little resemblance to the actual architecture in the project as was manifested in the code. Architects that are far from the code are just playing with themselves
- Architects should strive to code. Whether or not an architect will write code should only depend on the number of architects vs. the size of the team. When there aren’t enough architects to go around an architect will usually won’t write too much. In any event, the architect should know how to code and up to date on the technologies involved. The architectural constraints posed by the technologies in use are real and the best way to understand them is to write code. Things that are suggested by the architect should be reasonably feasible if you can’t code chances are what you suggest will not meat this criterion. If you don’t actively code you’d get rusty – do the math.
- Algorithms are not developed they are researched. You don’t have a concrete plan for the development of an algorithm you have several candidate ideas or approaches – some of them will work some won’t. This is true even if you adapt an existing algorithm. Some agile practices aren’t a good fit for this kind of “development” (TDD that was mentioned in one comment is an example- though a lot of tests for regression purposes are almost a must). Algorithmic research does need to responde to change as things you expected would work may need other approaches. Also, like the rest of the software the algorithms should match the changing business needs e.g. in xsights we started with 3G video calls and small(ish) image databases and now we focus on identification via clients and large image databases -the chalenges are different. (It might be a good idea to do a post or two on architecture challenges in project with a lot of algorithmic components – let me know if this is interesting to you)
- Agile shines for new development – This isn’t an architectural point, but the issue was raised in one of the comments. When you start with a new system a lot of the requirements are flaky – and so, most likely, is your understanding of the domain. Having a development methodology that embrace change is a real boon (esp. in startups :) )
- Software architecture vs. building architecture (Gilbert comment <->slides 4-7 based on slides by Philippe Kruchten)
- Software architecture at different levels (Sadi, Arthus <-> slides 20-24)
- Software architecture vs. design (Jerome, Sadi, Arthur, Peter <->slide 17)
- Coding architects and agile (peter <-> few articles in DDJ see a discussion on InfoQ)
* illustration : Ziggy stardust album cover