Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. 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?
  2. (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?
  3. 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.

share|improve this question

closed as not a real question by Jim G., gnat, Walter, mattnz, Dynamic Jan 7 '13 at 1:18

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Here is a counter-example, how do be unsuccessful: joelonsoftware.com/articles/fog0000000018.html (and follow-ups joelonsoftware.com/items/2005/10/21.html, joelonsoftware.com/items/2008/05/01.html) –  Doc Brown Jan 6 '13 at 21:28
    
I'd be interested in hearing whether or not others think that an architecture team is useful as well as what role it should take. In my view it sounds unnecessary, I would have thought that all of the developers should be capable of designing an architecture. –  Stu Jan 6 '13 at 22:21
2  
There are several constructive questions embedded in this one. Please consider splitting this up, because I'd like each question to receive the attention that it deserves. –  Jim G. Jan 6 '13 at 23:10
1  
@Jim has it right, hence my down vote. Seems your team is performing many functions, or does not now what it is performing. Architecture implies setting a high level product design, but you also seem to be delving into the an organizational SDLC, and performing the function of the CTO as well. The fact you cannot define a way to measure you success, indicates you have no clear mandate of what you need to achieve, let a lone how to do that..... –  mattnz Jan 7 '13 at 1:18
    
Do not try to set global coding standards if technology stacks are all different. Variable names, patterns, etc are dependent on languages and frameworks. If I'm coding C++ with libraries that_all_look_like_this then my classes won't be namedLikeThat and vice-versa. –  MrFox Jan 7 '13 at 18:11

2 Answers 2

I think you are doing it completely wrong. Trying to build an "architecture", that is separate from the project itself is perfect recipe for disaster, as noted in the comment.

I would start "librarising" common code across the projects. You will simply create a project, with it's own development team and requirements and quality management. I would take example from open-source projects, where everyone from the company can submit a patch and people tasked with maintaining this library would review and accept/deny this patch. I would also make sure, that specific people would go across codebase of all projects withing a company and determine code, that could be "librarised" in this way.

Then I would forget about having team "prototype" a technology. If some team needs or wants to use new technology, then let them. But make sure that every developer has at least some idea what other teams are using or doing. So when other team wants to use new technology, so they know that it is already used in some other team so they don't have to reinvent the wheel. This can be achieved in many ways. Public (to the company) documentation of all projects is good start. Same with common cross-team discussions and workshops. You can also implement people rotation. Simply every half a year, take few people from each team and move them to different team. This will normalize knowledge across company and will give developers better ideas what is whole company doing.

share|improve this answer
    
I completely agree with the librariZation (in the US) approach -- I definitely think that is step one. I also agree with the idea of letting devs use whatever tech they want...to a point. I think it is quite common for teams to do something quick/dirty because of resource constraints or lack of foresight. I'm not in any way advocating for a SOA, but I can see the arch team offering resources and support in cases where the dev team doesn't want to or cannot "do it right". I suppose the challenge is in identifying the right opportunities to offer that support. –  user1038402 Jan 6 '13 at 22:59

The architecture team should provide a technical foundation and guidance so that the team can deliver successfully. How they achieve that depends on the project...

Whatever you do, have the final goal in mind. Also, whenever you take decisions like "Form an architecture committee" ask yourself "how is that going to take you the goal faster/safer?".

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.