Software Architect – A Role, Not a Job
spin.atomicobject.com
spin.atomicobject.com
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.
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.
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 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.
Didn't really give me any reassurance as he wielded the knife.
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 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.
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.
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.
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.
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".
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.
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.
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.
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.
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!
Code or GTFO.
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.
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."
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.
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.
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.
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.
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.
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,
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.
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.
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.
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).
* regular developers, yet senior
* work on/with teams (not part of a separate architects team)
Though I feel you do hit the point where the description could be written more in terms of "creates buy-in" and "raises awareness".
Thanks for the feedback!
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.
usually only in the first weeks of a project
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.
Hope that helps!
Thanks!
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)
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 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.
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.
Your snark should be turned inward.
^^^
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).
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.
And ships, etc. Architect is much broader than making buildings. It is about building a system.
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.
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).
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.
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.
With enough communication any result can be a visible one because everybody understands why it is important.
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.
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.
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.
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 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 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.
And it's better that way - especially when people speak up about issues that they personally feel invested in or passionate about.
This has been my experience, anyway.
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.
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.
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