"Correct" is a point of view

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.

Comments

• Anonymous
  October 10, 2008
  PingBack from http://www.simplynetdev.com/correct-is-a-point-of-view/

• Anonymous
  October 12, 2008
  This sounds a lot like relativism...in EA no less.  At least a good part of your argument seems to rest on the fact that there is no "correct" point of view, that there may be many points of view which I think begs the question, how many points of view are there?  How many is enough to consider?  If you have an answer to this, which I think you must at some point, then you're doing the very think you say you shouldn’t do, decide on the correctness of something - specifically, the number of viewpoints.  Someone, somewhere must make decision, not everyone everywhere.   In a court room my viewpoint, while it may be more or less correct, is not valid because the goal is not to understand everyone’s point of view but to make progress.   Decision rights and structure for said rights are supremely important even in the agile utopia you ascribe to. In the end someone must assert a point of view that is correct, as quick as possible.  I think you mean to assert that a point of view is never completely precise.

• Anonymous
  October 12, 2008
  The comment has been removed

• Anonymous
  October 12, 2008
  I think coming at EA from an Infrastructure background rather than a coding one I have a noticeably different perspective. When it comes down to it I don't care if it's the right app or whether it's written right.  I can only guide the business not control their perceived requirements.  I care about how hard it is to integrate an application into the ecosystem.  Wether it will cohabit and cooperate; or in other words what do we need to house, feed and water it, and how it is going to talk to everything else. Which gives me a slightly different perspective on virtualisation as well.  Virtualisation is a great tool for caging those surly beasts of applications and making them more manageable.  

• Anonymous
  October 12, 2008
  Fascinating, Robert.   I'm reading your post for the third time now, and it appears to me that you are saying this:   "We provide technical advice about technical impacts raised by business initiatives so that business people make good decisions." If that is the case, then I would agree: we have a different perspective on EA. I believe that EA is responsible for raising good ideas, not simply waiting for the business to ask.  In that vein, we have to create a picture of what the IT landscape SHOULD look like, sometimes many years in the future, and do our best to guide the order of projects and the scope of their infrastructural efforts, to deliver key parts of that future state vision. So when the business comes to the door with a new initiative that needs to be evaluated, it is evaluated not just in the context of "what harm can it do" but also in the context of "how well does it fit into the model of a developing ecosystem." I mean no disrespect.  If your role calls for the former, then you can and should fulfill that role to the best of your abilities.  My view of EA is simply different. Peace, ---- Nick

• Anonymous
  October 13, 2008
  The comment has been removed

• Anonymous
  October 13, 2008
  The comment has been removed

• Anonymous
  October 14, 2008
  It is an interesting thought that goes far beyond the realm of EA. When is a decision/an item correct? Correct translates to "meet a certain set of criterias". Why not create a framework of criterias then to assess Enterprise Architecture Initiative qualities. If there are guidelines to support the EA process (frameworks, model, standards, rules), it means its deliverables and outputs can be assessed. As you mentionned, the Enterprise Architect brings his own point of view to the discussion, but, if the business stakeholders were empowered to define their needs and vision on a scalable level, then you would be able to further assess your solution. What I seem to grasp from your post, if I get it right, is that there is not, today, an enough strong evaluation system to quantify the quality of an EA decision/suggestion. Is it because we lack references? benchmarks? Clearly defined objectives sets?

• Anonymous
  October 14, 2008
  Hello William, You have responded with an excellent question:  Why do we not have a strong evaluation system to quantify the quality of an EA decision or suggestion? I believe that it is many things, but first and foremost, it is a "who guards the guards" problem.  If we, as EAs, are responsible for understanding the criteria for the quality of ANY decision, then how do we routinely apply those criteria to ourselves, to insure that we not only measure the quality of our decisions, but also to improve them. That said, at some point, evidence of quality can only solve a problem if the stakeholders for that evidence care what the evidence says.   What happens when your stakeholder says "My mind is made up, don't confuse me with the facts?"  That is when the facts end and justification begins.  That is selling, pure and simple. Even when we are selling to ourselves.

• Anonymous
  October 14, 2008
  The comment has been removed

• Anonymous
  October 15, 2008
  The comment has been removed

• Anonymous
  October 15, 2008
  Hi Robert, Your criticism of Microsoft's apparent inability to speak to Architecture (capital A) is heard fairly frequently, and there are many folks on the inside who are passionately working to create stronger, more focused, offerings for the Architecture community.  I'm somewhat tangential to that effort in that I'm not employed by one of those groups.  (I help to run the operations of the company... deep in the bowels of IT... which makes me qualified to have this discussion). I hope that you don't take my response as a criticism of your role or your viewpoint.  To be honest, the statement "build right apps vs. build apps right" is not intended to be a binary choice.  At the end of the day, the formula that EA "helps to guide" produces a portfolio of applications, and there are implications to that portfolio.  You have addressed, in your eloquent response, many of your concerns that arise, and I agree with you. I've seen 'munged' infrastructures in public IT before, but to be honest, I've seen it in corporate spaces as well (including some bits of MS IT).  It's a tough problem, and one that resists "top down engineering."  I can only say that I wish you good fortune in helping your agency cope.  If I ever get down to NZ, I'll buy you a beer. --- Nick

• Anonymous
  October 15, 2008
  The comment has been removed

• Anonymous
  October 21, 2008
  The comment has been removed

• Anonymous
  October 21, 2008
  The comment has been removed

• Anonymous
  October 21, 2008
  Hi Nick, A few more points, then I'll leave you alone! You say that you agree than complexity is the enemy of EA. Actually, the situation is reversed. Good EA is the enemy of complexity. In fact, complexity is, in some ways, the friend of EA, since without it, we would have no reason for EA! Second, EA does not lead the business away from chaos. In fact, a good EA doesn't lead anybody anyplace. It simply sets the stage for the business and IT groups to work together in a collaborative way to do business better. And I do not believe it is the responsibility of the EA group to manage a "portfolio of projects". That is the responsibility of the IT group. One of the reasons that EA groups so frequently fail is that they try to do too much. And finally, while I agree that complexity is not the only root cause for problems in IT, it is by far the most serious problem and the only one that we routinely do not know how to manage. Until complexity is brought under control, trying to deal with the other problems is a waste of time. And once complexity is brought under control, the other problems typically fade into relative insignificance. Unfortunately, in most organizations the biggest problem of all is not complexity. The biggest problem is that the organization doesn't know that its biggest problem is complexity. Until we know who we are fighting, it is impossible to win the battle!

• Anonymous
  November 09, 2008
  The comment has been removed

• Anonymous
  November 10, 2008
  Hi Steve, I do agree that there is a break in the understanding between what the business needs and what IT delivers.  There are many causes for that break, one of which we can place at the feet of the business for not making any real attempt to discuss their requirements.  On the other hand, we can also place IT in that boat for having invested so little in the business architecture that we are not able to correctly interpret what the business is actually saying. I don't make the distinction about 'undreamt of' requirements that originate through creativity from the technical team.   I would agree that the business often fails to consider all of the business processes implied by a particular solution, especially when the solution being proposed replaces, instead of upgrades, an existing solution.   I would also agree that the business sometimes fails to describe what a measurable result would look like, or to make clear the business rules that drive success.  It is up to the analyst to discover them. On the other hand, if there is no measurable benefit to a feature, perhaps it is a design choice, but not a feature... perhaps it is a reflection of the SOLUTION and not the PROBLEM.  In that case, perhaps it is not a REQUIREMENT, in that a requirement is something that the business requires, not something that is required by the solution. I've spend the last couple of months working on the most extensive traceability model I've ever encountered, considering and documenting hundreds of different opinions, and dozens of threads through various planning, design, development, deployment, and operations processes.   To me, the distinction between the 'requirements of a business' and the 'requirements imposed by the solution' are very important. I'll blog on the distinction later. --- N