I was recently appointed as the leader of a newly formed architecture team (most similar to systems or enterprise architecture, not explicitly software architecture). My company is medium sized, and there are ~8 different engineering groups each with their own stacks, and their own culture. As part of this re-org, many of those groups are going to be consolidated and part of my team's job is to figure out how to bring their stacks into alignment. In thinking about the new team's charter, we've struggled with:
- How should the architecture team engage and interact with the engineering teams without stepping on toes, while remaining effective? When should architecture stand back and let engineering do its thing?
- (related to the above) When is it appropriate for the architecture team to build something versus when should the architecture team provide guidance, and allow the engineering team to build it themselves?
- How can an organization measure the success of an architecture group? None of the goals of architecture seem easily quantifiable.
As an example: Should the architecture team be involved with setting coding standards? Theoretically, this is something that the engineers use day to day, and could be set by engineering leadership, but it could also be tied to architectural needs. For example, if architecture defines the directory structure of a standard project, and how the build should be set up to fit within the CI that they've mandated, shouldn't they also have a say in the documentation and coding standards in order to be consistent with their directory structure. Maybe this is an inelegant example, but I think it illustrates our line of thinking.
Another example: It is determined that we need a new key/value store to support the needs of a particular project, but it is not clear that the requirements of that project will ever be felt in future projects -- everyone else has a k/v store that works just fine. Clearly architecture will be involved in the decision of which technology to use (and vet whether a new technology is, in fact, really needed), but should the architecture team be charged with building the infrastructure for the new tech? If it is not likely (we all know that means VERY LIKELY) that it will be re-used in different projects, it seems like the answer should be "no", but given the parenthetical above, I'm inclined towards "yes". Should architecture be involved in project-level tech decisions, and to what level should they be involved?
My initial thoughts:
- The architecture team prototypes the new technologies/systems that it espouses and then transitions to relevant teams.
- By and large, architecture tries to avoid getting involved with project-level problems (it isn't "you should use this new charting package that we think is cool", it is "we are trying to get everyone onto this uniform front-end framework, you need to use it").
- Form an architecture committee that includes engineers and business leaders to make sure engineers are part of the decision making process.
- Architecture must stay tightly linked to business needs and goals without stepping on Product's toes. A core responsibility of architecture is to inform the business of un(der)utilized tech that offers potential upside.
- Architecture should ultimately make the lives of engineers better. Our main goal should be to solve problems once, so that they don't get solved many times, which means that engineers will have more time to work on 'the fun stuff'.
Sorry to be so long winded. I'd love any feedback, especially from those who have worked at organizations with impactful and effective architecture teams.
