A recent comment on my post about the value of enterprise architecture suggested that enterprise architects should be directly involved in Scrum projects. In that post I suggested that the primary value of EA is “continuity” and “self-correction” across all the IT initiatives. If these qualities represent the value of EA, then the mechanism for realising that value must involve communication.

Communication is the key to ensuring that IT project deliverables provide cohesion across organizational, geographical and temporal boundaries. I have previously written that communication and governance are effectively the same thing. The problem is that “governance” needs to overcome the image of heavy-handed, top-down, hierarchical “rules” handed down by “out of touch” enterprise architects – like commandments on tablets of stone. EA must be seen as an enabler, not a roadblock.

But communication and governance must also be relevant to the organizational culture. So if the culture embraces agile development methods such as Scrum, then on the face of it the governance structure ought to conform with agile practices which favour direct verbal communication over documentation. If it is true that an embedded business representative can communicate requirements more effectively than a written requirements document, then perhaps it is also true that an embedded enterprise architect can “govern” more effectively than a written EA document.

However, on reflection, I don’t think the analogy of EA as a “customer” of the project is quite as strong as I first thought. There are a couple of differences between “business requirements” and “EA requirements”.

First, business requirements for a project are communicated primarily to that project. Few if any other IT projects would be interested in these particular business requirements which we are trying to encode into an IT solution. However, EA requirements must be communicated consistently across multiple projects and consistency demands that the EA requirements – the “governance principals” – need to be encoded in some written form, independent of an individual architect or even team of architects.

Second, business requirements change very frequently within the timespan of an IT project. Indeed the development process itself can change business requirements. This is why agile methods value verbal communication methods over written – so as to allow for frequent change in business requirements. EA requirements will not change as rapidly. Even though the Enterprise Architecture will evolve over time, it should not change over the course of a single project. Indeed if your Enterprise Architecture undergoes sudden rapid shifts (e.g. adopting an overnight SOA mandate) then you have a recipe for IT disaster. Hence the agile “insight” that written business requirements cannot keep up with reality, is not quite as relevant when it comes to EA requirements.

So my response to Paul’s comment is still: Yes! I agree that an EA representation on a Scrum project would be a good idea – to communicate, elucidate and interpret EA requirements to the project and importantly to take new lessons learned back from the project into the governance structures. However, this is no substitute for EA “documentation” – artefact-based governance – which is necessary to ensure consistency and continuity.