Many software developers just "get by" at the companies they work at, knowing just enough about the business the company is in to do their jobs. This trait is more common amongst the lesser experienced, but like those immature kids we knew in high school — some just never really grow up.

I shouldn’t be surprised, because it could simply be ignorance, but it often amazes me that many developers expect to be promoted (either by title or responsibility) simply because they have "put in their time." This isn’t really the developer vs. programmer argument. It’s more architect vs. developer, but even if a developer doesn’t have his or her eye on eventually becoming an architect, the only way to become truly more valuable to a company is by deepening your knowledge of how your company does business, regardless of the technology and tools you use on a day to day basis.

Becoming a more well rounded "programmer" will help you become a "developer", but there is so far you can get by with your technical skills alone. And even if your goal is to become a consultant, if you don’t at least focus on deep understanding of a vertical market or a business process niche, you won’t ever become more than a "contractor". In my experience, a "consultant" is a completely different role from "contractor". If you want to become a high-priced valuable "consultant", you are expected to not only understand the technology, but you also need to understand which technology is the right fit for the task. And you need to be able to "consult" with your client, taking into account their current environment, their market or business process niche. This is a good fit for someone who has either been an actual architect, or has understood the value of thinking like an architect, and has gained deep understanding of a business or process.

Although each role is extremely valuable in its own right, the amount you will be able to earn is in proportion to your perceived value to the business you are providing the service to. We cannot succeed without all of the roles participating, but we need to understand the career limitations of each. The following labels aren’t necessarily agreed upon throughout the industry, but will serve as a basis for the rest of this discussion:

A programmer is more or less going to provide similar value as a contractor provided by a consulting firm, which is often labeled with the negative-sounding body shop moniker. These people are often considered interchangeable, because, quite frankly, they are a "dime a dozen". I know people who absolutely love being a programmer, and know the technology they use inside and out. Many programmers understand the limitations of their perceived value in the business world. But some at this level often don’t understand that just "doing the time" in this position does not warrant a promotion to the next level. Learning another programming language doesn’t warrant a promotion at most companies either, but many programmers don’t understand business enough to understand why the perceived value isn’t there for them.

A developer will more or less provide value similar to that of a well rounded contractor, provided as a mid-level contractor by a higher-level consulting firm, or as an independent contractor . These people aren’t as interchangeable, but there are still more to choose from across several industries or niches, because the focus is still mainly on technology, and not necessarily the business or process. I have found that some people at this level strongly want to eventually become architects, or go into consulting. But some of them don’t understand or aren’t willing to accept that in order to become truly more valuable to their current company, they need to step out of their comfort zone (technology) and start to gain a deep understanding of their business niche. Also, at an architect or lead-developer level, they will normally be expected to manage people and processes, which a lot of developers simply hate. But it often goes with the territory.

An architect , or someone who has invested the time and energy to gain deep understanding , will more or less provide similar value as a consultant , either subcontracted out by a reputable consulting firm, or as an independent consultant or mentor . Usually, these people are not easily interchangeable, and therefore would be perceived as more valuable because of their specialty in the industry or process in which they have gained their deep understanding. Employees of a company who are architects often serve in management roles, and although some can balance the dual roles of technologist and leader, many strongly consider a consultant role, in which they would normally be responsible for only the technology role. It’s these people who often take the next step into starting their own business or becoming independent. They’ve moved beyond their comfort zone, and more clearly understand their strengths and weaknesses, and normally take that into consideration for outsourcing when building their own business. But this is a topic for a completely different article one day…

There are a few developers in my company who have expressed their desire for promotion. One has specifically asked what it would take for him to become an architect. So I put together a list, which basically consists of the following. Now remember that there has never been total agreement in the industry of the exact roles and tasks of an "architect", and there are several different types of architectural positions defined here and there. So your mileage may vary. Also, even if you don’t want to eventually become an architect, your perceived value would rise greatly from adopting most of these points:

1. At our firm, the Architect role also serves as lead developer and is considered a management position. The development staff reports to both the Architect and the Project Manager. Specifically, as an Architect, your job would include the following responsibilities / expectations. Even though we may not always have the bandwidth to perform all of these tasks for all projects or at all times, you would still be expected to be able to handle all of these when called upon.
2. The Architect is responsible for focusing on the quality, relevance, and efficiency of the development process to make sure that resulting applications meet business requirements.
3. The Architect’s focus also needs to be on the functionality, reliability, and performance of the resulting applications. He’d need to understand how to best balance the three.
4. The Architect is expected to deliver frameworks, toolsets, techniques and expertise that support and enable the development of these applications in a rapid development and time-sensitive environment, without compromising code-quality and performance.
5. The Architect is responsible for defining project scope from a historical perspective and current understanding of the business domain (in context with the business model). That means understanding, at least at a high level, the impacts to, and by, systems in the other silos. The Architect is expected to work closely with and cooperate with the team leaders of these silos. The Architect should take some time and initiative to meet with the Architects of the other silos to gain a deeper understanding of their systems.
6. When deciding how to approach projects, the Architect would need to understand how to incorporate future business goals for growth and competitive advantage. In other words, the Architect is expected to understand how the project supports the entire business, not just his own silo. The Architect should take some time and initiative to meet with the business owners of the other silos, and with management, to gain a deeper understanding of the business’s needs for future growth.
7. The Architect is expected to establish cost-effective development practices ("biggest bang for the buck"), taking into account any legal and SOX-compliance requirements, and deliver and maintain guidelines related to such. The Architect needs to be able to handle any resistance from his development staff, be able to explain the business needs requiring these practices, and ensure that the staff is following these standards.
8. The Architect is expected to iterate through current technology frameworks, and communicate relevant strategies in the context of the business domain for future enhancements to these frameworks. The Architect is expected to assist in the software selection process, and oversee proof-of-concept, and provide cost / benefit analysis, building a case to present to upper management. This process includes considering and recommending upgrades or replacement of existing architectural components.
9. The Architect is required to interface with vendors and third-party software companies to evaluate, implement, resolve, and tune the tools and components to support our requirements.
10. The Architect needs to regularly communicate strategy and guidelines effectively to team members (IT, management, business owners, users, etc.), adjusting his communication tactics depending upon the audience. The Architect must be able to communicate quickly and clearly, both verbally and written (i.e.: articulating functionality and business benefit of an entire application and user interface, from a functional and technical level, for differing audience skill sets).
11. The Architect is expected to mentor and guide design decisions and the decision-making process, staying engaged with multiple concurrent projects, and providing architectural and design oversight throughout.
12. The Architect is required, along with the team’s project manager, to evaluate his development staff, and produce timely performance reviews. The Architect is required to monitor the performance of his developers, and to provide mentoring, support, and occasional discipline. The Architect will often need to push, challenge, invoke thought and initiative, and guide and help, even though he may feel he can do the job faster and better, and want to take on the task himself. The Architect would have to be able to deal with, and often mediate the typical disagreements between team members, separating the trivial from the more serious. At times, the Architect will also be called upon, along with the team’s project manager and the CTO, to even help to decide whether or not dismissal is deemed necessary for the subordinate in question.
13. The Architect is required to do some "bureaucratic" paperwork, including becoming involved in the annual budget planning with the CTO, and providing cost analysis for projects. We understand that you don’t enjoy this part of the job at all; none of us do. But it is a necessary evil. Obviously, there will never be full enjoyment of every responsibility in any role; there are some tasks and responsibilities you may despise.
14. The Architect is expected to represent the best interest of the business at all times, using his ability to justify and speak to all technical decisions with respect to quality, and cost and time objectives. This involves looking at the big picture when making technical and process decisions, going the extra mile when deadlines approach, and although he may be physically in the office from around 9 to 5, it is definitely not a 9 to 5 job. The Architect remains on call and is responsible for the smooth operation of all systems in his silo, much of which run seven days a week, at all hours.
15. The Architect is responsible to provide quality, timely documentation, for new systems, existing and impacted systems, recovery and monitoring procedures, and standards.
16. As a leader, the Architect is expected to set precedence for his team, leading by example.