Geeks With Blogs
Catherine Russell Architect, President of "Women In Information Technology" Group

15 the most important things every Software Architect should know

1. To be a great software architect you need to understand the businesses in which the company serve.
2. You’re fully expected to understand your company’s technology and the software platforms used throughout.
3. Communication is King; Clarity and Leadership its humble servants
4. Simplify essential complexity; avoid accidental complexity 
   Use The "KISS" principle. KISS stands for "Keep it Simple Stupid".
5. Architecting is about balancing
6. Avoid Scheduling Failures  
7. Architects must be a coder too, must be hands on
8. There is no 'I' in architecture 
   Empower developers
9. Share your knowledge and experiences
10. Find and retain passionate problem solvers
11. You're negotiating more often than you think  
12. Flexibility breeds complexity
13. Data is forever
   "Technologies, methodologies, and business process change but data is forever".
14. Documentation is the universal source code
15. You have to understand Hardware too

To read more about it go to:
97 Things Every Software Architect Should Know - The Book
http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

Posted on Saturday, December 12, 2009 8:18 PM Blogs | Back to top


Comments on this post: 15 the most important things every Software Architect should know

# re: 15 the most important things every Software Architect should know
Requesting Gravatar...
"There is no 'I' in architecture". Actually I disagree. Not only is there an "i" in "architecture" but a lot of architecture stuff is about personal opinion and personal expertise. It's like saying there's no "i" in "management", although at least that wouldn't look so immediately wrong.

This list is a mix of prescriptions and advice. "You have to know Hardware too" isn't "something an architecture should know", it's a prescription for something they need to do. The same with "Avoid scheduling failures"

As a bunch of ideas thrown up, it's a good starting point, but it's not finished yet. I would provide it to someone intending to become a software architect until it was more finished.
Left by Jacinta on Jan 04, 2010 5:36 AM

# re: 15 the most important things every Software Architect should know
Requesting Gravatar...
I too have a bit of a clarification on #8 - I am all for empowering my developers, but I have to keep in mind their strengths and weaknesses when so doing. As I teach and their understanding grows, I can begin to give them more and more leeway in how they implement features, but in the same way you wouldn't let a second year medical student perform neurosurgery, I see a problem with letting junior developers without much "big picture" vision and "been-there-done-that-know-why-it's-a-bad-idea" experience to make their own architectural decisions.

My own methodology for "plugging in" junior devs is something like this:
1) First, explain the "big picture" - what are we trying to accomplish.
2) Show and explain the surrounding architecture and why it was designed the way it is.
3) Point out explicitly the "must haves" (for example, "reuse these existing components to accomplish X, use this data access strategy" while also explicitly saying where there is flexibility ("I'm open to your ideas on how you want to do Y -- here are several suggestions")
4) Put "safeguards" around danger zones that will warn them if they "fall in" (for example, I have "instead of" delete triggers on tables that should only ever have "soft deletes" -- and trust me, they've been hit!)
5) Review what they've done, give positive feedback on the good choices and when a choice wasn't optimal, show them a better way and explain why it's better. If their way was just "different" but not better or worse, let it be and resist the temptation to "fix it".
6) I avoid micromanaging, but different developers need different amount of explicit instruction up front. We have some who can take an idea and run with it, others who need step by step instruction to not become crippled by confusion.

Sorry that was a bit long winded. At the end of the day though, I think it is absolutely essential for one person to have the final call and ownership of the architecture. By all means, let others in on the discussions and considerations where it makes sense and when someone has a good idea, use it and give them credit for it. But I find usually it is only the architect who really sees the whole picture, the developers may be masters of their limited domains but their understanding of surrounding systems may be somewhat limited and the best solution in a vaccuum is not necessarily the best solution in an integrated system.
Left by Anye on Mar 09, 2010 6:46 AM

Your comment:
 (will show your gravatar)


Copyright © CatherineRussell | Powered by: GeeksWithBlogs.net