CE Fully agree and good point - I'll work on that as part of my 2nd Paper (maybe a third) on the
website.

In agile software development you
are focusing on the final product — i.e. a software product that will be
used by business for some useful purpose (hopefully). In agile enterprise
architecture, the end product (which, of course, is never actually "done")
is a set of models that (hopefully) allows the business to make informed
decisions about how best to adapt to change. So, agile software development
results in a product while agile enterprise architecture results in models.
Interesting slant on it. While you are not wrong - I was thinking more along the lines of the EA
converging the Business 'Products'. Products being some models, but also physical and tangible
implemented 'Business Processes', 'Software' and 'Hardware'. If done in isolation could diverge, if
done with the big picture in mind have more chance of converging.
Given the general aversion to modeling in the agile community, this could be
a problem.

Yes - agreed. If we push more for the Product angle this may alay their fears somewhat. Even if
conceptually the models describe the actual end products that are built in an Agile manner. Both before
and after the fact. i.e. If the Goals of the Agile Dev projects are driven by the thinking of the EA team
based upon their own models, then the implementation on the ground could still be largely done in an
Agile manner.

If agile EA is about producing models, but "agilists" don't like
models (which is a overreaching stereotype, of course), then what useful
thing does agile EA "build"?

To me - even though we produce models, the Agile Product developers do not necessarily consume
these models. They consume the output from them, Goals and requirements that Coordinate the
spawning of Projects. The consume or at least have to reconcile with the Reference Architectures they
have to build to (ok so that’s a model), but they don’t need to change it, just use it for understanding
and input to their work. They consume the requirements at

• a Business Arch level to work with Business Processes A,B and C.
• At an Information Systems Arch level they get to work with Information service L,M & N, and
• at Technology Arch level to use DB x, ESB y, Server z, etc.

If fact, there might be a large number of
"agilists" that think the whole idea of EA could never be agile (Big Design
Up Front thing).

There's the rub. The whole point of doing EA in an Adaptive manner is to build the design as we go
(just like they do) but not for one specific Product, for the whole collection of Products = Enterprise.
The Agile Dev Team for on Project only need to focus on their Product for their Project. EA focuses on
the glue between the Projects and Teams for the Collection of Products.

In particular, I think the first two principles of the Agile Manifesto don't
quite apply as written (or could result in misunderstanding). While it is
important to value "individuals and interactions over processes and tools",
we may need to be cautious about how this applies to agile EA, since EA is
quite a bit about understanding your business processes and how they map to
your technology platform (i.e. the "tools" that automate the business
processes). And since quite a bit of EA is about governance, there is a need
for process (how formal is another question). Perhaps this first principle
could be to value "Informed business stakeholders over reference models" or
something…

Yes - good point. Especially since the Models and repository in the early stages of an EA would not be
nearly as well defined or up to date as the knowledge of the users. I guess if you get really good at it
there will come a point where the knowledge base in the repository would be more accurate than any
one stakeholders individual knowledge (but that’s still an ideal right now!)

Second, "Working software over comprehensive documentation" might be better
restated for agile EA as "Useful architecture models over pretty pictures"
(i.e. no Visio or PowerPoint). I do think EA has run the danger of creating
too much "comprehensive documentation", but in many cases the bigger problem
is that the "comprehensive documentation" isn't very easy to use (because
it's often a pile of Word documents, Visio diagrams, and PowerPoint
presentations).

Yep - that’s exactly the problem we (where I work) have right now! Made worse by the fact that older
documents contradict newer ones, etc. Boils down to having the right EA Toolset which integrates to
the Asset repository of the Enterprise, etc.

I think a clear definition of what it means to be "agile" at enterprise architecture needs some more attention. In agile software development you are focusing on the final product — i.e. a software product that will be used by business for some useful purpose (hopefully). In agile enterprise architecture, the end product (which, of course, is never actually "done") is a set of models that (hopefully) allows the business to make informed decisions about how best to adapt to change. So, agile software development results in a product while agile enterprise architecture results in models.
Given the general aversion to modeling in the agile community, this could be a problem. If agile EA is about producing models, but "agilists" don't like models (which is a overreaching stereotype, of course), then what useful thing does agile EA "build"? If fact, there might be a large number of "agilists" that think the whole idea of EA could never be agile (Big Design Up Front thing).

In particular, I think the first two principles of the Agile Manifesto don't quite apply as written (or could result in misunderstanding). While it is important to value "individuals and interactions over processes and tools", we may need to be cautious about how this applies to agile EA, since EA is quite a bit about understanding your business processes and how they map to your technology platform (i.e. the "tools" that automate the business processes). And since quite a bit of EA is about governance, there is a need for process (how formal is another question). Perhaps this first principle could be to value "Informed business stakeholders over reference models" or something…

Second, "Working software over comprehensive documentation" might be better restated for agile EA as "Useful architecture models over pretty pictures"
(i.e. no Visio or PowerPoint). I do think EA has run the danger of creating too much "comprehensive documentation", but in many cases the bigger problem is that the "comprehensive documentation" isn't very easy to use (because it's often a pile of Word documents, Visio diagrams, and PowerPoint presentations).

Anyway, my two cents…

Thanks, Chris ~:|