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.
PingBack from http://www.simplynetdev.com/correct-is-a-point-of-view/
PingBack from http://www.simplynetdev.com/correct-is-a-point-of-view/
PingBack from http://www.simplynetdev.com/correct-is-a-point-of-view/
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.
ROTF,L
Only an EA would answer that way, Gern.
The phrases "correct portfolio" or "right answer" are problems because people ascribe emotions to statements like that. Those emotions create a level of inflexibility when it comes time to correct mistakes or adjust to changing business requirements.
I’m not arguing for relatism. EA teams must ascribe to a basic set of principles, drawn from IT strategy and business strategy, and must stick to them in drawing out conclusions…
But it is not possible to avoid tradeoffs, and no one can afford to do every "correct" thing at the same time. Some things are just higher priority than others.
Here’s the cool part: EA doesn’t get to decide business priorities. We don’t have those decision rights. We don’t represent the shareholders. We represent principles derived from strategies constructed to approach business goals that the shareholders find palatable. That’s a long way.
So when we have an idea of the "correct" world, we need to temper our enthusiasm for our own viewpoint with the (sometimes emotional) goals and desires of the people who actually have the right to make decisions.
We don’t ask for everyone’s opinion. We go to the decision makers and present the rationale for our priorities. It is not enough to create a "correct" list because it is not "correct." It is correct according to our viewpoint.
We cannot toss that over the wall to execs and either (a) say nothing, giving us the right to gripe and complain that they didn’t follow our advice, or (b) fight tooth and nail for our idea of the priorities without regard to those of others.
The list of priorities, created through a collaborative process, is often more of a compromise than a list of ‘correct’ ideas.
It’s not relativism. It’s real.
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.
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
Business user/client wants the application to be functional and bug-free, and that’s what they pay for. Once the payment is made, when the application usage increases, when hackers warm up, when business logic changes then certainly the non-functional requirements such as flexibility, performance, documentation, configurable (no hard coding) etc really come into play. Interestingly the business user had taken such things for granted, while accepting initial version of application. To retain the customers, we need to deliver a bit of "perfection" too… It remind me of "sailer" coding now: Write code for 2 months, then leave the country for next 6 months 🙂
Hello Litty Joseph,
We can certainly discuss an application with a business stakeholder, but that shouldn’t be the extent of the discussion.
We should also be discussing the business strategic needs, the maturity and readiness of IT systems, the long term impacts of business trends, and the connection between business processes and their technology needs.
It is entirely possible that they will love their application and we will suggest that they must kill it, or that they will hate their application and we will suggest that they should wait a year before replacing it, or that they will want to build a new solution and we will suggest that they adopt an existing one, or join with another team that is purchasing a COTS package, possibly causing that other team to restart their purchase process with entirely new requirements.
It is true that the business takes IT quality for granted (until it is not there) but IT also takes business planning for granted (until it is not there). Health requires both.
— N
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?
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.
Hi Nick. I don’t think that is what I’m saying. I thinking I’m more commenting about the binary choice you seem to be offering when you say things like:
"We tend to say things, in EA, like this: "we are not just about building apps right. We are about building the right apps."
I do like having the right app [for the business function], and I do like having apps written right but to me that’s a Developers perspective.
What I’m saying is that I think the meaning of "correct" for someone who comes to EA from an Infrastructure background is an application that *can be part of* a developing ecosystem.
Without writing a novel "correct" for me is an application that runs on our standard O/S, our standard hardware choice, our standard network protocols, can be backed up with our standard backup application, has BCP and DR capability, meets our Governance criteria, has acceptable maintainable and upgrade terms and conditions, can be interfaced with our other applications, uses our standard database technology, fits our storage model, fits in with our existing licensing schemes, and fits into our technology roadmap [et al blah blah].
As well as of course fulfilling the businesses needs.
I’m not going to object because it was written with Visual FoxPro or because it only comes in blue. And I’ve been around long enough to not be overly concerned when business buys a dog either because they don’t know their own requirements or someone is good mates with a VP from Vendor X.
Providing thought leadership aside, I am never going to be able to challenge the purchase of the "incorrect" application on the grounds of its business functionality, but I can if it won’t be part of our ecosystem and is therefore risky.
I could be doing you a disservice but I likened the point of view in your post to the fact that nothing in the Architecture stream of the NZ Tech Ed was actually about what I’d term Architecture (Capital A). At best it was application design. Microsoft seems to have this pervasive meme of Architecture being software architecture. Potentially because you write and use so much of your own software.
I work for an Agency that was formed out six other agencies. Our current state is Frankenstein’s monster. Day to day EA to me is about building up standard repeatable patterns that over time and through influence I can ingrain in the organisation so we can reach a target state.
So mostly I’m in complete agreement with this blog. Apart from the bits when you give me that old System Administrator "who let the bloody developers out of their cages" spine tingle 🙂
Well, you presented two points:
– Define criteria : Well, at the enterprise scale, an EA team or department might be a little to small to define best practices and accurate assessment and quality standards. (Some EA being in a godlike mindset might consider me wrong here) That’s why, as part of an EA framework, a criteria set (or criteria definition and scaling standard to adapt it to the corporate environment) should be designed or at list suggested.
– Business consideration : Well, at the end of the day, you sure want to be able to think you offer the best solution you could design, meeting as many requests/needs as possible. In any business line, you could always find somebody to overrule you or your findings based on personal feeling/considerations. We unfortunately have to live with it and try to champion EA and its rights/justification in our corporate environments….
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
Nick I don’t take your comments as criticism. I read your blog for several reasons. One is that your posts of SOA and other "developery" things are informative. Another is that you also consider non "developery" things like ITIL. I’ve referred your blog to the BAs and Developers here, so occasionally at points in ‘discussions’ some one will say something like "but you agreed with Nick when he said x". (But of course my Architecture Waffle Fu is so strong I immediately prove how them pointing that out just proves the point I was making :-] )
One of the challenges I see in EA is coming to some sort of common understanding between those from information, application, or infrastructureoperations backgrounds. Blogs like yours help.
I spent quite a few years in the Internal IT group of a US multinational IT company so I understand what it is like for you. The only real time I’ve ever had culture shock was going to the corporate headquarters in PA.
Hi Nick,
In my view, EA is not about either building apps right OR building the right apps. It is about creating a structured framework within which meaningful and collaborative dialogues can occur between the business and IT groups. The term that I use to describe this "structured framework" is Enterprise Architecture.
In most organizations, "meaningful and collaborative dialogues" between business and IT do not occur. You must ask why this is so. Is it because the business folks are overly demanding and unreasonable? Is it because the IT folks are unable to understand what business is saying?
In my view, the problem is neither the business nor IT. The problem is that EA has either not been done at all or, if it has been done, has been done incorrectly. Which brings us back to Nick’s original point. Is there a "correct" way to do EA?
The answer is absolutely, yes. But the starting point needs to be an understanding of what we mean by "correct". I define "correct" as "as simple as possible". So of two EAs that both accurately define the enterprise, the more correct one is the simpler of the two. And the EA that is "absolutely" correct is the EA that is the simplest possible EA.
Why do I believe that simplicity is the raison d’etre for EA? The answer goes back to my original question. What is it that gets in the way of meaningful dialogues between business and IT? In my opinion, what gets in the way is complexity.
When IT blames the business for fuzzy requirements, IT is wrong. When the business blames IT for inability to deliver, the business is wrong. The problem is neither IT nor the business. The problem is complexity. Until complexity is solved, dialogue is impossible. Complexity is the enemy, and it is the common enemy of both IT and the business.
So can you determine if an EA is as simple as possible? Again, the answer is yes. But to do so requires both an understanding of the mathematics of complexity and a rational process for testing an EA for being "as simple as possible".
These are both topics I have covered extensively in my book, "Simple Architectures for Complex Enterprises", so if you are interested in these ideas, that is where to go. I also have a number of papers on this topic at my website, http://www.objectwatch.com.
Best Wishes,
Roger Sessions
Hello Roger,
Thank you for contributing. Good to hear from you. I agree that complexity is the enemy of EA.
However, my point was NOT whether there was a correct way to do EA. My point was that there is that you set a vision and then you "walk the walk." You have to help make decisions that lead the business away from chaos and complexity and towards simplicity, and those decisions are not perfect. They are tempered by the capabilities of the enterprise, the capacity of the staff, the strategies of the business, and the personalities of the leaders. The imperfection is in the walking, not the destination.
Also, to your comment that the goal of EA is to create a dialog… what is the result of that dialog? An effective, correctly balanced, enterprise architecture. To get there, you have to operate a "book of work" or "portfolio of projects."
In other words, this is not an either-or… we are saying the same things. You are focused on the environment of the conversation… I’m focused on the topic of conversation.
Also, I do NOT agree that complexity is the ONLY root cause for problems in IT. Complexity is a serious problem, and one that the EA function is responsible for, but there are plenty of problems in IT that cause that conversation to be sour. Complexity is just one of them.
Respect,
—- N
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!
I love Roger’s book, and highly recommed it.
I usually approach this from the angle of business architecture: if I can get the business to state needs more clearly, getting change in the IT monolith is usually easier.
This is particularly important for those ‘undreamed of’ requirements thought up by technical people which can offer so much value.
Back to the main discussion: we talk about ‘correct enough’ in an attempt to stop the customer or the technical team trying for perfection inside projects, and I agree the concept translates to EA.
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