Chief Architect - Enterprise Architecture Blog

My blog on what good looks like prompted a couple of blog posts that I would like to answer. My answers will be inline. They take a pragmatic viewpoint of a practicing executive level solution architect …

The first blog was written by Leo de Sousa and this had the title of What good looks like – follow up. He asked the questions:

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.
- This is a good point and I should have made the context clearer. I am not assuming that the artefacts exist as project artefacts but just that they exist. They may be at enterprise, line of business, program or project level. In the context of a project, I just want the information. My opinion is that this information should be created at an enterprise or line of business level and updated by projects and support teams.
Is there a subset of these artefacts that would be sufficient for small and medium projects?
- No! A smaller project will have fewer decisions, fewer deliverables and therefore the information produced will be less.
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?
- It doesn’t matter so long as architects, analysts, designers, developers, testers, etc can find what they need when they need it. All of those approaches listed can work with the appropriate implementations and disciplines and they can all fail.
- The key to this is not the repository, it is in most organizations the “business as usual” support team. They are the long term custodians of the IT solution and its relationship with the business. They keep the knowledge up to date and are responsible for handing that knowledge on to development teams when major changes are required. Ideally this is well supported by sound processes and tools and not critically dependent on individuals.

He went on to make the points that the key factors for success are:

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
- I absolutely agree and I find that this is one thing that can be very difficult to achieve. Enterprise architects tend to be in short supply and have to ration their time. Solution architects often do not take an enterprise view and fail to highlight critical enterprise architecture issues. A good triage process addresses the issue of rationing.
communication of agreed upon standards and principles is essential to build a common language
- The standards and principle help address the second issue and educate solution architects on the issues that are of enterprise significance.
- I would go a little further, we also need common goals and an agreed approach to making rational compromises to help solution architects make the right decisions and recommendations.
negotiating with functional managers to ensure time is allocated to every project for architecture
- This point is very important. It is easier where there is a recognition that the landscape will change significantly. It is equally necessary where the project extends an existing capability.
- In any significant project there is the potential that a requirement will “break” the architecture (the break could could be in the business, applications, data or infrastructure). My approach to ensuring there is architectural effort has been to ensure that the project has enterprise and long term requirements captured to justify the “extra” effort.
regularly demonstrating value to the organization by taking an enterprise, long term view
- Every project has an enterprise and long term context. The key is to identify the stakeholders and requirements to express this. Then demonstrating value becomes meeting stakeholder requirements.

The second blog was by Nick Malik and was entitled Why good doesn’t happen. He states that “there is a flaw in the logic” and the “advice is incomplete”. He examines my list of 10 artefacts (or 14 as he appears to prefer) from the perspectives of :

Viewpoint 1: at the beginning, looking forward, defining project requirements

Viewpoint 2: in the middle, looking back, trying to understand

He goes on to make the following points:

If I create an artefact “for the future” that does not mean that the people, in viewpoint 2, will use it. He states there must be a design process that mandates that the artefact be used.
- The existence of a process today does not imply the existence of the same or any process in the future (the reverse applies too) so I am not sure that this point helps us much.
If there is not such a process then the artefact should not be produced because there is no business justification.
- The business justification is simply based on hard experience which tells me from past and current projects that I need this information to take cost, time and risk out of making significant changes to an existing solution. The project or program, through its governance process, is at liberty to de-scope these proposed deliverables. But, in the interests of making a fully informed decision, it is passing on cost, time and risk to the next project.
In the context of the maintenance process, we should “draw the requirements for documentation from that development process… not from a wish list.”
- To be clear, the selection of artefacts is mine based on my experience of making large scale changes to existing architectures. It is not the “wish list” of an enterprise architect imposing his views on developers.
The artefacts identified form “some tiny part of a much larger ecosystem of information”.
- I absolutely agree. The management of this eco-system is another subject. My preference is that we approach this using a federated approach that puts responsibility close to the point of consumption but also ensures coordination where necessary.

Finally, he makes the following suggestions as to how I should complete my advice:

The artefacts “need to be findable, consistent, and AUTOMATICALLY linked together in a way that minimizes the “archaeology expedition””
- This is a worthy aim. In many organizations this is a distant dream – perhaps a fantasy. If we are not on that road, I think we should do something today that makes things better, let us just have some information. And that is what I have tried to describe. I believe that the issue of inconsistent and out of date information is quicker and cheaper to solve than the problem of no information.
“The data describes part of the architecture of the enterprise, and as such, needs to be maintained at the enterprise level, for the sake of engineering.”
- It does not need to be maintained at enterprise level. It needs to be maintained where it has value to be maintained. It needs to be consistent across the enterprise where consistency has value. We should only engineer to the level where the engineering adds value and no further. I do not see the need for monolithic centralised approaches that require huge uninformed, unaccountable bureaucracies to operate.