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 am the architect for my group. Unfortunately I was given this position organically and there are no standards in place for how I should do my job. At different companies, how does the architect role work?

I am very interested, for example, in what type of diagrams and documents an architect might provide so that they can assist a developer in doing their job.

share|improve this question
    
Were you ever a devloper? –  JeffO Sep 11 '11 at 0:10
2  
there's only two requirements: (1) be right, (2) be humble. –  Steven A. Lowe Sep 11 '11 at 4:12

2 Answers 2

Before you read my answer, please consider that the term software architect means different things to different people. I'll just share my point of view, as I understand the architect role.

Unfortunately I was given this position organically and there are no standards in place for how I should do my job.

Well, that's what your job is all about. Most of the time you're defining, choosing or communicating standards. In my opinion you have got several responsibilities:

1.) Defining standards

It is your responsiblity to define the standards for your applications. This includes coding conventions but also architectural standards and processes. Homogeneity is sacred and thus this is a very important thing. The better your standards are, the easier it is for all developers to work with your company's products, even if they were not the original creators.

2.) Know your infrastructure or choose the appropriate one

It is your responsibility to know your company's IT infrastructure best or to choose the appropriate infrastructure. Choosing an infrastructure is a strategic decision, so choose wisely. Also consider economic factors (are there enough developers available for that technology? How much do they cost? Will I still get support for that 3rd party library in 3 years?). This often involves trade-off decisions like higher development costs but lower runtime costs or the opposite. You're also responsible for picking the right tools to aid the development process.

3.) Have deep insight in your business domain

It is your responsibility to know the business domain best! You should be the one who has the best sight on the big picture of your problem domain. You need to divide it into components and subcomponents and choose their place in the infrastructure! You'll have to think about synergy effects (reusability etc.).

4.) Define interfaces between system and components

It is your responsibility to define interfaces between systems and components! When the interfaces are good, implementations can be exchanged pretty easily.

5.) Choose the right architecture

It is your responsibiltiy to choose the appropriate architecture for applications and to provide a standard way of implementing it. In my experience, this is best done by providing small example projects that show how to create the structure of files and folders and how to implement standard things.

6.) Communicate! Communicate! Communicate!

Last but not least, it is your responsibility to communicate everything to the developers, to help them understand and to listen to their criticism. In my opinion you should as often as possible have the developers involved in important decisions. They might bring up things and potential problems you wouldn't have noticed. Communicate a lot with them and listen to their feedback and problems. Have your wizard around when you're defining standards or you're creating an example project for a certain technology! Collaboration is the key to success.


I am very interested, for example, what type of diagrams and documents an architect might provide so that they can assist a developer in doing their job.

You'll have to help the developers understand the business domain and the architectural decisions you made. I wouldn't waste the time and create documents that are subject to change every three weeks. Imho the best way to provide the knowledge is to give them example code (an example project e.g.) and to sketch down some UML every now and then when they're having a problem or you need to communicate something. This should be supplemented by the usual documents (requirements analysis, product backlog, etc.).


Finally, I want to give you some personal advice. Having this role is hard indeed. You're responsible for many things. Success and failure stand and fall with your ability to communicate and collaborate. You needn't know everything or excel at every single task, rather make sure your team participates and find the best solutions as a team. Don't be an ego, there'll always be a developer who knows something better than you. Keep these people around you for the sake of the product. Be humble and incorporate any good feedback. Don't take criticism personally, but compliment developers on a well done feedback or for pointing out errors.

share|improve this answer
4  
Great answer, +1 for point 6 having developers involved in important decisions. But I also would like to have application maintenance, operations and test involved. –  KeesDijk Sep 10 '11 at 14:04
1  
(+1) The first paragraph says all, altougth the rest of your answer its more descriptive. –  umlcat Sep 10 '11 at 16:23
1  
+1, altho it's a good idea to limit those included in point 6 to few senior engineers as too many cooks in the kitchen often stifles production. –  Demian Brecht Sep 11 '11 at 0:58
1  
Amazing answer to a below average broad no effort question! –  Steven Jeuris Sep 12 '11 at 13:28

As noted by Falcon ( Standard practices for an architect ) the architect role isn't universally defined yet and there is a lot of differentiation between company's on what they expect from a software architect.

but IASA is working hard on defining, educating and certifying architects look here for a lot of information on how they perceive a software architect.

a book that you might find helpful is 97 Things Every Software Architect Should Know (Paperback)

I personally love the way Simon Brown looks at Software Architecture and what he calls Hands on Software architecture. He has a nice presentation here but his entire site is worth studying.

From the resources above and my personal experiences the tasks performed by a software architect in general are a subset of the tasks below.

  • gathering non functional requirements
  • decomposing systems into subsystems and defining the responsibilities of these subsystems.
  • fitting the system into the environment
  • making technology choices
  • communicating on how the choices made affect the concerns of the stakeholders and how these choices affect the non functional requirements
  • developing a longer term vision on where a system is going and making sure that current choices don't make needed future development impossible.
  • develop prototypes to see if certain architectural decisions are sane.
  • communicating his ideas to the team.
  • getting feedback from the team to see if certain choices don't cause problems during development.
  • reviewing the system.
  • making choices to except technical dept and keep an eye on this dept.
  • make choices about migration paths, versioning and release management.
  • extract/define reusable components
  • define coding standards
  • etc...

in a more populistic way I would say : gather information, communicate, make choices, communicate, help realizing, communicate, review, communicate and start from the beginning.

The diagrams software architects make can be tricky, I really believe you must use the appropriate diagram that shows the concerns of the intended audience best. So the diagram is dependent on the concerns and is depended on the audience. But if you take that to the ultimate than you will only be creating diagrams and never will get to creating a finished system. So you need to balance. But diagrams Software architects make :

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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