|
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. |
|||||||
|
|
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.
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.
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. |
|||||||||||||||||
|
|
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.
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 :
|
|||
|
|
