May 23, 2006
Agile Enterprise ArchitectureIs it possible to be "agile" about enterprise architecture? It's one aspect of governance that has traditionally implied heavyweight processes, Big Design Up Front and authoritarian, centralised control. But does it have to be like that?
Today I took part in a different kind of enterprise archiecture, on a much smaller scale - but I class it as "enterprise" because it involved more than one information system and more than one department. I have been tasked with classifying a list of business processes into process areas (yes, I've got my business modeling hat on today), with the end product of a big "process walllchart" for the client's senior managers to wheel out whenever anybody asks "which bit of the enterprise are we talking about?" Naturally, I've been capturing this information using a UML model.
Meanwhile, the guy sitting next to me, who works on a different team, is busy capturing information about the relationships between the very same business processes. He is using a spreadsheet. He is adding processes to his list. My list is therefore getting out of date. I have to keep updating my model to keep up with his spreadsheet (and vice versa). There's a vey good chance our data will end up out of synch. This is a level up from copy-and-paste coding or a non-normalised database. The architect in me needs to fix it by removing the duplication.
So I refactor, creating a single system for capturing both sets of data. I add a process area column to his spreadsheet, and merge my data with his data. If he adds a new business process, I can see straight away that a new unclassified process is in the list.
To me, this has an "agile" feel to it. I didn't set out to design a finished solution. I just used what was to hand to solve the immediate problem of classifying business processes. I actually wanted to write the process names on cards and put them in boxes, but I was overruled by a document-centric culture. So I did the simplest thing I thought I could to solve the problem. I created UML packages as the process areas, and use cases as the processes, and stuck the use cases in the most apprioriate package.
My colleague with the spreadsheet did the easiest thing he knew to solve his immediate problem. Through our regular discussions about what everybody was doing, we spotted the duplication and refactored it out of existence.
I maintain that the key to good architecture (and to reuse) is knowledge and communication. You cannot reuse what you don't know exists. You cannot remove duplication if you don't know it's there. People building, supporting and using systems need to make it their business to know about other systems. They should be especially interested in the data in those systems, and - as a basic design principle that applies at all levels - to keep function as close to data as possible. If you have a Lotus Notes database with customer names in it, and you know that there is another database somewhere (or spreadsheet, or Word table, or web page) with the same information, you should take that duplicate data and put it on one place where it can be shared (reused) in spreadsheets, Word documents, web pages, and so on. So if John Q. Customer changes his name to Jane Q. Customer - and, by the sound of it, that's not all he changed - that change will be immediately reflected wherever his (or shoud that be "her") name is referenced.
This requires no central control. No ivory tower. No mysterious bearded bloke in a white suit talking bollocks in a room full of TV screens. It just requires some basic design principles, a sense of shared system ownership and - above all else - a culture where free communication across all boundaries is in abundance.
Posted 14 years, 8 months ago on May 23, 2006