No hacks allowed!.. or are there?

What, Why and How

One can frequently hear "no hacks allowed" in programming discussions. This is also frequently considered a trait of a good developer that safeguards his code. However the subject is not quite this simple.

Daily motto (not just for architects) - "Aim for success, not perfection" Dr. David M. Burns

Unfortunately our industry in general has no clear definition of an architect. Many companies struggle to define roles and responsibilities of architects and are never successful.

What is an Architect?

Architect Types

According to Mark Richards' experience and fairly thorough industry analysis there are 3 general architect types. The distinctions are best summarized by the diagram below. For example an Enterprise Architect is expected to still be technically knowledgeable but the emphasis of this position is on technical breadth (rather than depth), business domain knowledge, communication and leadership.

Architect Responsibilities

Everyone knows what programmers do and even tech lead's responsibilities are more or less obvious. Saying that architects architect is the easy way out, is a recursive definition and is thus invalid. To begin with the best definition of what architecture is I ever heard is that it's something that is really-really hard to change. For example, the choice of programming language, the architectural design (SOA, event-driven, etc) and to a lesser degree the choice of frameworks and such is architecture. So what does an architect do on a daily basis? Does he sit and ponder these complex decisions (which you don't have to make very often)? An industry survey of actual architect responsibilities and expectations across many known IT companies came up with the following list.

• Analyze technology industry and market trends
• "Sell" the architecture process, its outcome, and ongoing results
• Analyze current information technology environment to detect critical deficiencies and recommend solutions for improvement
• Define the principles to guide technology decisions for the enterprise
• Design and direct the governance activities associated with ensuring compliance with the architecture
• Exposure to multiple, diverse technical configurations, technologies, and processing environments
• Exceptional interpersonal skills, including teamwork, facilitation, and negotiation
• Understanding of the political climate of the enterprise and how to navigate the politics

Architect Skills

According to Mark there are several key skill areas for any architect. I will not cover all of them equally because I think some of these are understood much better than others. I will mostly concentrate on the underestimated category of Leadership and Communication.

Leadership and Communication

I will bombard you with some quotes here (straight from the presentation) as I think they get the point across quite nicely. I have to add that these leadership skills are important and relevant to almost anyone and are not restricted to architects only.

"The day soldiers stop bringing you their problems is the day you have stopped leading them" (Colin Powell)

"Great leaders are almost always great simplifiers, who can cut through argument, debate, and doubt to offer a solution everybody can understand" (Colin Powell)

One of the key aspects of architect's job is to talk to business and translate their needs to technical decisions. See if you can translate following typical business requests into technical and architectural decisions

We need faster time to market to remain competitive

Due to new regulatory requirements and penalties, it is imperative that we be able to complete end-of-day processing in time

Our business is constantly changing to meet new demands of the marketplace

Our plan is to engage heavily in mergers and acquisitions in the next three years

We have a very tight deadline and a very tight budget for this project

A great example given by Mark was of one famous Lockheed aircraft designer. He was asked by DoD to create a lightweight fighter capable of 2-2.5 Mach speeds. After he asked why, he was told that it needed to be fast to escape a fight if need be. What was designed in the end is a very light and maneuverable aircraft that was not, however, capable of 2 Mach speeds. Nevertheless, clients needs have been achieved and F-16 remains one of the most used fighter aircrafts today.

An interesting opposite example by Ted was about Edwin Armstrong - the creator of FM radio. He unsuccessfully tried to sell idea to RCA and eventually saw no personal gains from his discovery. The point is that it's not enough to come up with a brilliant idea but you also have to be able to "sell" it to business.

However, talking to business and leading technology folks does not mean that architects do everything business says.

Don't be afraid to ask the business for a change in requirements to simplify a complex architecture problem (trade-offs)

Focus on simplicity and always question anything that adds complexity to the architecture

To summarize an architect should be able to speak both Business and Tech language and clearly explain to either camp the reasons and trade offs behind all decisions while maintaining a pragmatic and feasible approach to decisions making.

Interestingly, the social aspect of programming was one of the main points of the Keynote by Ted Neward and there was a whole presentation (which I did not attend) about Communication Skills for Knowledge Workers by Neal Ford.

Domain Knowledge

I think that there's mostly a universal agreement that architects need to be able to communicate in domain-speak. Here are a few examples of why it is necessary

By taking into account business goals and industry trends you can design the system to better handle future changes

Helps you decide which architecture pattern may work best to satisfy the specific needs of the organization

Knowing the domain helps you speak the language of the business stakeholders and gains their trust faster

Technical Knowledge

Any, and especially enterprise, architect needs to have technical breadth. But what is breadth? After all you cannot know everything. On the picture below it is the top two portions of the triangle. Although it is hard to know a lot (the top portion of triangle), it is possible to know a lot of what you don't know (the middle portion). That still, however, requires constant reading, attending conferences and mingling with colleagues.

Sources

This wiki is mostly based on Mark Richards' On Being a Software Architect presentation. I have also included some ideas from the Keynote by Ted Neward.

Free/Busy info in Outlook 2007+ outside of Active Directory domain

Say you are running Outlook 2007 and for any number of reasons you are outside of Active Directory domain. As of now your Out Of Office Assistant and Free/Busy info in the calendar will not work. Without getting into too much detail of new Exchange 2007 protocol (see this article for more info) this happens because Exchange autodiscovery service is not setup properly. After some fiddling around I found a way to hack it. It takes only 5-10 minutes but goes a long way toward better user experience for yourself.

SunOS, backspace and vi

Are you a Linux user forced to use SunOS for a part of your work? Simply navigating around shell and vi is a major PITA. How can it not be if backspace and delete don't work? After some looking around I came up with a pretty standard bash solution of .inputrc config. See the file below - it solves all the problems and makes SunOS behave just like Linux. It also lets you search your bash history with up/down arrow keys (type something and then hit up/down and it will find commands that start with these characters).