10 ms·

Software Architect – A Role, Not a Job

141 points by davidkellis 12y ago

rdtsc 12y ago
Besides, when I hear someone referring to themselves as "I am an architect" (in the context of software development) I usually read between the lines as "I have a rather inflated sense of self and am quite susceptible to flattery". It is kind of like the milder version of Rockstar or Ninja Developer. I know it is an official title in many organizations (unlike say titles like "Rockstar Dev IV"), nevertheless, it still sounds a bit silly to me.
- ChicagoDave 12y ago
  This is funny. At one client, my team would yell, "The Architect!" in a very sarcastic manner to remind me I was just a developer with a few years on them. I agree, the title can be misused or offer an inflated sense of self for some. A reminder though... I was considered a .NET Architect from about 2004 to 2009. I'm an independent contractor, so I'm always changing clients. In 2009/2010 I would get calls and the recruiters would talk to me about senior developer roles. I would complain, "I'm really an architect," and they would say, "Not anymore. You don't have any front-end architecture experience and your JavaScript background is weak." Lesson learned. You may be an architect for a moment, but to maintain that title, you have to continue to learn and grow. If you don't, you may find out you're just a legacy programmer. I'm sure that can be very humbling.
  - yitchelle 12y ago
    Good points. For an architect, maintaining your knowledge set is important so that the correct decision is made. However, I think it would be done in a contextual manner. Ie, if you operate in the world where Cobol is main technology driver, would you have to continue to keep up your knowledge?
- benjaminwootton 12y ago
  It's a bit unfair. It's a job title, a career, and a full time job for a lot of people. Whether or not it's necessary and how architecture should interface with everyone else is open for debate, but it's not really an indication of the persons level of ego.
  - tracker1 12y ago
    I've bounced from UX developer, to systems developer, to architect, director and back to senior developer... I'm currently working in an architect/senior developer role... The title is just that.. it associates with a role you play. I'm designing a relatively large system, and making suggestions towards the tools, technology and implementation (as well as doing a lot of said implementing). I can't speak for most... but for me, it's the position I'm in... Of course my role is much closer to that described in TFA... which is what being in a smaller organization calls for. I like solving problems, and developing solutions.
- firebones 12y ago
  I was getting ready to undergo a surgical procedure once. The doctor looked at my chart and saw I was (by title) a "software architect". He asked me to clarify. I described what the job entailed. He scoffed, "So you're not a REAL architect," as though I were inflating the title my organization had given me. Didn't really give me any reassurance as he wielded the knife.
  - kragen 12y ago
    Did you tell him he wasn’t a real doctor because he lacked Ecclesiae declaratio?
  - pavlov 12y ago
    Well, your doctor did have a point. In most countries, "architect" is a protected title. Architects are required to register and they must meet very specific requirements. If a hardware repairs guy adopted the title of "Doctor of Computer-Medicine", I think most of us would find it silly. Personally I agree that we should let real architects keep their title rather than muddy it with the confusing baggage of our business.
  - icedchai 12y ago
    Hah. It's true. We're not real engineers either.
- dwenzek 12y ago
  Yes, there is a risk to be boastful. But the risk is shared by many positions and roles. It's not enough to say I'm an architect or a full stack developer or UX designer, there are a lot of skills and attitudes to have along the days to fill plainly the role in a team. It's why, I totally agree the post. To fulfill the architect role, you have to be on a daily basis with the team, to design, develop and debug with them. This is not about being a Rockstar, but yes, this requires some broader and smarter vision on how the whole system is being developed. And this implies responsibilities too and even a bit of humility when things do not go like expected: it is at these difficult times that we can judge whether you deserved the role. Besides, titles have their importance. This is maybe a pity, but, for sure, you don't have the same audience from the management when you are introduced as a software architect rather as a developer. Same thing, when you are looking for a job. I'm a freelance developer with 20 years of experiment and I introduce myself as a software architect even if I'm looking for contracts where I will be plainly involved in development tasks. Each time I failed to do so, I put myself in situation with no chances to use my skills and to help the project at the level I could have. On the contrary, with an architect hat, I have been often welcome with some suspicion ("how can this guy fix the mess we're in?"), but this gave me the opportunity to work effectively with all team members and to truly help them.
  - keithnoizu 12y ago
    Nice description. On a side note but related, I really think one of the major difference between a developer versus an architect is having strong grasp of how components can fit together and impact overall costs, quality and timelines for a project even if you aren't familiar with the specific details of those components. For example if you need to design out something highly distributed you don't necessarily need to be proficient in erlang, or scala + akka, or clojure before you start but you do need to understand the pros and cons of each system, the underpinning philosophy on how they work and basic behaviors of the solutions in terms of speed to develop, benchmarks, known scaling problems, trouble spots etc. Sometimes you need to use the right tool for the job even if you don't know the tool yet. Sometimes that means taking a deep dive to get to know the technology, talking to experts on the technology and fitting their feedback into the overall picture of what the system needs to do. Which is a very different skill set then being able to pack as much functionality as possible into an MCU, or improve average performance on an algorithem, or being able to rapidly construct a component. Which is why I advertise myself as architect and not as systems developer, or ux guy or full stack engineer. It's the type of work I enjoy doing, and it's the work that clients get the most bang for their buck out of me for their retainers. It doesn't mean I think I'm a better developer than non architects. In a lot of ways I'm not, but I does mean that I think (rightly or wrongly) that I am often better at sleuthing out the rough behavioral characteristics of components or technologies needed for a project and knowing how to leverage that high level understanding together for designing or improving a project.
- keithnoizu 12y ago
  Maybe. Although I think there is a distinct mindset difference between someone who is a really good coder versus a really good designer. Personally I refer to myself as a software architect, partially because it's one of my job titles and partially because laying out large multi-component systems comes very naturally to me and is something I seem to be more proficient at than many developers I meet. Meanwhile when it comes to actually sitting down for implementation work I'm just on the average to high-average side of things. Finally when it comes to algorithm design and analysis I'm pretty mediocre. Although, I hope, that is mostly from never having to work in that area very much. I sort of think it boils down to if you are a forest or trees sort of person. Normally I approach writing code as modules, then classes and then methods working my way down to implementation instead of going the other route and starting with methods and building up to classes and modules. So when I sit down to start a new project I normally plug in most of the classes and interfaces first for the sections i'm working on and then implement down from class design to coordinating logic to specific methods (tweaking my interfaces as I go). Meanwhile I know some other developers that take the opposite route and start with low level implementation and work from there up to coordination level stuff. They can't really feel out the big picture until they have a solid grasp on the low level implementation details and I can't really feel out the low level implementation details until I have a good idea of the big picture in my head.
ChicagoDave 12y ago
I've always viewed software architecture the same way start-ups function. If you plan to build frameworks, guidelines, and processes, you should treat those things within your company as a new product or service. Your customers are all of the programmers, some of the business liaison people, and stakeholders of the systems within. If you build a framework and approach your customers for buy-in and they refuse, you've failed. And failure is as simple as having complicated documentation, extended ramp-up periods, or high turnaround in your development teams. Know your customer. Get their buy-in before you complete any big changes. Don't assume your brilliant ideas will be received or successful, no matter how great they may be.
nickbauman 12y ago
Agree, but I would go further. The term "software architecture" is one I actively disdain. Architects build buildings. If there's anything we learned from comparing civil engineering to software development it is that they it is harmful to draw parallels. So while using architectural metaphors is sometimes ok, this term is not. Software design, on the other hand, is something everyone who writes software is involved with. It is not an act reserved to few and disseminated to the "great unwashed coders" like they are some kind of construction crew who just read blueprints while typing the source (another crappy parallel drawn from the same place as the term 'software architecture')
- bottled_poe 12y ago
  I disagree, but I also agree. I believe software can be planned to near-perfection by one or more architects. If you establish a design, the implementation can be verified, at least to the level of detail defined in the plans. In my experience, the problem is that I find coding to be a bit tedious. Problem-solving is the interesting aspect of software development, and when that gets taken away my productivity drops. I'm sure not all developers feel the same. A great engineer knows their colleagues well enough to delegate effectively.
  - kragen 12y ago
    If you first design your software to near-perfection and then find coding it to be tedious because no problems remain to be solved, I recommend that you obtain a thing called a “compiler” to do the coding part for you. You see, a “compiler” takes a formal specification of your design as input, and automatically produces a program as output! I know this sounds like science fiction, but we’ve been using these things for a while now, even though they took a while to get accepted. Alternatively, if you’re already using a compiler, have you considered that maybe you’re doing some things by hand that the compiler could do for you? Modern “high-level languages” (as the design notations compilers accept as input are known) are astonishingly capable of eliminating repetition in the “source code” through the use of “abstractions” and “embedded domain-specific languages”. Of course, there’s always the risk of making your system so abstract that you can’t figure out how to debug it! So you probably don’t want to remove all repetitiveness.
benjaminwootton 12y ago
IT over the last 10 years has been a story of breaking down siloes. Agile development was all about breaking down the wall between IT and the business - getting them collaborating earlier and more often. TDD and test automation are bringing development and test closer together, getting testing involved earlier in the cycle and quality build in. DevOps is bringing the build and run halves of the IT organisation closer together, breaking down that particular silo. All of the other siloes need to go the same way - infrastructure, information security, architecture. Siloes were great for a waterfall world, but when we want to move quickly the whole concept of functions and job titles is too slow and process driven. What I'm trying to say is, yes, I agree with this post whole heartedly.
- djcapelis 12y ago
  Information security seems like it has especially never worked well as a silo. Without building it in proactively at the beginning and continuing to design with it in mind, software quality wrt security will always suffer badly. Unfortunately the stark reality is that for almost everything, worrying about security means you ship things slower. It's not that people don't know they need to worry about it, it's that every short term incentive exists to shove it aside. And so people have, and do. Security doesn't drive user growth. (It can make people go away eventually. But it almost never drives adoption.) There's a real tension between "move fast and break things" and "break down all the silos".
- tracker1 12y ago
  While I agree with the post... And most of your comment, I find that a large issue with a lot of "Agile" development, is that not enough thought is put into the architecture and overall design ahead of time. Another big breach is when early on a lot of conveniences are put into place, and the knowledge therein is lost in the ongoing development.
- pjmlp 12y ago
  From my enterprise seat, most silos are still there and won't go away regardless how much we wish they would. I have seen Agile progress from the new cool thing, requirements for all kinds of agile certifications to the current trend of mini-waterfall sprints. All because it doesn't matter if the IT team wants to be agile if the reaming part of the corporation keeps doing everything the old way.
cies 12y ago
At the place where I work, I've recently described the role of Software Architect. It is a project-role, so only exists in the context of a project, and usually only in the first weeks of a project. We describe it as follows (feedback is very welcome): # What is expected of a Software Architect? * Makes high-level technical design choices. * Records those choices, and the supporting arguments, in a deliverable. * Ensures feasibility of the technical approach (and informs the PM). * Identifies risky aspects of the project (and informs the PM). * Dictates technical standards (e.g.: coding standards, tools, frameworks, platforms). * Provides the team with a "standard way" to develop the software. * Ensures compatibility with Hoppinger's technical road map. * Aligns all his decisions with the resource constraints of the project. * Recognizes "reuse" opportunities (either existing software that can be incorporated, or spin-off contributed/reused). * Observes and understands the broader system environment (of the customer). * Creates architectural overview diagrams and/or descriptions when needed. * Knows which applications are used in the organization. * If possible: subdivide a complex application, during the design phase, into smaller, more manageable pieces. * Understand the functions of each component within the application, and the interactions and dependencies between components. * Communicate the technical design, "architecture", to developers. * When needed also provides hardware requirements (or several options), considering the needs and abilities of the customer.
- EtienneK 12y ago
  This is pretty much the description of an Architect that the article is arguing against. From my experience, Architects that conform to the above requirements tend to sit in their Ivory Towers and are oblivious to the problems on the ground.
  - alphadevx 12y ago
    > ...and are oblivious to the problems on the ground. Should they even care, if it's not their role? Engineers are hired to problem solve, architects are hired to design. Think about an architect designing a building: should he/she know the intricacies of every separate sub-system in the building (plumbing, wiring, ventilation, gas...), or rely on experts in each of those sub-systems to resolve implementation issues? The architect is only concerned with pulling together all of these separate efforts to form something cohesive and elegant.
br3w5 12y ago
It's certainly true that if someone in a an architect position does not know the technologies intimately then how can they make informed decisions about it. They can certainly maintain consistency at a high-level e.g.this next solution will have a REST API, but people still shouldn't be making those decisions without a detailed understanding of the impact of those decisions. I have seen devs move into a pure architect role but as time goes on it does become apparent that they need to be closer to the detail. I think the definition of architecture should be a dev team effort with the architect role making the final decision (be that lead dev, CTO, whatever job title for that person). I like the idea suggested in the thread of making the architect a product team/project role.
- ukigumo 12y ago
  An architect, at least one worth his title, does not work in isolation. The article talks about a type of architect that I call tech lead. It has as much to do with the architecture process as a front-end developer has to do with mechanical engineering. There are many types of architect, with vastly different roles and functions within an organisation from pre-sales to business strategy so I strongly argue that people should stop looking to become architects as a step up from being engineers in the same way that fashion models should stop looking at picking up acting as some sort of a graduation when when they get too old for the catwalk. Some can do it because they have picked up enough knowledge and insight along the way but, for most, it's a new career with a whole new set of skills and responsibilities.
  - br3w5 12y ago
    An architect needs to keep learning in much the same way as developers do. I would look to this person to make the decision on the high-level system design/architecture for each solution. I think they should also be pushing the dev team to look at new tools and technologies, and it would really help if they had some understanding of those technologies. I think there is a similar debate (but from a different angle) around should your project manager or scrum master be technical. Obviously an architect should be technical but how much familiarity should they have with the technologies being implemented. I would say they should have a good understanding of them. There is some benefit to being conceptually removed from low-level technology concerns, in that the architect won't get caught up in design patterns intrinsic in the technologies the devs want to use, that could actually be detrimental to the overall design - the old 'the devs can't see the wood for the trees' argument.
alphadevx 12y ago
> One risk of the integrated architect model is that an architect can get preoccupied by implementation. Nailed it. In the same way that ex-engineers often struggle to let go of the code when they switch into management, I've seen the same thing happen to those switching to architect roles. They find it hard to step back and trust others to take care of the implementation, and this often leads to the worse kind of micro-management tendencies manifesting early on in this transition period. The best architect I ever worked with was a terrible programmer (by his own admission, and I can confirm because I worked on fixing his code). But he was able to bring to bare tremendous technical improvements on any project he worked on. It's a different mindset, more focused on the design of the implementation rather than the actualization, and it's really not suited for every ex-engineer (just like management).
dingaling 12y ago
> In the same way that ex-engineers often struggle to let go of the code when they switch into management, I've seen the same thing happen to those switching to architect roles It's not always a choice; where I worked, as architects we sometimes had to put on our hero-capes and wade into code to save the day. Saying "that's an implementation issue" doesn't work when the implementers don't have the savvy to make it work. Or, worse, throw up their hands and say it's impossible because of the unreasonable demands of those ivory-tower architects . Can't we just save the credit card details to a local database instead of all that integration stuff? At the end of the project, if it works it's despite the architects and if it fails it's due to the architects... always in the spotlight but never in the limelight.
- harkyns_castle 12y ago
  > It's not always a choice; where I worked, as architects we sometimes had to put on our hero-capes and wade into code to save the day. I think its a matter of context, and one "architect" from one organisation to another will differ greatly. I've never seen a good "hands-off" architect in my experience. They've normally been the failed developers, or the ones that have been able to network to such an extent they get to a hands-off role. But, that's in context. Dilbertian almost.
  - crdoconnor 12y ago
    >I've never seen a good "hands-off" architect in my experience. Because when it's done right, coding is 80% "architecting" stuff. If there is more than a tiny amount of menial work involved in programming then you are generally doing something very wrong. I think architect is one of the worst metaphors to ever grace the software engineering profession, by giving this impression that a programmer who can work "hands off" is even possible.
    - harkyns_castle 12y ago
      Couldn't have said it better myself, a really well said point or series of points.
    - 12y ago
snarfy 12y ago
We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn't matter if we had them. The business believes iterating on the business plan and direction is agile development, the result being a code base full of dead ends and code that should be refactored or deleted, but can't because it will take a non-trivial effort to do so since data is already deployed to production. If we ever do take the time to clean up, that's a sprint the business doesn't get any backlog items, so those sprints are few and far between.
- keithnoizu 12y ago
  Someone probably should have architected out that release pipeline and planned for scheme version control and a more efficient data migration process. ;)
- antris 12y ago
  Doesn't sound like agile development to me. In Agile development you usually refactor as you go. Refactoring is not a separate task, it's part of the process. http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html http://c2.com/cgi/wiki?WhatIsRefactoring http://c2.com/cgi/wiki?WhatIsRefactoring
- ExpiredLink 12y ago
  > The business believes iterating on the business plan and direction is agile development The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored.
  - antris 12y ago
    > The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored. Sounds like quite a passive aggressive way to solve a communication problem. "You only said we needed feature X, you didn't tell us not to mess up our codebase during the process". It's not the stakeholders responsibility to tell you how to do your job. You don't wear clothes at work because it's in the backlog, you do it because it would be unprofessional not to. Even when stakeholders have asked me to take shortcuts, they usually seem very level-headed about it once you start the dialog. I've talked to stakeholders proactively about tradeoffs of taking shortcuts and they seem to understand when I compare "not refactoring" with "making a mess". In my experience, people understand what messes are. If we make a mess, it will slow us down as long as it is there. We can clean it up later, too, but it will cost us more because it is slowing us for a longer time. Taking shortcuts without telling stakeholders is unprofessional. If the stakeholders don't explicitly tell you to not refactor, refactoring is implied.
keithnoizu 12y ago
I think the arguments for or against keeping full time architects on staff versus having developers who also work together to design out systems are the same the argument for or against separating out internal systems and test automation from regular developer roles. For example googles SET, STE & Engineer roles. Personally I like more integrated teams and believe a good architect should be down in the mud writing code half the time in-between designing things out. Partially because technology keeps changing and you need to keep an eye on developments and partially because it's a shame to waste that big picture understanding when tacking debugging or designing out specific components, and partially because it's important to keep an eye on cod equality. I've done the architecture thing both ways however, throwing design notes over the fence versus designing and helping with implementation, and honestly they both have their pros and cons. Tighter integration reduces communication problems and wasted effort. On the flips side having individuals focus on producing what they produce best can be more efficient then forcing team members to wear multiple hats. For the same reason why a country much better at growing expensive widgets and slightly better at growing gaskets than another country should focus their production efforts on widgets while the other country focuses their production efforts on gaskets. The major problem in my own humble opinion with the separating out the architecture discipline is that once you step away from the code you're basically kicking off a countdown to the point where your understandings of the technologies involved and current practices and tools doesn't match up with reality. Which impacts your quality as an architect. You can say similar things about technical project managers, general managers and ctos who no longer code,
tootie 12y ago
There's a comment on that post that I 100% agree with. The architect is responsible for the architecture (among other things) but that doesn't mean she's doing all the work. It's a team effort. The artchitect is just the one who is responsible for the final deliverable. Same with every role. It's defined by it's responsibility, not necessarily by the work being done.
kitd 12y ago
I don't like the term Software Architect. I think having an architect for software alone is redundant. That's part of the job of coding. Where I believe there is value is in having a System Architect, who will take a wider view of the system as a whole, especially wrt the users and how they will use it, plus all the add-on mechanisms required to install/maintain/backup a production system.
exelius 12y ago
But here's the thing - dedicated architects often aren't just focused on software. The same architecture patterns you use for building software are just as applicable to business processes or organizational design. Architecture as a function has been consolidated to ensure effectiveness across all parts of the business, not just software development (which is why it's often called enterprise architecture or solution architecture). A good architect should work WITH the software experts to determine the optimal architecture, but sometimes the business needs will require an architecture that is less optimal than it would be in a vacuum. In organizations large enough to require a dedicated architecture function, software developers are poorly positioned to understand the various requirements of the architecture.
- codingdave 12y ago
  If an organization has grown so large that software developers do not understand the larger business and organizational requirements, then that organization has already gone too far down the path of compartmentalizing their teams, at least in terms of job satisfaction and career growth for the devs. When I worked in medium sized organizations (4000 employees, etc), we did have devs who did not understand the business, but they were outsourced contractors. Every actual employee knew the broader picture of their own applications. Those of us who worked on platforms that pervaded the enterprise did have enough knowledge to make architectural decisions. We also knew enough to pull in other people when a decision stepped outside our area. After a few years, a new CIO did form an enterprise architecture group, and hired a new guy to be the "enterprise architect". We were told that software devs need not apply. Morale died, projects started to go very badly, and within 2 years everyone had quit. So while there may be organizations that really do need a separate enterprise architect, I'm pretty much on board with the article, and feel that those places are likely to be quite craptastic places to work.
  - exelius 12y ago
    I agree - they're not the kinds of places that engineers who love working in a startup would enjoy. But if you're going to scale as a company past a certain size, you have to centralize these functions, which is why large enterprises are such a pain in the ass to work for. If you don't centralize the architecture functions, you start to get multiple independent groups building the same things because the communication is too hard to manage across a big organization. Enterprise architecture is a totally different skill set from software development - it requires a business mindset, not a technical one. It's really more a requirements gathering job than a development one, and it wouldn't be enjoyable to most developers anyway. It's one of the inflection points that growing companies have to deal with - the people who built the company may not be right to maintain it going forward. The job becomes more corporate and less fun, and growing companies often see a lot of turnover during these times. But some people will stay on, as job security to support a growing family becomes more important to a developer than fun projects or the content of their work.
hacknat 12y ago
This might be controversial, but if you want a good example of a code base where this is painfully obvious look at Android, especially the UI components. There are interfaces for everyyyyything. So many of the UI components are unnecessarily internal, which can be a pain in the butt if you want to do something just slightly different than default (you obviously can't inherit form an interface, so you end up copying the code). A lot of the cruft is probably from trying to make Java work, but when I read through the code I find myself wondering why it was implemented the way it was implemented and the only explanation I've been able to come up with is the one described in this post.
- rifung 12y ago
  I completely agree. I find the Android APIs absolutely appalling. My former coworker knows both iOS and Android, having done Android for many years, and he refuses to program for Android ever again. He would also tell me that the time it takes to implement things in Android is usually 1.5x - 2x longer than the equivalent thing on iOS

141 points by davidkellis 12y ago

rdtsc 12y ago

Besides, when I hear someone referring to themselves as "I am an architect" (in the context of software development) I usually read between the lines as "I have a rather inflated sense of self and am quite susceptible to flattery". It is kind of like the milder version of Rockstar or Ninja Developer. I know it is an official title in many organizations (unlike say titles like "Rockstar Dev IV"), nevertheless, it still sounds a bit silly to me.

ChicagoDave 12y ago
This is funny. At one client, my team would yell, "The Architect!" in a very sarcastic manner to remind me I was just a developer with a few years on them. I agree, the title can be misused or offer an inflated sense of self for some. A reminder though... I was considered a .NET Architect from about 2004 to 2009. I'm an independent contractor, so I'm always changing clients. In 2009/2010 I would get calls and the recruiters would talk to me about senior developer roles. I would complain, "I'm really an architect," and they would say, "Not anymore. You don't have any front-end architecture experience and your JavaScript background is weak." Lesson learned. You may be an architect for a moment, but to maintain that title, you have to continue to learn and grow. If you don't, you may find out you're just a legacy programmer. I'm sure that can be very humbling.
- yitchelle 12y ago
  Good points. For an architect, maintaining your knowledge set is important so that the correct decision is made. However, I think it would be done in a contextual manner. Ie, if you operate in the world where Cobol is main technology driver, would you have to continue to keep up your knowledge?
benjaminwootton 12y ago
It's a bit unfair. It's a job title, a career, and a full time job for a lot of people. Whether or not it's necessary and how architecture should interface with everyone else is open for debate, but it's not really an indication of the persons level of ego.
- tracker1 12y ago
  I've bounced from UX developer, to systems developer, to architect, director and back to senior developer... I'm currently working in an architect/senior developer role... The title is just that.. it associates with a role you play. I'm designing a relatively large system, and making suggestions towards the tools, technology and implementation (as well as doing a lot of said implementing). I can't speak for most... but for me, it's the position I'm in... Of course my role is much closer to that described in TFA... which is what being in a smaller organization calls for. I like solving problems, and developing solutions.
firebones 12y ago
I was getting ready to undergo a surgical procedure once. The doctor looked at my chart and saw I was (by title) a "software architect". He asked me to clarify. I described what the job entailed. He scoffed, "So you're not a REAL architect," as though I were inflating the title my organization had given me. Didn't really give me any reassurance as he wielded the knife.
- kragen 12y ago
  Did you tell him he wasn’t a real doctor because he lacked Ecclesiae declaratio?
- pavlov 12y ago
  Well, your doctor did have a point. In most countries, "architect" is a protected title. Architects are required to register and they must meet very specific requirements. If a hardware repairs guy adopted the title of "Doctor of Computer-Medicine", I think most of us would find it silly. Personally I agree that we should let real architects keep their title rather than muddy it with the confusing baggage of our business.
- icedchai 12y ago
  Hah. It's true. We're not real engineers either.
dwenzek 12y ago
Yes, there is a risk to be boastful. But the risk is shared by many positions and roles. It's not enough to say I'm an architect or a full stack developer or UX designer, there are a lot of skills and attitudes to have along the days to fill plainly the role in a team. It's why, I totally agree the post. To fulfill the architect role, you have to be on a daily basis with the team, to design, develop and debug with them. This is not about being a Rockstar, but yes, this requires some broader and smarter vision on how the whole system is being developed. And this implies responsibilities too and even a bit of humility when things do not go like expected: it is at these difficult times that we can judge whether you deserved the role. Besides, titles have their importance. This is maybe a pity, but, for sure, you don't have the same audience from the management when you are introduced as a software architect rather as a developer. Same thing, when you are looking for a job. I'm a freelance developer with 20 years of experiment and I introduce myself as a software architect even if I'm looking for contracts where I will be plainly involved in development tasks. Each time I failed to do so, I put myself in situation with no chances to use my skills and to help the project at the level I could have. On the contrary, with an architect hat, I have been often welcome with some suspicion ("how can this guy fix the mess we're in?"), but this gave me the opportunity to work effectively with all team members and to truly help them.
- keithnoizu 12y ago
  Nice description. On a side note but related, I really think one of the major difference between a developer versus an architect is having strong grasp of how components can fit together and impact overall costs, quality and timelines for a project even if you aren't familiar with the specific details of those components. For example if you need to design out something highly distributed you don't necessarily need to be proficient in erlang, or scala + akka, or clojure before you start but you do need to understand the pros and cons of each system, the underpinning philosophy on how they work and basic behaviors of the solutions in terms of speed to develop, benchmarks, known scaling problems, trouble spots etc. Sometimes you need to use the right tool for the job even if you don't know the tool yet. Sometimes that means taking a deep dive to get to know the technology, talking to experts on the technology and fitting their feedback into the overall picture of what the system needs to do. Which is a very different skill set then being able to pack as much functionality as possible into an MCU, or improve average performance on an algorithem, or being able to rapidly construct a component. Which is why I advertise myself as architect and not as systems developer, or ux guy or full stack engineer. It's the type of work I enjoy doing, and it's the work that clients get the most bang for their buck out of me for their retainers. It doesn't mean I think I'm a better developer than non architects. In a lot of ways I'm not, but I does mean that I think (rightly or wrongly) that I am often better at sleuthing out the rough behavioral characteristics of components or technologies needed for a project and knowing how to leverage that high level understanding together for designing or improving a project.
keithnoizu 12y ago
Maybe. Although I think there is a distinct mindset difference between someone who is a really good coder versus a really good designer. Personally I refer to myself as a software architect, partially because it's one of my job titles and partially because laying out large multi-component systems comes very naturally to me and is something I seem to be more proficient at than many developers I meet. Meanwhile when it comes to actually sitting down for implementation work I'm just on the average to high-average side of things. Finally when it comes to algorithm design and analysis I'm pretty mediocre. Although, I hope, that is mostly from never having to work in that area very much. I sort of think it boils down to if you are a forest or trees sort of person. Normally I approach writing code as modules, then classes and then methods working my way down to implementation instead of going the other route and starting with methods and building up to classes and modules. So when I sit down to start a new project I normally plug in most of the classes and interfaces first for the sections i'm working on and then implement down from class design to coordinating logic to specific methods (tweaking my interfaces as I go). Meanwhile I know some other developers that take the opposite route and start with low level implementation and work from there up to coordination level stuff. They can't really feel out the big picture until they have a solid grasp on the low level implementation details and I can't really feel out the low level implementation details until I have a good idea of the big picture in my head.

ChicagoDave 12y ago

I've always viewed software architecture the same way start-ups function. If you plan to build frameworks, guidelines, and processes, you should treat those things within your company as a new product or service. Your customers are all of the programmers, some of the business liaison people, and stakeholders of the systems within. If you build a framework and approach your customers for buy-in and they refuse, you've failed. And failure is as simple as having complicated documentation, extended ramp-up periods, or high turnaround in your development teams. Know your customer. Get their buy-in before you complete any big changes. Don't assume your brilliant ideas will be received or successful, no matter how great they may be.

nickbauman 12y ago

Agree, but I would go further. The term "software architecture" is one I actively disdain. Architects build buildings. If there's anything we learned from comparing civil engineering to software development it is that they it is harmful to draw parallels. So while using architectural metaphors is sometimes ok, this term is not. Software design, on the other hand, is something everyone who writes software is involved with. It is not an act reserved to few and disseminated to the "great unwashed coders" like they are some kind of construction crew who just read blueprints while typing the source (another crappy parallel drawn from the same place as the term 'software architecture')

bottled_poe 12y ago
I disagree, but I also agree. I believe software can be planned to near-perfection by one or more architects. If you establish a design, the implementation can be verified, at least to the level of detail defined in the plans. In my experience, the problem is that I find coding to be a bit tedious. Problem-solving is the interesting aspect of software development, and when that gets taken away my productivity drops. I'm sure not all developers feel the same. A great engineer knows their colleagues well enough to delegate effectively.
- kragen 12y ago
  If you first design your software to near-perfection and then find coding it to be tedious because no problems remain to be solved, I recommend that you obtain a thing called a “compiler” to do the coding part for you. You see, a “compiler” takes a formal specification of your design as input, and automatically produces a program as output! I know this sounds like science fiction, but we’ve been using these things for a while now, even though they took a while to get accepted. Alternatively, if you’re already using a compiler, have you considered that maybe you’re doing some things by hand that the compiler could do for you? Modern “high-level languages” (as the design notations compilers accept as input are known) are astonishingly capable of eliminating repetition in the “source code” through the use of “abstractions” and “embedded domain-specific languages”. Of course, there’s always the risk of making your system so abstract that you can’t figure out how to debug it! So you probably don’t want to remove all repetitiveness.

benjaminwootton 12y ago

IT over the last 10 years has been a story of breaking down siloes. Agile development was all about breaking down the wall between IT and the business - getting them collaborating earlier and more often. TDD and test automation are bringing development and test closer together, getting testing involved earlier in the cycle and quality build in. DevOps is bringing the build and run halves of the IT organisation closer together, breaking down that particular silo. All of the other siloes need to go the same way - infrastructure, information security, architecture. Siloes were great for a waterfall world, but when we want to move quickly the whole concept of functions and job titles is too slow and process driven. What I'm trying to say is, yes, I agree with this post whole heartedly.

djcapelis 12y ago
Information security seems like it has especially never worked well as a silo. Without building it in proactively at the beginning and continuing to design with it in mind, software quality wrt security will always suffer badly. Unfortunately the stark reality is that for almost everything, worrying about security means you ship things slower. It's not that people don't know they need to worry about it, it's that every short term incentive exists to shove it aside. And so people have, and do. Security doesn't drive user growth. (It can make people go away eventually. But it almost never drives adoption.) There's a real tension between "move fast and break things" and "break down all the silos".
tracker1 12y ago
While I agree with the post... And most of your comment, I find that a large issue with a lot of "Agile" development, is that not enough thought is put into the architecture and overall design ahead of time. Another big breach is when early on a lot of conveniences are put into place, and the knowledge therein is lost in the ongoing development.
pjmlp 12y ago
From my enterprise seat, most silos are still there and won't go away regardless how much we wish they would. I have seen Agile progress from the new cool thing, requirements for all kinds of agile certifications to the current trend of mini-waterfall sprints. All because it doesn't matter if the IT team wants to be agile if the reaming part of the corporation keeps doing everything the old way.

cies 12y ago

At the place where I work, I've recently described the role of Software Architect. It is a project-role, so only exists in the context of a project, and usually only in the first weeks of a project. We describe it as follows (feedback is very welcome): # What is expected of a Software Architect? * Makes high-level technical design choices. * Records those choices, and the supporting arguments, in a deliverable. * Ensures feasibility of the technical approach (and informs the PM). * Identifies risky aspects of the project (and informs the PM). * Dictates technical standards (e.g.: coding standards, tools, frameworks, platforms). * Provides the team with a "standard way" to develop the software. * Ensures compatibility with Hoppinger's technical road map. * Aligns all his decisions with the resource constraints of the project. * Recognizes "reuse" opportunities (either existing software that can be incorporated, or spin-off contributed/reused). * Observes and understands the broader system environment (of the customer). * Creates architectural overview diagrams and/or descriptions when needed. * Knows which applications are used in the organization. * If possible: subdivide a complex application, during the design phase, into smaller, more manageable pieces. * Understand the functions of each component within the application, and the interactions and dependencies between components. * Communicate the technical design, "architecture", to developers. * When needed also provides hardware requirements (or several options), considering the needs and abilities of the customer.

EtienneK 12y ago
This is pretty much the description of an Architect that the article is arguing against. From my experience, Architects that conform to the above requirements tend to sit in their Ivory Towers and are oblivious to the problems on the ground.
- alphadevx 12y ago
  > ...and are oblivious to the problems on the ground. Should they even care, if it's not their role? Engineers are hired to problem solve, architects are hired to design. Think about an architect designing a building: should he/she know the intricacies of every separate sub-system in the building (plumbing, wiring, ventilation, gas...), or rely on experts in each of those sub-systems to resolve implementation issues? The architect is only concerned with pulling together all of these separate efforts to form something cohesive and elegant.

br3w5 12y ago

It's certainly true that if someone in a an architect position does not know the technologies intimately then how can they make informed decisions about it. They can certainly maintain consistency at a high-level e.g.this next solution will have a REST API, but people still shouldn't be making those decisions without a detailed understanding of the impact of those decisions. I have seen devs move into a pure architect role but as time goes on it does become apparent that they need to be closer to the detail. I think the definition of architecture should be a dev team effort with the architect role making the final decision (be that lead dev, CTO, whatever job title for that person). I like the idea suggested in the thread of making the architect a product team/project role.

ukigumo 12y ago
An architect, at least one worth his title, does not work in isolation. The article talks about a type of architect that I call tech lead. It has as much to do with the architecture process as a front-end developer has to do with mechanical engineering. There are many types of architect, with vastly different roles and functions within an organisation from pre-sales to business strategy so I strongly argue that people should stop looking to become architects as a step up from being engineers in the same way that fashion models should stop looking at picking up acting as some sort of a graduation when when they get too old for the catwalk. Some can do it because they have picked up enough knowledge and insight along the way but, for most, it's a new career with a whole new set of skills and responsibilities.
- br3w5 12y ago
  An architect needs to keep learning in much the same way as developers do. I would look to this person to make the decision on the high-level system design/architecture for each solution. I think they should also be pushing the dev team to look at new tools and technologies, and it would really help if they had some understanding of those technologies. I think there is a similar debate (but from a different angle) around should your project manager or scrum master be technical. Obviously an architect should be technical but how much familiarity should they have with the technologies being implemented. I would say they should have a good understanding of them. There is some benefit to being conceptually removed from low-level technology concerns, in that the architect won't get caught up in design patterns intrinsic in the technologies the devs want to use, that could actually be detrimental to the overall design - the old 'the devs can't see the wood for the trees' argument.

alphadevx 12y ago

> One risk of the integrated architect model is that an architect can get preoccupied by implementation. Nailed it. In the same way that ex-engineers often struggle to let go of the code when they switch into management, I've seen the same thing happen to those switching to architect roles. They find it hard to step back and trust others to take care of the implementation, and this often leads to the worse kind of micro-management tendencies manifesting early on in this transition period. The best architect I ever worked with was a terrible programmer (by his own admission, and I can confirm because I worked on fixing his code). But he was able to bring to bare tremendous technical improvements on any project he worked on. It's a different mindset, more focused on the design of the implementation rather than the actualization, and it's really not suited for every ex-engineer (just like management).

dingaling 12y ago

> In the same way that ex-engineers often struggle to let go of the code when they switch into management, I've seen the same thing happen to those switching to architect roles It's not always a choice; where I worked, as architects we sometimes had to put on our hero-capes and wade into code to save the day. Saying "that's an implementation issue" doesn't work when the implementers don't have the savvy to make it work. Or, worse, throw up their hands and say it's impossible because of the unreasonable demands of those ivory-tower architects . Can't we just save the credit card details to a local database instead of all that integration stuff? At the end of the project, if it works it's despite the architects and if it fails it's due to the architects... always in the spotlight but never in the limelight.

harkyns_castle 12y ago
> It's not always a choice; where I worked, as architects we sometimes had to put on our hero-capes and wade into code to save the day. I think its a matter of context, and one "architect" from one organisation to another will differ greatly. I've never seen a good "hands-off" architect in my experience. They've normally been the failed developers, or the ones that have been able to network to such an extent they get to a hands-off role. But, that's in context. Dilbertian almost.
- crdoconnor 12y ago
  >I've never seen a good "hands-off" architect in my experience. Because when it's done right, coding is 80% "architecting" stuff. If there is more than a tiny amount of menial work involved in programming then you are generally doing something very wrong. I think architect is one of the worst metaphors to ever grace the software engineering profession, by giving this impression that a programmer who can work "hands off" is even possible.
  - harkyns_castle 12y ago
    Couldn't have said it better myself, a really well said point or series of points.
  - 12y ago

snarfy 12y ago

We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn't matter if we had them. The business believes iterating on the business plan and direction is agile development, the result being a code base full of dead ends and code that should be refactored or deleted, but can't because it will take a non-trivial effort to do so since data is already deployed to production. If we ever do take the time to clean up, that's a sprint the business doesn't get any backlog items, so those sprints are few and far between.

keithnoizu 12y ago
Someone probably should have architected out that release pipeline and planned for scheme version control and a more efficient data migration process. ;)
antris 12y ago
Doesn't sound like agile development to me. In Agile development you usually refactor as you go. Refactoring is not a separate task, it's part of the process. http://www.extremeprogramming.org/rules/refactor.html http://www.extremeprogramming.org/rules/refactor.html http://c2.com/cgi/wiki?WhatIsRefactoring http://c2.com/cgi/wiki?WhatIsRefactoring
ExpiredLink 12y ago
> The business believes iterating on the business plan and direction is agile development The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored.
- antris 12y ago
  > The perils of Agile. You are only allowed to do what you stakeholders understand. The rest is ignored. Sounds like quite a passive aggressive way to solve a communication problem. "You only said we needed feature X, you didn't tell us not to mess up our codebase during the process". It's not the stakeholders responsibility to tell you how to do your job. You don't wear clothes at work because it's in the backlog, you do it because it would be unprofessional not to. Even when stakeholders have asked me to take shortcuts, they usually seem very level-headed about it once you start the dialog. I've talked to stakeholders proactively about tradeoffs of taking shortcuts and they seem to understand when I compare "not refactoring" with "making a mess". In my experience, people understand what messes are. If we make a mess, it will slow us down as long as it is there. We can clean it up later, too, but it will cost us more because it is slowing us for a longer time. Taking shortcuts without telling stakeholders is unprofessional. If the stakeholders don't explicitly tell you to not refactor, refactoring is implied.

keithnoizu 12y ago

I think the arguments for or against keeping full time architects on staff versus having developers who also work together to design out systems are the same the argument for or against separating out internal systems and test automation from regular developer roles. For example googles SET, STE & Engineer roles. Personally I like more integrated teams and believe a good architect should be down in the mud writing code half the time in-between designing things out. Partially because technology keeps changing and you need to keep an eye on developments and partially because it's a shame to waste that big picture understanding when tacking debugging or designing out specific components, and partially because it's important to keep an eye on cod equality. I've done the architecture thing both ways however, throwing design notes over the fence versus designing and helping with implementation, and honestly they both have their pros and cons. Tighter integration reduces communication problems and wasted effort. On the flips side having individuals focus on producing what they produce best can be more efficient then forcing team members to wear multiple hats. For the same reason why a country much better at growing expensive widgets and slightly better at growing gaskets than another country should focus their production efforts on widgets while the other country focuses their production efforts on gaskets. The major problem in my own humble opinion with the separating out the architecture discipline is that once you step away from the code you're basically kicking off a countdown to the point where your understandings of the technologies involved and current practices and tools doesn't match up with reality. Which impacts your quality as an architect. You can say similar things about technical project managers, general managers and ctos who no longer code,

tootie 12y ago

There's a comment on that post that I 100% agree with. The architect is responsible for the architecture (among other things) but that doesn't mean she's doing all the work. It's a team effort. The artchitect is just the one who is responsible for the final deliverable. Same with every role. It's defined by it's responsibility, not necessarily by the work being done.

kitd 12y ago

I don't like the term Software Architect. I think having an architect for software alone is redundant. That's part of the job of coding. Where I believe there is value is in having a System Architect, who will take a wider view of the system as a whole, especially wrt the users and how they will use it, plus all the add-on mechanisms required to install/maintain/backup a production system.

exelius 12y ago

But here's the thing - dedicated architects often aren't just focused on software. The same architecture patterns you use for building software are just as applicable to business processes or organizational design. Architecture as a function has been consolidated to ensure effectiveness across all parts of the business, not just software development (which is why it's often called enterprise architecture or solution architecture). A good architect should work WITH the software experts to determine the optimal architecture, but sometimes the business needs will require an architecture that is less optimal than it would be in a vacuum. In organizations large enough to require a dedicated architecture function, software developers are poorly positioned to understand the various requirements of the architecture.

codingdave 12y ago
If an organization has grown so large that software developers do not understand the larger business and organizational requirements, then that organization has already gone too far down the path of compartmentalizing their teams, at least in terms of job satisfaction and career growth for the devs. When I worked in medium sized organizations (4000 employees, etc), we did have devs who did not understand the business, but they were outsourced contractors. Every actual employee knew the broader picture of their own applications. Those of us who worked on platforms that pervaded the enterprise did have enough knowledge to make architectural decisions. We also knew enough to pull in other people when a decision stepped outside our area. After a few years, a new CIO did form an enterprise architecture group, and hired a new guy to be the "enterprise architect". We were told that software devs need not apply. Morale died, projects started to go very badly, and within 2 years everyone had quit. So while there may be organizations that really do need a separate enterprise architect, I'm pretty much on board with the article, and feel that those places are likely to be quite craptastic places to work.
- exelius 12y ago
  I agree - they're not the kinds of places that engineers who love working in a startup would enjoy. But if you're going to scale as a company past a certain size, you have to centralize these functions, which is why large enterprises are such a pain in the ass to work for. If you don't centralize the architecture functions, you start to get multiple independent groups building the same things because the communication is too hard to manage across a big organization. Enterprise architecture is a totally different skill set from software development - it requires a business mindset, not a technical one. It's really more a requirements gathering job than a development one, and it wouldn't be enjoyable to most developers anyway. It's one of the inflection points that growing companies have to deal with - the people who built the company may not be right to maintain it going forward. The job becomes more corporate and less fun, and growing companies often see a lot of turnover during these times. But some people will stay on, as job security to support a growing family becomes more important to a developer than fun projects or the content of their work.

hacknat 12y ago

This might be controversial, but if you want a good example of a code base where this is painfully obvious look at Android, especially the UI components. There are interfaces for everyyyyything. So many of the UI components are unnecessarily internal, which can be a pain in the butt if you want to do something just slightly different than default (you obviously can't inherit form an interface, so you end up copying the code). A lot of the cruft is probably from trying to make Java work, but when I read through the code I find myself wondering why it was implemented the way it was implemented and the only explanation I've been able to come up with is the one described in this post.

rifung 12y ago
I completely agree. I find the Android APIs absolutely appalling. My former coworker knows both iOS and Android, having done Android for many years, and he refuses to program for Android ever again. He would also tell me that the time it takes to implement things in Android is usually 1.5x - 2x longer than the equivalent thing on iOS