Where Should an Architect Begin?--reference

http://www.bitnative.com/2014/01/24/where-should-a-software-architect-begin/

Where Should an Architect Begin?

Posted on January 24, 2014 by Cory House

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.

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.