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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
> 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.
> 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.
>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.
>>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.
Or, even worse, "designing" everything in UML diagrams and then throwing it over a wall to "just be coded up" and then running away.
Edit: Just to be clear - it's the "just coding" attitude and particularly the avoidance of actually mucking in and getting stuff to work that is the real problem with this approach. Mind you - I do hate UML, but that is personal!
The problem is people want to feel special. It's not enough to say you're a Computer Programmer. Instead you have to be a Software Engineer. And once that bores you, you start calling yourself an Architect.
I have an actual engineering degree. Call me what you want to call me, but at the end of the day, I'm a computer programmer. And darn proud to be one.
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.
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.
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.
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.
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.
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,
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).
If you assume these are only needed in the first weeks of a project then it sounds like the classic waterfall fallacy. Preserving architectural consistency and evolving tech choices and adapting dev processes is a continuous process as a project grows and its easy to generate waste by front-loading too much of this.
My feedback on the list is that some of these qualities like handling risk, reuse, company/customer knowledge etc. should be expected of all senior devs. Other items like decision making, design diagrams, identifying standards etc. should be treated as tasks just like design, development and testing. They will regularly arise during a project and can be delegated across the team.
I would consolidate governance in the lead dev role - they are where the buck stops for all decisions, quality, consistency, delivery etc. but they do this by leading a team and delegating unlike an architect role that ring-fences categories of task for themselves.
Good points. We usually prefer to keep the lead developer responsible for all the project's architecture needs. This is more of a role in case the lead is not able to --from early on-- oversee the technical complexity of the project.
I think you are missing some key aspects of the architect role in that you don't mention requirements (apart from hardware requirements which are always funny coming from a developer...) and you only point the communication towards peers but not clients and business partners.
The architecture process can be summed up along these lines:
- Identify stakeholders, their concerns and objective. Translate these into goals and requirements;
- Understanding, validating and designing the requirements;
- Identifying possible solutions but also constraints, risks and assumptions. Document and validate them;
- Document decisions and solutions with blueprints and design documents (diagrams, tables, natural text, etc) that are actionable and can be used as reference material;
- Limit the scope of the development activity to the requirements in order of relevance (to the sprint, or other time-bound metric);
Behalve dat, goed geddan jonge!
(edited for clarity)
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.
> ...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.
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).
"Problems on the ground" can include things like how much sun the location gets, which direction it comes from, how cold the place is in winter and how many feet of snow it averages. An architect who ignores all these local details will be lucky to design a building that lasts a year.
>This is pretty much the description of an Architect that the article is arguing against.
I didn't get that at all. I imagined an architect described by that text as a role that one (or more) of the engineers takes on during a project to ensure its success.
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')
I agree and I also wouldn't call most of what software developers do "engineering" either. There are so many people with "engineer" in their titles who really just develop applications and websites. What ever happened to "Software Developer" or "Programmer" as titles? They are much more appropriate, but I guess they don't sound high-falutin' enough.
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.
>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).
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.
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.
Blueprints can be analyzed to verify the design correctness from an engineering perspective. That a bridge depicted will hold so much weight, for example. UML has no such utility. This is another bad parallel being made between civil engineering and software. Give it up.
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.
> 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).
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.
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.
Sounds like an "eternally vaporware startup" to me. I've worked for one of those before. The work can be interesting at times as you feel the need to do something nobody else has done before. But then it never gets anywhere because the whole premise is based on things that are fundamentally unsound/impossible. My experience is then you get your pay cut by the CEO because you're not producing anything "of value", and then you get sued by the investors for the same reason (okay I've got my name on provisional patents that aren't based on reality, but I refuse to give them up after I quit, probably mostly out of spite). Still, I say get out while (if) you still can, and move on to better things.
> 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.
Of course they want it as fast as possible. But they also want the code to not slow the team down later on. And they want a cure for cancer, eternal happiness and world peace too.
My point is that people say and want all kinds of things, but when you engage in dialog about tradeoffs, they usually understand what refactoring is and how it affects long-term development speed.
Someone probably should have architected out that release pipeline and planned for scheme version control and a more efficient data migration process. ;)
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.
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.
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.
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.
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.
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.
>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 find the quality of decisions made by a single person in this role are never as good as decisions made by team consensus.
Architecting is by its nature a job that often requires subtle and delicate trade offs, and the more you concentrate the role in one person, the less experience you have to draw upon to make those trade offs.
I find that giving somebody authority to make the final call when there is still team disagreement is something of a false economy, too. The whole idea that discussion should be minimized for 'cost reasons' is how a lot of fantastically expensive bad decisions get made.
Yes but the reality of decisions is that one person needs to drive that decision - a group of people will often struggle to make a clear decision every time
I've had "architect" in my job title for ~15 years and I'm very clear that my job is not to make the key technical decisions, but to facilitate the process for making these decisions.
Agreed. An architect should be a knowledgeable generalist able to facilitate the discussion. Personally I'd hate to be the "smartest guy" in the team about anything.
However I spend a large part of my work days collaborating with all different stakeholders and different subsystem vendors and what I as an architect bring to the table is the requirements based on the context of the subsystem we work on. Rest of my days I design, code and debug just like the rest of the team.
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.
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
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.