Agility Loop

Reading up applying Agile techniques to architecture and modeling, and came across a new acronym.  They Ain't Gonna Read It (TAGRI):

Extreme Programming (XP) introduced the YAGNI (You Aren't Gonna Need It) principle which advises you to not invest time overbuilding software because you likely won't need the extra functionality anyway, and that the time you spent building stuff that you don't need could instead have been invested building stuff that you do need.  There's a complementary concept with respect to documentation: TAGRI, They Aren't Gonna Read It.  The basic idea is that very little of the documentation which gets created during software development actually gets read by the actual target audience.  Recognizing this, you should model/document with a purpose and create agile documentation which reflects the true needs of the audience for that documentation; the best way to do this is to work closely with the people you are writing the documentation for, when you do that you discover that they may need something completely different than what you originally thought.

LOVE IT.  Too often in dealing in enterprise IT and architecture, there is a such a overwhelming amount of shelfware you can DROWN in it.  The emphasis should be on creating useful documents that actually contribute to the success of a project or capability.

In my role in supporting the U.S. Government in the evolution of an Information Sharing Environment, I have had the opportunity to become more exposed to the machine that is Enterprise Architecture Frameworks.  Not the frameworks themselves necessarily, but the machine and engine around them.  And more and more I have to wonder, what is the true value of the frameworks and the associated artifacts it produces?

To give context, it is probably useful to understand my background.  I have "grown up" during my professional career architecting (little "a"), designing, and implementing information systems.  This has included upgrades of email infrastructures (I still hate you Groupwise) to enterprise wide white pages/attribute services.  However, when I say that I have architected these systems, I mean that I have worked with some VERY good people to actually plan the entire system from software to hardware to networks to user experiences.  However, during that time, the maintenance and creation of artifacts related to Enterprise Architecture (big "A") Frameworks was NEVER a priority.  Typically there was only enough time and money to actually design and implement the system (DO SOMETHING) rather than the creation of artifacts (PROCESS).

Now does that mean I was simply blind to the usefulness of those frameworks?  Perhaps.  But since then I have had more exposure to life in the SETA world and with agency CIOs where these same Enterprise Architectures get a lot more play.  A lot of money gets spent on maintaining the associated artifacts b/c they are required for certain programs (typically over a certain dollar amount).  There are relatively few people who are "certified" in Enterprise Architecture, and therefore those contractors are pricey. Anyhow, I don't have a good answer.  But I do know that creating documents simply for the sake of creating them is not best practice.  I think there seems to be a lot more value in concentrating on information architectures and knowing more about our data so we can effectively share it with our business partners.