Imagine
you’re dropped in a new position with no one there to help provide a smooth
knowledge transition. It’s like being dropped right out of the sky. That’s
exactly how a new software architect felt who reached out to me with this
question:

You
are brought on board as a software architect in a company with products in a
totally foreign business domain (to you). You are told you are responsible for
working with product lines X, Y, Z. Btw, here is the code base (TFS url).
Kthxbai.

Ouch.
That’s an intimidating place to start. Time to figure out how to eat the
elephant a bite at a time.

One
obvious starting point is documentation. Well, assuming the existing
documentation that isn’t horribly out of date. But properly updated
documentation is rarely the case. Much like out of date comments, stale
documentation can tell dangerous lies and lead you in the wrong direction
altogether. So avoid
spending time reviewing any documentation alone. Having others there to
vet existing documentation as you review it kills two birds with one stone. If
it’s accurate, it shouldn’t take long to confirm. And if it’s a dusty mess,
now’s the time to have the conversations necessary to get the house in
order.

class="alignnone size-medium wp-image-1741"
alt="By Andrew Dupont at http://www.flickr.com/photos/savetheclocktower/172724622/"
src="https://img8.php1.cn/3cdc5/123fc/696/31353eaf9a27e1e1.jpeg">

I
would move on by reviewing the codebase at a high level. Where is it stored?
What technologies are utilized? What skeletons are in the closet that are
immediately obvious? But don’t spend too much time exploring on your own just
yet. There’s a more profitable and enjoyable option: >buy
chicken wings and beer. Get your fellow geeks and business folk out of
the office and start picking their brains in a casual atmosphere. Bring some
paper so you can sketch down notes as you strive to understand and document the
system.

To
help drive your initial goals, consider the areas of the application that you
seek to manage and improve as an architect:

1. Security


2. Reuse


3. Duplication


4. Separation
   of concerns


5. Code
   quality


6. Test
   coverage


7. Build
   process


8. Consistency


9. Performance
   and scalability


10. What
    do people love? Hate?

Prioritizing
these areas will focus your conversations, questions, and any documentation you
decide to generate. Sure, the problem is feeling like the domain you need to
learn is too big. Having a standardized list of questions to ask helps drive
discovery. However, >consider
exactly what actions you plan to take based on the answers. This will
cut the fat on your list of questions and maximize the signal to noise ratio in
conversations. Having a finite set of areas you seek to improve initially will
focus conversations and lessen the pain of your initial learning curve.

There’s
no easy answers when you’re trying to bootstrap in a situation like this. But
organization and clear short-term goals combined with out of the office time to
help gain the necessary candor can help make the transition process more
profitable and enjoyable for all.