
Software Architect – A Role, Not a Job - davidkellis
http://spin.atomicobject.com/2015/02/19/software-architect-role/
======
rdtsc
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.

~~~
firebones
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.

~~~
pavlov
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.

------
benjaminwootton
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
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".

------
dingaling
> 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
> 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
>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.

~~~
eludwig
>>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 both agree and disagree with this, or it may be that the statement is vague
(or that I just don't understand it).

I have seen horrible "analysis paralysis" at most of the big financial
institution where I have worked - especially the ones with a separate
"architect" job. Hundreds of UML diagrams that were worse than none.

For myself, I actually _understand_ problems better by coding them. I can't
always say exactly how something will work until I _do_ it. Once I have
general idea defined, I just start coding it!

This is not to say that I sometimes don't put pencil to paper to help me think
it through, but I would say I spend _far, far_ more time coding than thinking.
In fact, for me, coding _is_ thinking. Yes, there is rewriting and throwing
away and revising and tightening that inevitably happens. I work more like a
writer, I suppose.

This may not be everyone's cup of tea, but it's how I work. There is a balance
to these things and it's up to everyone to figure out where they fall.

~~~
crdoconnor
This sounds more or less exactly like what I wrote. What part did you disagree
with?

~~~
eludwig
I may have read it wrong.

I would have said: "Because when it's done right, 80% of "architecting" stuff
_is_ coding."

If that is spirit of what you are saying, then I got it backwards! (apologies)

Edit: I think I see the problem. There is an "of" missing. "Because when it's
done right, coding is 80% _OF_ "architecting" stuff."

------
exelius
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
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
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.

~~~
Retric
A large part of why different teams end up building the same thing is it's not
actually the same thing. The details are frequently different is subtle but
important ways.

Often building a single piece of software to assist 4 teams is several times
more difficult than simply rewriting that code for each of the teams. Sure,
that’s not always true, but for such generic needs you can generally use or
start an open source project.

IMO, the best of both worlds is to have an architecture team that approves
designs created by a developer team. Ego often gets in the way, but the
advantage is ‘Architects’ can keep track of wider segments of the organization
when you treat them more like building inspectors than building Architects.
With the added advantage that they can help teams cross pollinate vs. trying
to come up with an ideal design in a vacuum.

~~~
exelius
Totally agree -- but the job function of the architect is different than that
of a developer. Usually the architects are more concerned about architecture
patterns and intercompatibility, i.e. making sure everyone is using the same
messaging bus, same primary keys, etc. Hence my comment that architects should
really be defining some base technical requirements, but leave most of the
internal implementation details up to the dev groups.

------
keithnoizu
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,

------
cies
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
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
> ...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.

~~~
xorcist
Not many buildings would stand upright if what you said was true.

An architect absolutely needs to be on top of the technical implementation of
both ventilation, fire systems and plumbing. They won't be the ones who
installs them those things are taken into consideration when the plans come
together. If you think an architect only dreams up what it should look like
and then leave the project you are mistaken.

With that said, I think a building architect is a terrible metaphor for what's
done in software engineering for plenty of other reasons.

And yes, you absolutely need to have intimate details of how the coherency
protocol works if you are the software architect of a clustered system, just
to take an example. In the opposite direction lies disaster (which I've seen
first hand).

------
nickbauman
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
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.

~~~
crdoconnor
>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.

^^^

I'm sorry to say that this presumption right here is responsible for an awful
lot of the terrible code I've seen.

Doing architecture isn't like solving an equation.

Architectural decisions are nearly always trade offs and the worst trade offs
are made by people who believe that there is a Perfect Answer to problems that
have no one one right answer. They have a tendency to get religious about
approaches, technologies, languages, etc. (sometimes even text editors and
where to put the braces).

~~~
bottled_poe
Perhaps near-perfection was a poor choice of language. My point was that a
software architect could design a complete solution without writing any code,
and be very confident that it will work as required when implemented. In many
organisations waterfall is too expensive/slow, and often an early iteration is
more important than a robust implementation. But the waterfall methodology is
still the only option for mission-critical applications. And these systems are
best designed by experienced software architects before any code gets written.

I'm not saying that the architect's involvement should end after design. They
are critical to communicating the design to anyone involved with the
implementation phase.

------
kitd
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.

------
alphadevx
> 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).

------
snarfy
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.

~~~
ExpiredLink
> _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
> 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.

~~~
ExpiredLink
What do you expect from a method that is based on _visible results_ for _short
term_ iterations (a.k.a. sprints)?

~~~
bgilroy26
Hardly anything in software is literally visible. Wouldn't visibility be an
analogy for clear and tangible?

With enough communication any result can be a visible one because everybody
understands why it is important.

------
ChicagoDave
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.

------
tootie
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.

------
br3w5
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
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
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.

~~~
ukigumo
A technology architect should be technical and be able to keep himself on top
of new developments in his area (software, networks, storage, etc) as well as
having a good solid understanding of the adjacent or related areas. The focus
is how newer and greater things fit together into the big picture.

A solutions architect looks over the fitness for purpose and is accountable
for the delivery at project level which means that he might have to make
decisions (together with his stakeholders) about which technology, framework
or methodology to be employed in order to ensure the deliverables are mapped
to the requirements with minimal or no slippage. The focus is business
benefits from technology.

An enterprise architect is a whole different beast and I'm not even going to
go there at this stage. I'll just say that being technical is as useful as
being tall in that it makes for a good first impression but does not correlate
to quality or effectiveness overall.

I am of the opinion that everyone involved in IT should have a good
understanding of the past, present and future of technology as well as a
systems thinking capability that allows one to understand how different
systems interact and react to his own area of expertise. The balance of
knowing how to do it and why do we do it is the difference between slave labor
and expert work.

------
hacknat
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
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

