My friends in the Agile community have succeeded in drilling a concept into my thick skull so deeply that the concept shows up in other things I do. What is that concept: don’t try to build the perfect app. Build the least complicated app that will do the job. Let the customer tell you when you are done.
Makes sense. Too bad there are so many developers who still insist on making this bit or that bit of code "really solid" or "reusable" when no one is paying for anything more than "functional" and "bug free."
So that bit of agile philosophy tends to get repeated a lot, even by me. There are a lot of people to reach, so we hammer home the concept: do the simplest thing possible… to the point where I use it even when I’m doing the ultimate BDUF exercise: Enterprise Architecture.
We tend to say things, in EA, like this: "we are not just about building apps right. We are about building the right apps."
But to be really honest, no one really knows what the "right" apps are. There are no tablets of stone that contain a perfect list of applications that should be funded or that should remain in the portfolio. We are humans and we make human judgements, using the best tools we have.
So the trick is to remember this: "Correct" is a point of view. If you think that a particular list of applications should exist, or should be funded, it doesn’t matter if you think you are correct. That is your point of view. Another person, with another point of view, may believe him or herself to be just as correct. You have to sell your concepts (and yourself) to be impactful. Help others to see your principles and how you used them to pick your list. Help them to share your point of view.
The challenge is not to do the "right" or "perfect" things, but to do a good job… and not to ‘gold plate’ the decision process with tons of special justifications or long meetings. Make a ‘functional’ decision, dare I say, ‘agile’ decision. Use the minimum amount of fuss that produces a good result.
That, my friends, is Agile Enterprise Architecture.