Next week, I’m interviewing another architect, so I’ve gone over my list of “things to ask an architect candidate” for another time to see if I’d change anything. Not much popped out, but I thought I’d share some exercises that I ask architecture candidates to run through.
Note: I care more about experience than book learning, but I care very much that you know the actual names for things. In other words, book learning does matter. If you never got around to reading any of those ‘patterns’ books, don’t bother to show up. You wouldn’t be considered a qualified medical intern if you referred to the Biceps Brachii as the ‘upper arm muscle’ and I won’t consider you an architect if you can’t tell that I’m using a Strategy pattern in my case study.
The things that a systems architect must do to survive an interview with me:
- Demonstrate the ability to work on a project team with developers productively
- Describe a time when you created a vision for a systems architecture, communicate it, and others made it come into existence
- Tell me how you know when it is time to review code for compliance and when you are better off getting out of a developer’s hair
- Be able to guide and direct the team in the art and science of visual modeling (it’s not enough to know… you must also teach).
- Detect the gaps in the early design artifacts of a project and determine what risks are going unmanaged.
- Be able to convince me that you understand, in your bones, the concepts of coupling, abstraction, and encapsulation.
- Be able to describe at least five GoF patterns in fine detail. Be able to describe at least five messaging patterns in fine detail.
- Pick a single system quality attribute that should be paramount in a particular situation, and then explain why.
Some exercises to run folks through:
A. James is an IT architect working with a team of 5 developers and 5 testers on a new system. He has a situation with his development team. He presented the high-level design for their new system at a dev meeting and the team listened politely. Then, after reviewing his diagrams, some of the members of the dev team concluded that he has created a great deal of complexity in one area that they think is overkill. James hears about it from the project manager three days later. He feels pretty strongly that the complexity is called for. Evaluate the situation. What dynamics are at play? James comes to you for advice: what do you tell him?
B. Let’s say that you have 10 systems in an infrastructure. One of them provides the list of all customers, while another provides the list of all orders. You want to keep the systems as decoupled as possible but they need to share data in real time. What mechanisms do you put in place to keep the systems independent, yet fully integrated? Describe the steps you would follow to replace the system that holds orders.
C. Draw the architecture of one of your most complex systems on the white board. Now:
- What made you partition the system in this way?
- What data entities are mastered by your system? Which components are responsible for actually writing the key data about each entity?
- What changes do you predict the business will want in the next 2-5 years in this system? How will the architecture cope with those changes?
- What system quality attributes did you consider most paramount when designing this system? What attributes did you sacrifice?
D. The architectural council has invited you to join. They perform periodic reviews on major projects. You attend and a project comes before the council that has not been reviewed before. It is a medium-sized project for your company (your company will perform between three and six projects of this size each year on average). It consumes data from other systems in real time, creates transactions in other systems, and produces data for reporting. The following artifacts are provided. What additional information do you ask for? What risks are you concerned about?
- Logical Data Model showing every data entity in the system’s database
- Deployment Diagram
- Class-level architectural diagram illustrating the use of design patterns
E. You review the code of a junior developer, and you see a call where the developer is passing a structure. The structure contains 25 different values as parameters to the method being called. The structure is used only to pass parameters to this one method call. You ask why the call needs so many parameters, and it turns out that it is used in about eight different places in the code, and each one has a slightly different need, so the routine will look to see what parameters are passed to decide what to do. The code for the method is complex, and contains many examples of code like this:
if (paramx != null)
do_something_specific(paramx);
What patterns do you discuss with your junior developer? What options do you consider? Do you advise the developer to change the code? Why?
F. Pick one of the following practice areas and describe the ideas and concerns that led to this area of software development practice, what the practice entails, the benefits that can be achieved, and the negative consequences that may be observed by teams engaged in the practice. Note: I may pick one for you… be prepared to be asked about any of them. (If you were to ask: “why this particular list?” I’d turn that around and ask you why I picked this list… )
- Service Oriented Architecture
- Test Driven Development
- Aspect Oriented Programming
- Dependency Injection / Inversion of Control
- Software Factories
G. Mary is a fellow architect with a problem and she has come to you for advice. She is producing an impact analysis on a system we will call “Charlie”. The Charlie system gets an hourly feed of data from another system called “Bravo.” The Bravo system is scheduled to be replaced by an altogether new system called “Romeo” that will organize the data in a completely different way. Unfortunately, this will radically affect the data feed from Bravo to Charlie. Not only will it vanish, but any feed from Romeo will be structured and organized in a completely different manner than it was before. Mary needs to develop a roadmap to allow this change to occur. What advice do you give her?
Great post and scenarios, but I do have one question: you plan on covering all of this in an hour or two? I’d think it would take the better part of a day.
Good point. No. I don’t use all of these. I chat for a half hour, and then spring one of them. The stuff I find out in the chat helps me to decide which one. If I have a 90 minute interview, I’d use two or three. Never all at once. That would be unfair.
I’m not there yet, but I’m much closer than I thought.
Scenario A, looks to be a case of "no sales skills". James should have been able to get that feedback from the developers, and he should have gotten buy-in from the team before he left the room.
Scenario B is currently causing me to punt with the phrase, "use web services".
Scenario C would have me describing my EDI parsing system that I put together in Bermuda.
Scenario D, I have to take a "no-pass" on it. But I would kind of like to see something in the realm of Fitness, or some other kind of system testing suite in order to capture "requirements" in living code. I’d also like to see business cases with ROI’s for each project.
Scenario E has be scratching my head. My first gut reaction is, "Get that sucker under test, and then refactor it to constituent parts". If there is an obvious anti-pattern here, I don’t see it.
F is a fun one.
1) I can stumble through SOA, but I couldn’t succinctly answer the "what problem does it solve".
2) TDD, No problem, I can go on for hours
3) AOP is still a deep mystery to me.
4) You’ve seen me teach this class.
5) Factories, I can give some good generalities, maybe talk about bridge patterns, but mostly still it’s a "I can’t teach it"
G) Charlie, Bravo, Romeo.
I’m thinking "put an access layer over the top of Charlie." When Romeo comes into play, put an access layer around it that knows how to talk with Charlie’s access layer. I may be adding an extra layer here that’s not needed, but that feels more right for a phased integration, and I’m thinking that making the access layer to Charlie is going to raise some issues that wouldn’t be obvious, but would still be critical. The effect of that would be to lower your risk. Most of my thoughts for this one are coming from my experiences working on that interesting system with you and later with Shawn.
Hi Malcolm,
Keep working on it, my friend. You will get there. I’m convinced of it.
— Nick
I think I see a weakness in the scope of the questions. Using your analogy, anyone with a fair amount of intelligence can become a medical intern by a combination of sheer will and persistence, coupled with an ability to memorize a lot of facts. It is important to note that in any profession, statistically, half of those who practice it will be below average (via the bell curve). What distinguishes those in the top half of the curve is a combination of 2 things: 1. A genuine love of the game that they play, and 2. A clear understanding of the basic underlying principles at play.
Number 1 generally leads to Number 2, but there are people who are naturally gifted for certain professions, and if they are disciplined, they will excel at them (and most likely have a genuine love for them). What I think is missing here is a set of questions or perhaps tests that identifies these gifts in the individual candidate.
Among these are both positive and negative characteristics. For example, on the negative side, a job with Microsoft is going to be highly lucrative. Establishing the motive for wanting the job would be helpful in weeding out those whose motive is purely financial.
On the positive side, with regards to architecture, the ability to think visually about ideas would definitely be a plus. It is not the skill with which one yields the visual modelling tools, but the instinct for recognizing visual patterns in design structures which matters most.
A natural tendancy for analytical thought would also be an incredible plus on the part of a candidate. The native ability, or even perhaps compulsion, to break problems down into smaller chunks recursively is the essence of architecture.
There is also a tendancy on the part of great architects to look at problems and ideas from differing points of view, because a problem often takes on a different appearance when viewed in a different way, revealing different aspects and potentials.
Finally, the ability to think outside the box is important, as architecture in any field is a creative endeavor. Innovation is not achieved by followers, but by trail-blazers.
So, what I’m ultimately getting at is that it seems the questions and problems presented here tend to be a bit too slanted towards technical knowledge, an understanding of facts and syntax, and perhaps a bit lacking in the area of recognition of personality traits and natural gifts. One can teach the technical aspects of software architecture to anyone willing to learn; to find the best candidate for such an education seems to me a more worthwhile endeavor.
Hi UC,
Great response. Strong compliment to my blog post.
I agree with your assertions. One clarification: I have no problem looking for the people who love architecture… but you seem to imply that if the love is there, I should take a less skilled person and let them ‘mature’ in the job.
I want them to have achieved the level of knowledge and skill required to do this job before they start. I have little time or patience for OJT in a position as key as this. Mistakes cost LOTS of money.
In addition, Microsoft IT has something like 2000 ambitious professional software developers (I’m guessing, but the number seems right). If I put an unqualified person in a rare and coveted job, the response would not be warm.
Hi Nick,
Let me clarify myself somewhat. I was talking only in terms of degree and balance. In fact, any aspect of this business involves continuing education, and there should most certainly be a base level of technical expertise in order to get one’s foot in the door. In other words, I agree with the technical/skill standards you enumerated. However, those standards are only part of the equation; the more difficult standards to measure (as I discussed) are often overlooked, and more important over the long haul. That is why I used the phrase "tend to be a bit" – as a way of emphasizing a balance rather than a contradiction.
I am a frequent reader of the Inside Architecture Blog . Yesterday, Nick Malik posted a good read that
I’m a a Systems Architect at an insurance company, I quite honestly can’t answer the pattern questions in detail – I know them and can point you to multiple references, but my daily grind is not really in the realm of code development, but in strategies and approaches to systems – At Microsoft, I would believe that you desire very strong programmers who can define technical systems, and that’s where these questions come from.
My odd insight on this, I have degrees in Architecture (the building type) and Civil Engineering. I think that in software we have tried to enjoin architecture and engineering into a single "Systems Architect" term. In architecture school you are trained to dream unrealistic dreams and understand the reasons why you developed that solution – yes, you cover the technical implications, but that is not the reason you go to school. We also learned how important it is to evaluate the building site and let the site inform your decisions – i.e., buying a house plan out of a book does make the house fit into the neighborhood or work if the house has to be built on a hill. In engineering school we quantified and broke down complex systems to their smallest parts and then iterated and applied safety factors to ensure that the solution proposed would meet the requirements that we understood. In both cases, process was key.
My point is that Systems Architecture can be both art and science. Sometimes you may need to hire an artist, sometimes you just need a scientist, and sometimes you need both – each have their strengths and weaknesses. There’s a time and place for each type of architect and you’ll just have to decide what is needed for your team.
Hi Steve,
Very well put. I have no doubt that you are a fine Architect. I can be a bit of a PITA sometimes about the ability to ‘speak patterns’ but it is somewhat from the POV that an Architect among eagles must be at least as skilled as the most annoying expert developer in the room. We have a lot of experts. Some are annoying. So that pushes the bar fairly high. That said, there is nothing in the world like working with a team that is so amazingly talented, passionate, and dedicated to excellence.
As for the comparison to building architecture, you are far more educated than I on the topic. That said, I believe that both fields share that boundary between the "what we must" and "what we want." To be truly great at either, you have to be something of a dreamer who recognizes the need for reality but dreams anyway.
There are similar processes defined for Systems Architecture as those you describe, although I can venture certainty that the software analog is far less refined and mature when compared to building architecture. I’m speaking of the work done at the Software Engineering Institute, especially the ATAM method and its kin in industry.
In the end, the Architect is more than just a strategist. They must be that, in spades, but they must also be a leader, in thought and in action, willing to stand up and drive for excellence when the daily grind of development and support weighs the project toward the inelegant and the short-sighted.
Architecture and Design has always been very interesting for me. For an architect I think its important to understand the different scenarios while you work out the technical requirements part of the system. One has to understand the bridge between the functional and technical requirements. Architects have to understand programming, then again its important for an architect to understand cross platform or platform independent semantics as well. I agree with UC that its important for an architect to think visually, again be able to map that bridge from functional aspects of the system to the technical details. Having the ability to work productively with the programmers is good but be able to work with analysts and visually define the system before you get with the programmers is also important.
I am working on a new concept (if I may call it that) of Software Architecture. Its titled "Organic Programming as an implementation of Behavioral Software Architecture". Its combines intelligent software units to the status, messaging and application behavior aspects. This helps in communication between units. The basic concept is that each unit we design has the ability to intelligently survive on its own and be able to manage its functions without external help but for a stable system it needs the ability to work with other units, that is where status, messaging and behavior comes in. Its still in development but I can post details of my paper if some one is interested.
Hello Moiz Ahmed,
When your paper is ready, drop me a note through this blog. I’ll link to it and give my honest opinion.
From what you describe, your idea sounds very interesting… In a way, the system is less of an organism and more of a hive or community.
I like it.
— Nick
Hi Nick,
You are correct, community or hive would be defined by the combination of organisms or the smallest unit of the application in software architectural terms.
In organic programming they refer to the smallest unit as a "Thing", which relates to a living thing in the real world. Again with the intellegence to manage its affairs. In this concept, the smallest unit will also have the ability to react to the external events and change its status.
The paper will be presented to a panel of UAB (University Of Alabama At Birmingham) faculty and some industry leaders from AL. The final presentation is due in April. I will post the message here once its ready.
Thanks,
Moiz