Category Archives: architecture

Where Do (Software) Architects Come From?

Where do software architects come from? There is a simple, obvious answer, but that is not what I mean 🙂 I am referring to company environments. I can’t help noticing that more often than not, architects come from one of the following sources:

  • Architect by appointment” (not skills). Somebody got promoted to be the architect (implying the role carries a higher value than that of a programmer), or somebody got simply pointed out
  • Not-so-great programmers who are thought to be good enough for “drawing boxes and lines on an abstract level”
  • Programmers who are so far removed from the trade they don’t have the insight any more what their options are, and what impact their decisions have
  • Non-programmers who, well, can’t code and therefore must do something that does not require coding

That is weird, assuming you choose your architect to help, improve, complement the implementation project on a level that is different from that of a programmer.

But maybe those who choose architects don’t know what to expect and what to look for. There is evidence for that: companies often don’t educate their people to be architects, or even have an expectation (that they communicate).

I can only offer my own standpoint: An architect is a person dedicated to looking at and being responsible for the quality aspects of a software project.

What kind of qualities? I would stretch that pretty far: Can the structure of the system be easily understood? Does it fit the purpose of the project? Does it address the problem and the constraints of the environment in a fitting way? Does it reduce the impact of changes to the requirements or infrastructure on the system?

While programmers must address quality issues, too, they are primarily occupied by translating functional specifications into technical reality (which is why code generation will not happen before arbitrary natural language can be understood by a computer), and wrestling with the intricacies of highly complex APIs, other people’s code, and their own.

The architect in my opinion must be a seasoned senior developer who knows what works, knows what doesn’t, and understands and can explain why that is so. S/he, too, has the (urgently) necessary people skills to promote good architecture, to convince management that additional effort will pay off, and to convince programmers that the marching direction is the right one.

You can’t study to be a “software architect”, though there are certifications. There are some great books that for sure can help. I believe a certain attitude to programming, long experience in many various projects, being awake at the IDE, and musing about why things went the way they did are a good base.

Musings on MDA

The noise about MDA generally has died down, and I think that has to do with expectations having met reality. MDA can do really good things, when expectations are set right. If not, disappointment is pretty much guaranteed.

In example, I was overseeing a diploma thesis about transforming EJB 2.x persistence into EJB 3.x persistence. This worked very well because the input data was already modeled in a machine-readable form (in example, EJB 2.x-style XML descriptors), that is, the human part of the work was largely done.

Regarding MDA often promises are made – especially by vendors of MDA products – that inevitably create disappointment because improvements by an order of magnitude rarely materialize, for various reasons inherent to the way software development works.

First off, “coding” (I hate this term) is only a small part of the whole process of creating software. Even if you could reduce code production effort to 10% of the conventional approach: if code production is 20% of the overall cost, you achieved an overall reduction of 8% (which still is not bad, but not as spectacular as 90%).

Secondly, all automatic approaches require that some human already did the thinking part. You’ll never get a class model generated from requirements written in prose (but you can create the DB from a class model), and you’ll never get code generated from the informal description of an algorithm (but you can create method stubs and calls from a sequence diagram).

One (big) problem that keeps me at a distance from MDA approaches so far is that round trip engineering often works rather poorly. If you always generate foward there is no problem; if you need changes in the generated code reflected back into the model (refactoring comes to mind; try that with your MDA tool), you’re often out of luck.

Breaking Up Architecture and Development

From practical experience, the emphasis in “breaking up architecture and development” is on “breaking” – it does not work.

A customer I have been working for decided to split software development across two different organizational branches: project management, specification, and architecture on one side and software development and testing on the other. The transition to this organizational structure was made in a “jump into cold water” fashion.

The idea was that the high level and therefore expensive work would be done in Germany and the low level cheap work would be offshored to a “development factory” (“industrialization” was another frequently heard term, but that is another story).

This did not pan out as planned, for a number of obvious and maybe not so obvious reasons:

  • Architects in that company often are programmers that are either totally out of touch with current developments, or clearly less than decent programmers, or aren’t even programmers at all. IMNSHO an architect must have years of programming experience and must be a really good programmer with clear ideas on what kind of programming style promotes high software quality.
  • Estimates where done independently by the architecture and the development team. Since both teams had different ideas about how the software would be designed and because these ideas never got synchronized the overall estimate often was the total of planned work for substantially different approaches.
  • The architects had no real influence on the programmers. If concepts were not liked the development team simply priced them out of range (“if we do it like this (solution that we don’t like), it will cost 30% more”). Project management did not have the necessary insight to call shenanigans or to understand and act on long term consequences.
  • When architects and programmers are separate persons a huge amount of information must be transferred in the form of papers, talks, and meetings. It is much more natural and efficient to let the senior developers, possibly with some guidance, develop the architecture, and then let them move on to programming as the project continues.
  • Developers in India are not just “coders”, if that management idea of “low level programmers” would exist. They can and want to do architectural work, too. Intelligent programmers will resist to micro-management on the code level.
  • The separation felt and worked like contracting development out to an external, untouchable company. Estimates had to be accepted like carved in stone; risk surcharges, profit margins, and baseline costs where added, and there was no direct talk to the programmers. Code reviews weren’t even on the agenda.
  • And – the whole thing just does not work out financially. The plan was to specify everything down to a pretty low level and then let the cheap “code drones” take over. The problem: You spend 50% of the time or more on expensive experts working out a detailed specification and then try to get your money back by executing the last 50% or less with cheap labor. And then you find that instead of ten programmers you need fourteen plus two group supervisors plus one off-site manager to get the same job done, and your customer is not willing to deal with documents written in English. So much for comparing hourly rates by dividing one through the other and drawing the wrong conclusions.

As you might have guessed, the split between architecture and development has been reversed after a year of pain and suffering, and surely a lot of money and enthusiasm lost.