Kostas Tsatsaris

If not why not?

If so what length are the iterations/sprints?

ArchiMate is now actively used by over 50 different organizations and is supported by several commercial tools and consultancy organizations.
More information can be found on: http://archimate.telin.nl

They obviously want a Solutions Architect in the Enterprise context.

It would be really nice if we could get our own definitions is order so that the rest of the industry could use them. It leads to all sorts of misunderstandings and mis-alignments of concepts. I personally think this is one of the reasons for establishing Process webs, so that the terminology starts becoming more standard.

Does anyone else have any strong feelings about this type of thing?

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 ~:|

If we are to speed up the creation of an EA Process, it would be quicker to Extend the existing base processes, such as Change Management, Configuration management, Project planning, Environment disciplines and other RUP/OpenUP type categorizations in an EA context. What do you think?