Alan Inglis posted about What good looks like from a solutions architecture perspective. How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.
Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:
- Project Background
- Terminology
- Key Drivers, Principles, Standards and Constraints
- Business Problem
- Information View
- Risk View
- Application View
- Data View
- Integration View
- Infrastructure View
I have some questions for Alan on this:
- How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
- Is there a subset of these artefacts that would be sufficient for small and medium projects?
- How would the next solutions architect find and assess the artefacts created? Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?
We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it. Some of the key factors for me would be:
- ensuring that there is time for solution architects and enterprise architects to work together to do peer reviews: 1) pre-project, 2) technical reviews in a project and 3) post-project
- communication of agreed upon standards and principles is essential to build a common language
- negotiating with functional managers to ensure time is allocated to every project for architecture
- regularly demonstrating value to the organization by taking an enterprise, long term view
