4 ms·

Ask HN: Does your company have a software architecture team? What do they do?

• relaunched 5y ago
  Practically, software architecture is about making certain you have as few tools as possible, to do a job, with the flexibility to accommodate other tools, when necessary. Documenting standards, exceptions, rationales and the alignment of the parties that hold an interest in the decisions is also a benefit of architecture. What that looks like, practically speaking, varies from company to company. However, you do have to achieve a significant level of size and complexity for this function to make sense. If you're saying that architecture, in some form, doesn't make sense in an organization, I'd challenge whether the size or complexity of that organization has reached the threshold.
  • swquinn 5y ago
    Yeah, that's a really good point. There is no "one-size fits all solution" to how an architecture team should be composed (if it should exist at all for a company) nor is there an easy answer for how it should operate. I really like this though: > software architecture is about making certain you have as few tools as possible, to do a job, with the flexibility to accommodate other tools, when necessary. This really resonates--one thing I've noticed is a growing complexity of like-systems and finding ways to reduce unnecessary complexity seems like it could be very beneficial for any organization.
    • quantified 5y ago
      Perhaps another slant that has long seemed apt: choosing the dependencies and steering the organization of the software and its stack. Minimizing the dependencies to those strictly necessary, treating as many as plausible as an implementation detail, and judiciously leveraging the strategic ones, all flow from that.
      • relaunched 5y ago
        if you are thinking in terms of dependencies and a singular "stack", the organization is probably not complex enough for architecture as a function. When you are running 5 different types of messaging queues, including 2 that were grown in-house, you need architecture.
    • relaunched 5y ago
      Thanks!
• aynyc 5y ago
  We are a mid-size company and we have a strong architecture team. We generally are advisors rather than deciders, but we can raise issues to senior management quickly if we see decisions that are directly against stated goals of the technology group. We have a lot of business units and each unit is served by a team or teams of engineers. I can't imagine how we can have a cohesive strategy and execute it without architects. If your company doesn't have that complexity, I don't see why you would need architects.
  • swquinn 5y ago
    We have several business organizations, oriented around different product offerings in the same service. So there is an organizational complexity that I think might lend itself to the architecture team being involved in contributing to, supporting, and executing a cohesive strategy across those products and organizations is another area where I've wanted to see us more involved. Unfortunately, it has been somewhat difficult positioning ourselves into a role where we can be proactive and lead rather than simply reactionary.
    • aynyc 5y ago
      In our org, architects are assigned to team(s) in a support role. It's up the architect on how their relationship works with the team(s), their reviews are based on that relationships. In our org, we are not 10X engineers who got promoted into those positions. Rather, our focus is to drive the overall strategy and help team(s) deliver their product. Some of the responsibilities I've worked on: 1. Help teams design new systems and manage backlogs. This suck up bulk of my time. 2. Help my business org to get new and more exciting or sexy work, such as event streaming, ML/AI and potentially blockchain adoption. Senior director of my business org loves me because I make him look good. 3. Cheerleader and promoter of the team(s). For example: * I run high-profile spotlight meetings to show case my team(s)' work to upper management and across the organization * I develop and run entire business unit developera round table for usually very silo'ed teams to talk and ask questions, as well as gather information on their general approach to their problems. 4. R&D research; third-party vendors evaluation, negotiation and management 5. Business cases for budgets, and development plan for the engineers. During Q4, this would get about 50% of my time. Architecture team needs support from upper management. Its role should be well-defined and understood, as well as accepted. My philosophy is that, I lead by serving the teams to achieve its goal. In my current position, I still have a team or two that disregard my advice. The rest are all on-board with me because they know I'm here to help them to do their jobs better.
• dyingkneepad 5y ago
  We have SW Architects. Here is what I've seen: John Smith is a great engineer. He does absolutely amazing work and is able to move up the company ladder. He interacts with many teams, has a lot of influence and so has great impact in the company. Eventually he gets promoted to the Architecture team. Once he reaches there, he can 100% focus on putting his great experience to maximize his influence and solve high-level problems. He even has regular 1:1 meetings with some powerful VPs. The problem is: since John is now part of the Architecture team, he is not really involved in the front line anymore. There's a chance he doesn't even get to write code anymore, all he does is tell people what and how to code, and sometimes he reviews patches. He has that code assignment that he has been trying to finish for a long time, but the higher-priority Architecture Team work is preventing him from putting that time in. He'll probably have to delegate it to the new employee James Jones. Over the course of the next few years John Smith starts getting more and more out of touch with reality. His ideas start making less sense, some of his suggestions simply don't work because of how we reworked the entire locking infrastructure last year. He doesn't know how to interact with new CI system so he gets misses some important things. John was recently asked to do a tech review on a certain new feature, but he's not up-to-date with the code since that new mega-feature so he put James Jones to do the actual review for him. All our devs are criticizing John Smith for only having impossible or obsolete ideas, being a stupid proxy architect that does nothing useful to the company. How the hell can he get away with such a huge salary, given he's so incompetent? Did he have to do sexual favors to someone to reach that position? But James Jones is such a great engineer, we should put him on the Architecture track since I'm sure he will be able to fulfill some of the gaps we have there! Unfortunately there are too many architects already, so we're going to have to wait someone to retire or quit, since no architects ever get fired, all the VPs love them.
  • swquinn 5y ago
    Interesting. The above is similar to what I've seen and experienced personally. One of the reasons I was able to move into my role was because of my technical experience but every member of our team has the same concern: the further away from the code we get the less effective we'll be at providing architectural advice for the systems as they evolve. It really is a bit of a catch 22. Instead we've begun talking about focusing on ways we can support the technical strategy as well as the business strategy more.
• nunez 5y ago
  I've worked with several engineering architecture and software architecture teams. The "old" architecture model is very top-down: architects (who were software devs/sysadmins a long time ago and haven't pushed a commit in >6mo) push top-down designs for large-scale systems that engineers (usually outsourced or entry-level) implement. This model works when most of the "doers" are entry-level but comes with a huge "you don't know what you don't know" disadvantage. It is very easy to read RFCs and docs for protocols and languages (repsectively) and surmise how things should work, but it's a whole other ball game when you _actually have to make them work_. The "new" model that I've seen come up is closer to internal consulting than "ivory tower." In the new model, architects (who are very much software and/or systems engineers) are "assigned" to teams to help them achieve a particular mission, like migrating them onto a corporate build and release framework or helping them release their greenfield application into "Production". They will either pair with engineers during these missions or they will take items directly from their backlog (at a lower velocity than the devs on the team, of course) and push commits themselves. I much prefer the "new" model to the "old" model.