There is an almost constant drip of articles about why Enterprise Architecture and TOGAF particularly is or is not appropriate/valid, particularly in an agile environment because it typically results in lots of documentation which often date rather quickly when it comes to describing the landscape rather than be sustained.

So why am adding to this mass of MBs and GBs of text on the subject?  Well, when I do look at these articles (which can be frustrating at times) there seems to me several  points often overlooked, which is what I want to address.  These points are:

• A document might not generate vast amounts of value (unless you’re Gartner or a government think tank) but the process or journey (and hopefully act of engagement of the right parts of an organisation) should shake out influencing points.
• On the agile documentation perspective that people often argue as a reason not to document we should remember the agile manifesto says ‘Individuals and interactions over processes and tools‘ and  ‘Working software over comprehensive documentation‘.

Let me expand on my first point a bit more.  When looking at a solution space it is easy to define the requirements (or be SME stakeholder)that deliver capabilities for current and near future operational needs and ways of working.  These challenges will always gain precedence over the desired direction of travel because you’re working shorter cycles.  Okay, the answer to this is bound to be – well that is what is needed and delivers value. But this always puts you in a position of delivering against now. If you’re focused on the now in a competitive landscape, the first organisation to build for a likely future is going stand a good chance of winning ground. Or worse a sudden change of direction or focus can set you onto the back foot. This is where EA can help.  Well engaged EA effort will bring the right people together  because it seeks to draw out not just the end users but the influencers, the people defining the business capabilities, and value propositions. Typically those stakeholders will differ from those involved as directly or 1 step removed from the delivery engagement). As EA techniques and modelling challenges people to look at fundamentals it should  draw people away from considering the short and near term  focuses and address the bigger game. We could reduce this to extracting business capabilities rather than defining function points. As a result you have a business roadmap on which an IT roadmap can be hung. With this   you can focus on what delivers value and when, it may even validate the original position held by the delivery team. This validation could be easily considered a waste of time. Except it isn’t because you have a confirmation, but more critically those a bit more removed from the day to day will appreciate the value being delivered as they have helped define and confirm it, and hopefully more brought into the delivery goal. It may even present the opportunity show how technology innovation can inform the business of opportunity.

Let me illustrate with an example. Many IT systems deal with user and customers, and as a result a level of data security can be defined (at its most simplistic how would I want my details to be handled).  A development programme can be running smoothly delivering, but because the bigger picture/full business capability needed is not been recognised. That can be expected as those involved in delivery are more likely to be thinking about how to make now and next week easier. However if the organisation then  starts pitching and winning government contracts, as they perceive the business to be essentially the same service.  But those closer to the details of Government contracts will know that they often have a higher bar regarding data residency.  If you’ve been building against a single deployment location model (plenty fine for Joe public) then the change  can throw a seriously big spanner at the works if the contract doesn’t happen to be in the same place as your data centre. Yes, you can refactor the solution but actually what would have been easier is if this direction had determined at the outset, then you’d have designed ready to build the features when the work came in that handled residency questions. Ideally the process of getting the engagement and working towards EA views should have drawn out the view of a capability being wider than justJoe public.

The naysayers will probably argue back that you cant know everything in advance. To which I agree to an extent, but life is not black and white and there are varying probabilities and you can choose to only work the certainties, or work and engage with the probabilities. If you work with a bigger picture and probabilities it will be easier to handle now and potentially be ahead of the competition. Oh, and that is where Gartner & the government think tankers I mentioned make their money understanding trends and likely needs.

As to the second point,  as you have seen I am emphasising the tool (EA and TOGAF) as means to achieve the bigger picture aspects of individuals & interactions. Where bringing some of these people together to interact may not be the easiest as they will be the furthest from the day to day development. Remember that TOGAF does not need to be swallowed verbatim – infact like delivery methodologies such as OUM and RUP you’re encouraged to tailor the framework. The benefit of something being codified creates a context in which people well invest greater effort to achieve the process.  Consider this, standups in an agile operation happen consistently and reliably because the timing and obligation have been ‘codified’ (not necessarily formally) in the same way how standups actually function have.

So there are places for EA, but you’ve got to remember not the process that is the key, not the documents you will produce, but what is it you’re trying to achieve with its use.  It is not necessarily