Agile Enterprise Architecture? You bet!

The title of yesterday's post caused me to google "Agile Enterprise Architecture". And sure enough, others got there before me. Lots of them.

• Agile Enterprise Architecture AgileEA! is a free open source EA Operational Process. It is a framework that is designed to either use as is, or to tailor and publish your own Enterprise Architecture Operational Process.

• AgileEA Wiki Site  wiki site for Agile EA Architecture.

• Eclipse EPF Composer is an ecliipse-based editor for building a new EA or refining an existing one.

The EPF EA Composer is only supported on Windows, RedHat/SUSE Linux and "perhaps others". I tried it on a Parallels Ubuntu VM inside MacOSX. It loaded fine, but crashed with a NPE on clicking the various models. Aparently there's a rich text component that isn't quite portable.

So I installed it on my Windows VM, and was frankly impressed. The Composer installed flawlessly (not usual with eclipse in my experience) and ran perfectly. It wasn't immediately obvious how to use it, but it comes with tutorials that brought it home quickly.

Better yet, there's a community developing EPF "plugins" (terrible name IMO). These aren't code, but architectural approaches, such as Scrum. For example, Eclipse has a plugin download page that allows their Scrum process model to be loaded into EPF. The same site also provides a version of this model published as HTML. That is produced by installing the Scrum library into EPF,  editing it to suit local conventions, and publishing it as HTML.

In my own work with Scrum, we used wikis to convey our ever evolving conventions to each other and our stakeholders. Those  were like communal legal pads that can record whatever people write there. But this unstructured approach means web pages become chaotic. And since navigational links between pages is up to each contributor, it becomes hard to find anything when the site grows over time.

EPF  is more like a workbook. It starts with most of the text you need to define a Scrum methodology, such as descriptions of the key roles and responsibilities. But it allows these to be changed or extended with whatever is missing. All pages are automatically linked into a hierarchy so browsing is much easier. And the structure automatically distributes different roles to different sections, which itself helps to keep the structure intact.

One concern, possibly an inevitable one, is that that publishing to html implies a centrally planned approach, albeit one that might be ameliorated by using distributed development techniques such publishing the evolving model for distributed access via Subversion or similar. That is, the only ones empowered to contribute are  EPF users with access to the enterprise model. Everyone else gets read-only access to the published (HTML) results, and cannot influence the architecture directly.  This is probably inevitable, and arguably good enough for less agile deployments. A middle ground might also be workable, such as importing the published HTML as in some writable format such as a wiki, with a select few responsible for manually moving information from the wiki  into the underlying model.