Software Architect or Handyman

Businesses need both but they don’t often realize this. First, let’s define a software architect. Later, I’ll share the qualities that I think make for a good software architect.

The software architect

Wikipedia

http://en.wikipedia.org/wiki/Software_architect
“Software architect is a computer programmer or computer manager or expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.”

Not so fast, Wikipedia. Agreed, a software architect “is” a programmer but he may not be a manager and need not dictate standards and tools.

In fact, an architect should have vast understanding of an array of technologies and approaches but might work with the existing technologies. There are many right ways to do things.

Microsoft

http://msdn.microsoft.com/en-us/library/ee658098.aspx
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman definition is:
“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”

Honestly I got lost by the end of this and have little to no idea what the heck they are saying.

Martin Fowler

“The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

Clear as mud…

Now what?

So I guess all we’ve proved is there can be many opinions about the definition of a software architect.
And that’s okay.

So now that we’ve agreed not to agree about the definition of a software architect, let’s just consider my opinion on what it takes to be a software architect and leave the discussion of “what” a software architect is, to people much smarter than me.

The software handyman

The reason for this blog is all to often companies hire a handyman to build their house and skip the architect all together.

This is a problem. Far to many projects fail to be delivered or when delivered fail when under load. All this could be avoided if an architect were involved.

The same reason you wouldn’t use a handyman to build your house without the blue prints of an architect is the same reason you need a Software Architect for your enterprise applications.

Any Software Handyman can become an architect with work. It’s something they must desire and dedicate years toward. Not every Software Handyman wants to. Maybe are happy to support existing applications and write code for new applications according to a specification. We need these guys. They are the unsung heroes of IT.

What it takes…

So, maybe I can’t give you one definition of an architect. Generalized terms and descriptions offer little to the concrete world we programmers live in.

So, dispensing with the BS titles and ego boosting descriptions I’ll simply say what I think an architect must be.

Be experienced

Sounds obvious right. Well it’s not. A programmer supporting an application for 15 years might be experienced but is not Software Architect material based on that experience alone.

A Software Architect must be experienced in a variety of environments with many technologies accompanied with both successes and failures. A diversity of solutions might include client-server, n-tier, distributed computing, and enterprise application integration (EAI) solutions. Failure experiences are as important as successful experiences.

Anyone who does anything significant is going to have failure. I wouldn’t trust anyone who didn’t.

Know surrounding practices

Surrounding practices are all those “things” that bump up against software architecture but are not specifically architectural tasks.

Examples include project management, process methodologies, networking, and testing. If we had a brainstorming session we could easily come up with a dozen more.

Be a communicator

The only thing worse than having no architect is having an Architect who cannot communicate or is a curmudgeon. Instead of not having an architect which leaves room for improvement you have someone in place nobody wants to follow and who could be difficult to remove.

Like the Project Manager an Architect must be able to communicate ideas and listen to his programmers. As much can be learned from other programmers as personal research.

I’ve seen grouchy old men who can’t keep up with the young wiper snappers and it’s imply uninspiring. Don’t be a curmudgeon! Programming is supposed to be fun. Don’t beat your programmers up with “Standards”, encourage them with “Guidelines”.

Study, study, study

An architect shouldn’t have to study anymore. Right? I wish!

At the rate of change technology is taking the architect job is no longer as easy as it once might have been. Today an architect must be a perpetual student, always learning, and always testing out new approaches and techniques.

Whatever technology you are using today is outdated in two years. When reading technology specific blogs and listening podcasts I check the dates. I skip anything over 6 months old and anything over 3 months old I view with skepticism.

The Architect job is a hard hard job and if you don’t want to do the work then that’s OK. Don’t take the job.

I imagine this is the one topic that will piss other architects off the most. We like to feel like we have arrived and all we need to do now is attend meetings, give our blessing and deliver edicts. How nice that would be.

Nope, we have to work our tukisses off more than anyone else because not only must we understand the technology but we must be able to place it into an enterprise context and teach it. When teaching we must know the technology many times more than if we simply wanted to use it.

Be a coder

Yep, not only should an architect have written several man years of code he’d better still be writing code.

As stated earlier, technology is changing at a rapid pace. An architect who is not writing code is quickly outdated and will have his lunch eaten by the next young programmer who “is” excited about technology. He won’t have the experience an architect should have but he will be able to code circles around a non-coding architect.

So pick a project, select a set of project requirements, humble yourself if needed, and get coding. It’s the only way to stay in this game.

Read/write articles, blogs, podcasts… oh my!

There is so much information published every day the even focusing on a narrow subject you can not hope to read everything available or even keep up.

It doesn’t matter. Today’s good architect reads every article and blog he can, has a list of podcasts. When enough time isn’t available cherry picking the most important podcasts is necessary.

Subscribing to news letters is an excellent way to stay on top of the best articles without having to search for them. When you discover a programmer author you respect then find his home page, contribute comments to his articles because this will make you a more critical thinker and you’ll, in time become a thought leader.

You should probably blog once a week because that forces you to continue learning and share what you have learned with the rest of us.

Be a teacher, mentor, thought leader, and be opinionated

This is the fruit of your labor which will multiple when it comes into contact with other programmers and applications.

Be a teacher to all and a mentor to those you see potential in. Chances are someone was a mentor to you. You could change a life. In this industry we do change lives.

Be an opinionated thought leader. We can never know it all and if we try to know something we risk being wrong. There is nothing more uninspiring than an architect who never has a solid opinion and even less inspiring is an architect who never changes or updates his opinion.

So be a though leader and come to some conclusions. When more information is available change those conclusions. Don’t keep it a secret out of fear someone might think you are wrong. Share it and have a bit of confidence.

If you aren’t making mistakes then you aren’t doing anything.

Feedback welcome

Being opinionated means I will sometimes be wrong but I’ve given myself the opportunity to get a few things right. I’m bothered by my “handyman” metaphor because it doesn’t give the deserved credit to the everyday coder. I might completely change that.

If you have feedback, I’m open to learning. You can leave a comment or just email me. I’m not looking to build some large readership base and boost my ego. I simply want to be better tomorrow than I am today.

Thank you. Bob

This is just an excellent blog from another blogger. 

Rather than copy and paste

it all here I'll give you an excerpt then a link to the full article.  In time I'll replace this with my own thoughts eventually but I want time to process...

"The Myth of “Good People”

By Rich, June 21, 2010 10:36 am

I often hear the phrase, “We hire the best and brightest.” It leaves me wondering who hires the “worst and dimmest.”

In order to experience real success every team needs to determine how they can achieve extraordinary results with ordinary people. When I teach our Agile Explained class, I reference the six focus areas of Six Sigma. These include Environment, Measurement Systems, Methods, Materials, Machines, and People.

My belief is most management teams first look at the people as the key to solving their most pressing problems.  “If we only had better people things wouldn't be this bad.”

Don’t believe it. We have good people in our industry. The people in our industry are smart, dedicated, educated, and diligent. It’s not about the people."

Link to full article...

It takes 15 minutes to fully recover from conversational interruptions

I’ve known about this study for about 6 years. When you are working, it takes 15 minutes to fully engage your mind into a single task. When you are interrupted, even for a moment, it takes 15 more minutes to be fully engaged again.

So, 4 interruptions an hour can nearly cause zero productivity for that hour.

Relationships matter, so this might not always be bad, but this is something to be aware of.

A company I worked at used to have a policy called, “the cone of solitude”. This was a period of time where our phones are turned off, email is shut down, and we committed to not interrupting each other.

I’m thinking about instituting this for myself at work for 2 hours a day. I think it will be a shock to my co-workers, because I'm as chatty as the next person, so I’ll go easy on them but I also believe it’s a good practice.

Microsoft Research Article...

Code Complete by Steve McConnell

This is a must read for any developer or development manager. After reflection, I consider this a first level book for developers; still I was impressed with what I learned from this book.

Many of the ideas and concepts are known to us instinctively, if you practice sound software development. It helps to read what we know to confirm that we are on a right path.

I also found this book useful for getting entire teams on the same page concerning defect correction, code documentation, and general process issues. This is a perfecting your craft kind of book and the entire team can grow together. None of the material is difficult and easily lends itself to some debate.

Some Sad IT Facts

 

These are fairly known but often dismissed facts about the IT industry. If you see these facts presented you will find IT managers and developers nodding their heads in agreement.
That is as far as it goes.

I'm always amazed to see an IT manager hesitate to purchase a piece of software because he is afraid of wasting 300 dollars but there is no hesitation to waste 10's of thousands or even 100's of thousands through his/her indifference to good software management practices. 

I found a company that specialized in process. I was very excited to be a part of a team dedicated to making quality software at an affordable cost. One week into this project, I realized that very basic steps were missed. They were not oversights. It was simply thought that gathering quality requirements was not worth the time and effort. I was shocked. Don't these people realize that while not sexy, this is still a critical step in the process?  All quality is related to requirements.

As I predicted, we went over budget around 200 percent. We missed our deadlines on a fix priced project and pissed off the customer. All because gathering quality requirements was not sexy enough. Seems it was more important to measure employee productivity and create schedules. Of course, it's impossible to measure productivity if you don't have a clear definition of what you are supposed to produce and let's not get into the impossibility of predicting a schedule without requirements.

SIDE NOTE: I'll cover this in another blog, after further thought. NEVER measure your employees for the purpose of criticism. When you do this, you will never get accurate numbers from your employees ever again. It's just a fact of life.

The following are the sad truths of IT:

From the Hugh W. Ryan article of Outlook Journal

• Only 8 percent of application projects costing between $6 million and $10 million succeed.
• Among all IT development projects, only 16% delivered to acceptable cost, time and quality.
• Cost overruns from 100 to 200 percent common.
• Cost overruns for IT projects have been estimated at $59 billion in the United States alone.
• IT workers spend more than 34% of their time just fixing software bugs.

Other reports make the following claims:

• Only 28% of projects are completed.
• In the UK, over $1 billion a year is wasted on poor software quality.
• 70% CRM project strategies fail.
• 90% companies cannot show a positive ROI for CRM.

Here is an interesting fact that I 100% believe is true but it is still shocking to comprehend the incompetence that must allow this.

"According to the Cranfield School of Management, the more ambitious the return on investment for the project cited in the business case, the more lacking the project plan is likely to be."