4 ms·

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 appl

by exelius 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.

by exelius 12y ago

codingdave 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.