This post is part of the Architecture series of articles, but I don’t know how many more there will be.
When doing an architecture, Togaf states that the outcome should include a description on how the architecture could or will, if we are sure that will happen, evolve.
I think it is very important to reflect the possible future requirements and sketch how the architecture can overcame them. For example, in case more power is required for a certain solution, how this can be achieved or if some non-abstract future security requirements finally have to be applied, how this will be solved.
By showing how this changes can be done in the current architecture, we will achieve 3 goals:
1 – Be prepared for the changes.
2 – Validate the solution.
3 – Show that not only current requirements have been used to design it.
diumenge, 11 d’octubre del 2009
dissabte, 29 d’agost del 2009
Architectures (I)
When an IT architect designs a new architecture, it has to favor some aspects among others: performance over administration simplicity, administration simplicity over installation simplicity or etc. Depending on the situation and the architect criteria, it’s better to favor one or another. It’s a price that we have to pay, because it’s nearly impossible to get it all.
Once the design has been created, if other IT guys see it, they could think it’s not the best design because everybody has different personal criteria: some people are stability fanatics and they could choose even very old but stable releases. Other could prefer state of the art architectures, etc. And the main problem is that under their personal criteria, they all are right and the rest of the world is wrong.
At this time, I’m reading “Togaf 9: Pocket guide” which has been inspiring for me. Togaf states that there is an initial phase during the design of an IT architecture, where the principles and guidelines of the design have to be set. That means that the Architect has to discuss with the customer or the IT department, which will be the principles and guidelines that will drive the design, and the most import issue, they should be included at the beginning of the design document. By doing that, the architect is setting the rules for the architecture and giving fewer margins for personal criteria.
Many people could think that this is only valid for big architecture projects, but I think it’s not true, even if the architect delivers a sample architecture, that design should also include a chapter with the sample principles and guidelines that are behind it
Once the design has been created, if other IT guys see it, they could think it’s not the best design because everybody has different personal criteria: some people are stability fanatics and they could choose even very old but stable releases. Other could prefer state of the art architectures, etc. And the main problem is that under their personal criteria, they all are right and the rest of the world is wrong.
At this time, I’m reading “Togaf 9: Pocket guide” which has been inspiring for me. Togaf states that there is an initial phase during the design of an IT architecture, where the principles and guidelines of the design have to be set. That means that the Architect has to discuss with the customer or the IT department, which will be the principles and guidelines that will drive the design, and the most import issue, they should be included at the beginning of the design document. By doing that, the architect is setting the rules for the architecture and giving fewer margins for personal criteria.
Many people could think that this is only valid for big architecture projects, but I think it’s not true, even if the architect delivers a sample architecture, that design should also include a chapter with the sample principles and guidelines that are behind it
Subscriure's a:
Missatges (Atom)
