Arnon Rotem-Gal-Oz is the director of technology research for Amdocs. Arnon has more than 20 years of experience developing, managing and architecting large distributed systems using varied platforms and technologies. Arnon is the author of SOA Patterns from Manning publications. Arnon is a DZone MVB and is not an employee of DZone and has posted 68 posts at DZone. You can read more from them at their website. View Full User Profile

Who needs an architect anyway?

06.03.2010
| 11657 views |
  • submit to reddit

Not all projects need architects. There, I’ve said it. Not all projects need architects and I am not talking here just about trivial projects. There are cases (maybe even many cases) where you can get by with what I call “off-the-shelf” architecture – maybe with a few adjustments that any master developer (i.e. seasoned and experienced developer) can handle. For instance a lot of web-sites can do pretty well by using Model-View-Controller (or a derivative of that) along with a simple O/R mapper such as active-record. In fact a lot of them do just that,  when they use a framework like Rails that made these architectural choices for them*. Another example is the vanilla 3-tier architecture provided by software vendors (such as this one by Microsoft). Yes, when you take something off-the-shelf, the result might not be optimal but that doesn’t mean it isn’t sufficient. You just have to be aware for the tradeoffs…

Another point is that “design” is not some exclusive architect thing. A developer is not a good developer unless she also known about  proper design. For that matter  ”mastery” of just the  technical aspects of a language without understanding the wider context of design will just help you code a lot of crap faster. So, again , a good developer knows a thing or two about design and can handle trade offs and variations on a project architecture (especially in cases described above).

This means  we need to consider a few issues – When (if at all?) do you need architects? What do they Do? What’s their relation and interaction with the developers ?

When do you need architects?

It isn’t always an obvious choice between a project that can get by with an “off-the-shelf” architecture and one that needs an architect. It would be nice if we could have something like a litmus test that would tell us if architects are needed or not. I don’t have one. The closest thing to a litmus test I have is something I call the SCLR test (pronounced scaler). SCLR stands for Size, Complexity & Limited  Resources.

  • Size – well if you are going to have something  estimated at 1000 man-years or dozens of teams. I think it is pretty obvious that you can’t just use something  which isn’t made to fit. If anything there’s a need to divide the work between the teams in a way that would make sense so that you wouldn’t get a big-ball of mud. There’s also a lot of need to coordinate the efforts and keep the big-picture inline. Personally I think that it doesn’t  have to be a huge project to warrent some architects involvement. Since as Fred Brooks notes the number of interactions grows exponentially as we add more people.  In my experience trouble starts even with more modest numbers – more than 4 or even 3 different teams working concurrently is probably a good number to start thinking  about architects
  • Complexity – There are many signs for complexity in a project. The vision statement can provide a hint. “Let’s design the software to support the next mars mission”, “best CRM platform ever”  – an ambitions project will not make-do with “average” architecture. Size (which  I already mentioned) is also a sign of complexity, while previously I talked about size of the project, the size of data,number of concurrent users etc. is also relevant when we’re thinking about complexity . A lot of external interfaces is another sign. Integration doesn’t seem very complicated, until you actually try to pull it off. When you have to do a lot of that in a project that’s complex. And there are many other such signs
  • Limited Resources – Naturally every project has limited resources, but limited resources should be considered as a sign for architect involvement if the resources are extreme. When resources are extremely limited the tradeoffs that have to be done are more meaningful, which is why wed want people who can help with that (i.e. architects). For instance in a projects I worked on in the past we had a lot of availability and performance requirements on one hand but only so many “U”s in the rack and even limited electricity to make all this magic happen. This turned something which otherwise was a relatively standard IT project into something a lot more challenging.


Let’s assume I convinced you that some projects need architects. Convinced, you go and hire one. now what?

What do architects do?

Let’s start by looking at  “architectural decisions” – which is sure sounds like something we’d want an architect to do. I read once (I think that was Martin Fowler) that an architectural decision is a decision that in hindsiight you wished you made right. if we look at a formal definition of software architecture (say from IEEE 1471) we see that the architecture embodies the fundamental decisions about the system its components, their relations and their properties. Using this definition an architectural decision is a fundamental decision about the system (which pretty much explain why we want to make them right etc.)

Well, here are two observations on what I’ve said thus far. One is that we would want to postpone architectural decision as much as we can, since changing them will cause us a lot of headache. The problem is that in order to postpone an architectural decision we need to build flexibility into the system which is an architectural quality in itself – which might not be the top of the list if we prioritize it vs. other architectural qualities we need.

The second observation is that if we “refactor” the pretty language out from both of these definition – we can see that an architectural decision is basically a guess, hopefully that’s an educated guess but it is a guess none-the-less. and as Albert Einstein once said it is  hard to make  predictions – especially about the future.

This is why architects  breadth of knowledge – which helps explain the architect training program I posted about a few weeks ago (see Architect training program Part I and Architect training program Part II). Another aspect is experience. And to get a wider perspective it can be helpful if this experience includes other roles besides developer such as project manager or business analyst etc. Another important component is domain knowledge and understanding of the business.

Using all these you (as an architect) may come up with a reasonable architectural decision (e.g. use MVC pattern) and a design to match it and that’s it.

Well, actually, not quite since as I said earlier it is still a guess. Remember  an architectural decision (and any design for that matter) is a mirage no matter how beautiful the power point slide looks (or white board or UML sketch etc.)

Alas, power point compilers are still in the making. Which means that as an architect, you must be able to prove your point in writing – that is coding. While you are at it, you also need to know a thing or two about the technology you are using because it too has an architecture, features etc. which may (and usually do) have a significant effect on the end result. (You can read a little bit more on this in the “Architecture Deployment” paper I published a while ago).

The result of trying to postpone architectural decisions coupled with ever changing requirements and with adding details as we unfold the  architectural abstraction level to a working system, is that the architect can’t just appear at the inception of a project and disappear afterwards – they need to stick around for the game. This is especially true if you want to have an evolving architecture.

The architect’s role goes beyond making architectural decisions. In effect the role shares some of the CTO roles -though on a smaller scale i.e. withing projects rather than companies making the architect the project CTO

Tom Berray has an excellent paper describing 4 models for the role of a CTO. 3 of them can be applied to software architects (within their projects)

  • “Big Thinker” – This is somewhat akin to the role discussed in the previous post.
  • “External Facing Technologiest” – I usually saw this in larger projects, but it is also applicable for smaller ones. There are many occasions where the technical capabilities of the project have to be presented and/or negotiated with external stakeholders. Architects are in a good position to perform this as they should have good understanding of both the business and the technology. Additionally making architectural decisions already requires the architect to understand the different stakeholders’ needs


The third model is called “Technology Visionary and Operations Manager” – Making sure that technology works to deliver business goals – but how is that done?

In their book on organizational patterns, Jim Coplien and Neil Harrison, talk about the “Quattro Pro for Windows” (QPW) development team. According to the case study, Borland had a team of 4 architects who worked together to produce what the authors call prototypes*. 6 month later these architects were joined by additional developers to produce the product. During the development the architects kept meeting on a daily basis to coordinate their efforts (sort of like a daily stand-up in a scrum of scrums).

The situation in the QPW is probably close to the ideal architect involvement in a project – coding architects that work closely with the team, while driving technical and architectural decisions. The availability of multiple architects (but not too many – to prevent the “design by committee” effect) also enhances the overall quality of the solution.

Another aspect of the architect work is to act as a coach/mentor. It isn’t enough for the architect to “know best”. We already know that architect must also be able to reason about their recommendations/decisions, but that’s just part of the story. Helping other team members get better in what they do means that they’d be able to do their job better, they’d be able to come up with their own ideas (and get more fresh ideas into the discussions) and produce better software. Since the architect is ultimately responsible  for the quality of the solution, making others perform better should be a top priority for the architect. Being considered as a source of knowledge will help an architect perform his/her role, even when they don’t have an architect title

[This post is an edited version of several posts I wrote in 2007 and are (IMHO) worth reprinting]

* Rails has more than just MVC and Active-Record but that isn’t an important point for this discussion
** In this post “Architect” means someone doing software architecture work (role) and not necessarily someone with the job title “architect”
*** Illustration taken from Matrix Reloaded
References
Published at DZone with permission of Arnon Rotem-gal-oz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Artur Karazniewicz replied on Thu, 2010/06/03 - 11:27am

Arnon

 I kinda disagree. Every (software) project has an architecture regardless it's documented, or done by a guy with "Architect" on his/her visit card. Usually there is someone, be it lead developer, senior programmer, leader or someone else who drives the shape of software solution. Who leads all the others, who takes decisions, who facilitates evolution of the project. He or She carries Architect role, regardless what the real role she has within a team. "Architect" could perfectly be the role, not necessary a position (on the opposite side, I have seen projects where this role was filled by few persons, few Architects with different focus). Simply Architect it's guy who has "Big Picture".

Architecture is all about Big Picture; on all levels (whatever it's single system (System Architect), or bigger Solution (Solution Architect) or even whole Enterprise (Enterprise Architect)). The "Big Picture" is the key. And here goes the answer when (or if) one needs an (named) Architect. It all comes down to Big Picture. And usually do You need someone who has Big Picture view. Even in the case of COTS (how this COTS application would add competitive advantage for You? How it will be absorbed into You environment, how it will be integrated? etc. etc.).

 Also what I can see. You focus way too much on wrong side of the problem. In my opinion You are too way technical here. What You're talking here is much more design (or low level design) You're talking about. And not architecture (architecture is kind of design, but not other way around: design is not always part of Architecture). OK it's important whether You use this ORM, or other, or MVC, or something else. But, frankly it's rather trivial decision. One time shot, not much to think about. It's what I call "Framework Oriented Architecture". What is really interesting from the architectural point of view is: how given (System, Solution, Enterprise, whatever) fulfils functional and non functional requirements; and You as an Architect responsibility is to fill those requirements in the most effective way (and usually this kind of decisions are not about given framework, unless Your aim is to build the framework). Here is where Architecture shines.

regards
http://blog.restfusion.com
Artur Karazniewicz

Sadi Melbouci replied on Fri, 2010/06/04 - 11:17am

I think you got the ROLE of an architect completely WRONG.

What happens when you have 1200 large projects and you want to make sure that all these 1200 applications are intergated. Well, let me give you a clue:

1- You must design at the Enterprise Level (Enterprise Architect)

2- You must design at the domain Level (Solution Architect)

3-  You must design at the Application Level (Application Architect).

 Someone has to make decisions at every level of the enterprise. 

 From reading your post, I can tell that you are looking into a room from the key hole and you only see the code and you may not care how that code fits into the enterprise.

IT is here to make organaizations perform better. Every organization must align IT to Business needs and that's where the Architects comes in.

 

 

Fab Mars replied on Sat, 2010/06/05 - 5:31am

...and here we go again on the architect(ure) topic. I was so glad it was gone for a while.

Jerome ROBERT replied on Sat, 2010/06/05 - 5:59am

As far as I'm concerned (and as an Architect), I think it's true that projects don't need Entreprise nor Solution or Application Architect either (to get an architecture). In one case your project will have a designed architecture choosen by the responsible architect according to the information system needs and in the other case it'll be a grown up architecture where design decisions were taken by individual on a day to day basis depending on their own needs at a given time. It does not mean that those discrete decisions are bad or unconsidered but they certainly are harmful to information system homogeneity. If managing your system as an homogenous whole is not important to you then you propably don't need an architect, but if you think (as I) that nowadays organisation can't afford anymore not to have a global strategy a good architect is a must-have. J.

Gilbert Herschberger replied on Sat, 2010/06/05 - 11:02am

The words architect and architecture come from the construction industry. Architecture is fundamental. It is not possible to construct a house without some kind of architecture. But what about an architect?

In 1970, my own father build a house without "hiring" an architect. How did he do it? He purchased the plans for a house from a mail order catalog. He bought a piece of land, got a permit and worked on it each week end for two years. It turned out okay.

Did he hire an architect? He hired an architect indirectly. An architect drew up the plans. But, an architect was not involved in the design of our specific house.

Likewise, it is not possible to build software without some kind of architecture. But what about an architect? Yes, you can construct an application, a system, an infrastructure without hiring an architect directly. You get architectural designs for your software in many ways, such as from a book, a tool, or another project. It is called Do It Yourself (DIY) architecture.

The question becomes, When should I hire an architect? You ought to hire an architect when existing architecture has failed. An architect can fix a broken software strategy. Hire an architect when pushing the envelope. An architect can prove that the foundation of your software is sound. And when switching architectures, from one that you know well to one that you don't, an architect can ease the transition.

Caution: Choosing the wrong architecture always leads to failure. By definition, architecture is a big decision. It is the biggest decision. Who do you trust to make big decisions? You can choose to become your own architect or hire one. It reminds me of an old saying, "One who represents himself in court has a fool for a lawyer."

Salvaging failed projects--that's my day job. In the face of total failure, bad architectural decisions should not remain unchallenged. Learn to question a bad decision even if it was made on day one. By the time someone hires me, a project is months behind and frustrated developers can't seem to fix anything. If your team is desparately trying to get the architecture to work at all, you may need an architect.

Senthil Balakrishnan replied on Sun, 2010/06/06 - 3:13pm

Well said "Gilbert", nice analogy...

Sen

Arnon Rotem-gal-oz replied on Wed, 2010/06/09 - 1:38pm

All - You can see my reply to your comments on my blog Arnon

Michael Eric replied on Wed, 2012/09/26 - 3:45pm

I've always thought the who point of agile was to implement something for which the architecture is well understood. If you're building a three-tier web-shop, then a metaphor, senior dev, and iterations should be more than enough. You don't need an architect on the payroll. On the other hand, if you're building something novel, or which has strong dependancies across the enterprise, then you might want an architect to steer the boat."Coding architect" makes no sense to me as the two jobs are different enough that you can't do both at once and still do either justice. Let's just admit that they're senior devs and get over this strange instance of labelling anyone senior in development as some type of architect.

debian 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.