What good looks like … follow-up

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:

  1. Project Background
  2. Terminology
  3. Key Drivers, Principles, Standards and Constraints
  4. Business Problem
  5. Information View
  6. Risk View
  7. Application View
  8. Data View
  9. Integration View
  10. 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