3 ms·

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 siz

by 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

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.