Potential Problems with an Agile Approach

No approach to enterprise architecture is perfect, including this. We would be remiss if we didn't identify the following known issues:

1. It does not include an explicit way to ensure compliancy. There is something to be said about the philosophy "If you build it, they will come," as long as you build something people actually want. We highly suggest that you do not force anyone to work with your architects and that instead you make it an option. For example, the CAT members at Canaxia should make themselves and their work available to project teams and should wait for the teams to find ways to best take advantage of their offer. This forces agile architects to provide services in such a way that they are attractive to development teams, that they actually provide immediate value to developers. The risk with this approach is that an application team will still decide to opt out and do things on its own, potentially producing a system that does not conform to the existing environment or to the overall corporate vision. The implication is that you need to either accept this risk or to put a mechanism in place to mitigate it. A good place to start would be to identify why the project team has chosen to opt out and then to address the actual root cause.

2. It depends on people being responsible. People need to be willing to work together. People need open minds and to be willing to learn new techniques. People need to accept that they make mistakes, and that they don't know everything.

3. It requires you to actively strive to keep things simple. Process entropy, the tendency of processes to become more complex and slower over time, is a serious danger to agility. Each new process step, such as the addition of a checklist or a review, always sounds like a good idea at the time and they almost always are. Unfortunately, a price must be paid, which is often forgotten. Follow AM's Maximize Stakeholder Investment principle when you're improving your software process, and ensure that all process improvements truly are improvements. Canaxia kept things as simple as possible.

4. It requires you to accept an agile approach to modeling and documentation. Many architects wait until they've got it "just right" before they publish. Sometimes they try to wait out fluctuations in technology or deficits in skill sets before they publish anything. The end result is that they may never publish anything or may publish too late. Everyone, including the architects, needs to accept that architecture models don't need to be perfect; they just need to be good enough. This can be very difficult for some people to accept.