Software Architect – A Role, Not a Job

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

IT over the last 10 years has been a story of breaking down siloes.<p>Agile development was all about breaking down the wall between IT and the business - getting them collaborating earlier and more often.<p>TDD and test automation are bringing development and test closer together, getting testing involved earlier in the cycle and quality build in.<p>DevOps is bringing the build and run halves of the IT organisation closer together, breaking down that particular silo.<p>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.<p>What I&#x27;m trying to say is, yes, I agree with this post whole heartedly.

&gt; In the same way that ex-engineers often struggle to let go of the code when they switch into management, I&#x27;ve seen the same thing happen to those switching to architect roles<p>It&#x27;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.<p>Saying &quot;that&#x27;s an implementation issue&quot; doesn&#x27;t work when the implementers don&#x27;t have the savvy to make it work. Or, worse, throw up their hands and say it&#x27;s impossible because of the unreasonable demands of those ivory-tower architects . <i>Can&#x27;t we just save the credit card details to a local database instead of all that integration stuff?</i><p>At the end of the project, if it works it&#x27;s despite the architects and if it fails it&#x27;s due to the architects... always in the spotlight but never in the limelight.

But here&#x27;s the thing - dedicated architects often aren&#x27;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&#x27;s often called enterprise architecture or solution architecture).<p>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.

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 &amp; Engineer roles.<p>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&#x27;s a shame to waste that big picture understanding when tacking debugging or designing out specific components, and partially because it&#x27;s important to keep an eye on cod equality.<p>I&#x27;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.<p>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.<p>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&#x27;re basically kicking off a countdown to the point where your understandings of the technologies involved and current practices and tools doesn&#x27;t match up with reality. Which impacts your quality as an architect.<p>You can say similar things about technical project managers, general managers and ctos who no longer code,

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

Agree, but I would go further. The term &quot;software architecture&quot; is one I actively disdain. Architects build buildings. If there&#x27;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.<p>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 &quot;great unwashed coders&quot; 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 &#x27;software architecture&#x27;)

I don&#x27;t like the term Software Architect. I think having an architect for software alone is redundant. That&#x27;s part of the job of coding.<p>Where I believe there <i>is</i> value is in having a <i>System</i> 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&#x2F;maintain&#x2F;backup a production system.

&gt; One risk of the integrated architect model is that an architect can get preoccupied by implementation.<p>Nailed it. In the same way that ex-engineers often struggle to let go of the code when they switch into management, I&#x27;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.<p>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&#x27;s a different mindset, more focused on the design of the implementation rather than the actualization, and it&#x27;s really not suited for every ex-engineer (just like management).

We have no architects. Everything is design-by-committee, and the design is horrible. It wouldn&#x27;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&#x27;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&#x27;s a sprint the business doesn&#x27;t get any backlog items, so those sprints are few and far between.

I&#x27;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.<p>If you build a framework and approach your customers for buy-in and they refuse, you&#x27;ve failed. And failure is as simple as having complicated documentation, extended ramp-up periods, or high turnaround in your development teams.<p>Know your customer. Get their buy-in before you complete any big changes. Don&#x27;t assume your brilliant ideas will be received or successful, no matter how great they may be.

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

It&#x27;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.<p>They can certainly maintain consistency at a high-level e.g.this next solution will have a REST API, but people still shouldn&#x27;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.<p>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).<p>I like the idea suggested in the thread of making the architect a product team&#x2F;project role.

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.<p>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&#x27;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&#x27;ve been able to come up with is the one described in this post.