community

9 years, 25 days ago

Does anonymity promote ill-informed consensus?

by

There are a spate of new Social Media apps that have emerged lately, all of which allow people to post comments and ideas anonymously.  They are being quickly adopted, especially among the very important 13-18 year old “adolescent market.”  They are also being quickly banned for promoting cyberstalking, cyberbullying, and otherwise cruel behavior.  Does anonymity protect cruelty?  And what does that say about more established Anonymous sites, like Wikipedia?

Normally I don’t comment on Social Media.  My regular readers know that I tend to focus primarily on enterprise architectural concerns like business model viability and strategic alignment.  But there is an interesting cross-over between Enterprise Architecture and Social Media, especially anonymous social media: the creation of community consensus.

The state of anonymity

For those not keeping up, there is a spate of new social media apps that have emerged lately, from Whisper to Secret to Yik Yak, that allow smartphone users to sign up and then post messages unfiltered and anonymously.  When in anonymous mode, users tend to say things that they feel uncomfortable saying on Twitter or Facebook (where their friends, family, and coworkers may discover a side of them that they may not agree with). 

YikYak especially is troubling because it uses a geolocation filter… you can see things posted by people within a certain distance of you.  Sounds innocent, right?  After all, young adults filtering through Bourbon Street festivities in New Orleans could share that a particular bar was playing really good jazz, or that drinks are strong and cheap across the street.  But you may quickly see the problem when I use two words: middle school.  Already, some High Schools and Middle Schools have had to ban the app because it became a platform for bullying and cruel comments.

The effects of anonymity

But what does it mean to be anonymous?  What are these comments that the guy next to you would like to send to “the world” without anyone knowing it was him?

You can look for yourself at Whisper.sh.  I spent a few minutes browsing through some of today’s messages.  Most were simple secrets… many were sexual or related to dating.  Some were work related.  Most had responses from equally anonymous people, and most were fairly benign.  Of course, there could be some judicious editing going on for the sake of casual surfers like me that own a Windows phone (and therefore can’t use the app).  Secret and Yik Yak don’t even make an effort to show any of their messages on their website.  It’s all in the app (once again, only for IPhone or, in the case of YikYak, android).

Of these, I think Yik Yak is the most interesting from a consensus point of view, because it is the only one that attempts to filter according to a community.  GeoLocation, especially when it comes to universities or even small towns, is sure to limit the reach of a message to people who share something in common with you.  That sense of “sharing something in common” is really what defines a community, and consensus only really matters in a community.

Anonymity and consensus

Does anonymity work to create consensus?  Sure.  Think of standing in a large crowd.  If one person yells something, you don’t normally turn to them and identify the source before considering, and possibly agreeing with, the content.  This is the very essence of a political rally or a protest march.  Taking in unfiltered ideas and deciding on them, on the spot, is part of how consensus is built.  Of course, there is no good way to take in ONLY good ideas when you are in a crowd.  We count on the crowd to do that for us.  If someone in a political rally yells “Death to the other guys!” we would expect the folks standing next to them to react, possibly causing the rabble-rouser to back down.  (Unless your protest march is in Karachi or Tehran or Cairo… but that’s another post).

In that sense, standing in a crowd is only “partially” anonymous.  There are still people who can see you, and if you do something really outrageous, there are people who could react by hitting you.  This is why you won’t find many people who will go to a crowded Yom Kippur (Jewish) service and stand up in the middle of the crowd and yell “Hitler was right!”  Pandemonium. 

But consensus and anonymity online is very different than standing in a crowd, and I think we need to be aware of the differences. 

The perils of anonymity online

Online, you can make claims that are difficult for another person to dispel, without consequence at all.  There is no one next to you ready to elbow you when you use name calling, or circulate unfounded rumors, or simply make things up!  Even when we use our actual names, we may participate in a discussion where we are not in the same room, or even the same continent, as our peers, and this can cause problems.

I cannot count the number of times I’ve witnessed this on LinkedIn.  A person will ask a question about frameworks, and I may point them to PEAF (a framework created by Kevin Smith).  No problem.  But if Kevin himself gets on the thread and mentions PEAF, his messages are blocked and he may even be kicked out of the discussion.  Why?  Because someone somewhere made a spurious charge (that he makes money when you use PEAF, which is not true).  Since the administrators of most LinkedIn Groups are anonymous, they can make bad decisions without consequence.  There is no good way for Kevin to clear his name of these charges because he does not know who the administrators are, and they appear unwilling to consider the possibility that he is not, in fact, using the platform to promote his own self interests.  Rumor rules the roost.  Not good.

I believe that the same thing applies to Wikipedia. 

Wikipedia, with its millions of articles, has emerged as one of the chief sources of encyclopedic content on the Internet.  It is widely respected, and most search engines make a point of returning Wikipedia entries near the top of their search results.  However, the administrators on Wikipedia are mostly anonymous.  (They use pseudonyms to do their editing work). 

This causes the same problems to occur in Wikipedia that occur in any other setting where people can be anonymous… mostly benign behavior with occasional outburst of bad behavior (with nearly no consequence). 

There is an essay (not a policy) on Wikipedia that says “Only Martians Should Edit.”  This policy says that some topics are so controversial that anyone associated with the actual content would be too biased to edit the content in a neutral manner.  Therefore, topics dealing with such things as State or Provincial politics, or national boundary disputes, or whether specific historic events should be counted as a genocide.  These things trigger strong emotions, so having people edit the articles as though they are “from Mars” can be a good policy.

On the other hand, for some topics that are very narrow, it is not possible to edit the article without knowledge of the subject.  If you are not an expert in African pop music, you may not do a good job discussing Azonto music and dance from Ghana.  In this case, an editor with no grounding in the subject is likely to make mistakes. 

The problem is that Wikipedia is based on consensus, and you may find yourself editing a page on Wikipedia where you have to build consensus among anonymous people, people that may or may not have ANY understanding of the subject matter.  And those people can be nice, or cruel, with no consequence.  There is no one in the crowd next to them ready to elbow them for making an outrageous statement… because the other editors don’t know if the statement is outrageous!  You can build credibility on how well you enforce the rules, and then use that credibility to attack someone, and no one else can tell the difference.

Anonymity: Handle With Care

I’m of the opinion that anonymity on the Internet has to be handled with care.  There are times when it is necessary, especially when attempting to avoid governmental or organized oppression to free speech.  On the other hand, there are times when it is a license for ill-informed people to promote nonsense as a consensus.  After all, one third of Louisiana Republicans have been misled into thinking that Obama is to blame for the poor response to Hurricane Katrina.  I can think of a other examples of an ill-fated consensus among the ill-informed, but rarely one so laughable.

I believe that Sites and Apps should not leverage anonymity as a feature.  I make exceptions for Tahrir Square and Occupy Wall Street, etc, where rumor may be the only information you can trust, but that is not what these apps do. For normal social interactions, anonymity is actually a problem.  On Wikipedia, I believe that anonymity has outlived its usefulness. 

9 years, 8 months ago

Ten Ways to Kill An Enterprise Architecture Practice

by

Have you seen practices that you know could kill an Enterprise Architecture practice?  I have.  A recent LinkedIn thread asked for examples, and I came up with my top ten.  I’d love to hear your additions to the list.

How to screw up an EA practice

  1. Get a senior leader to ask for EA without any idea of what he is going to get for it. If necessary, lie. Tell leaders that EA will improve their agility or reduce complexity without telling them that THEY and THEIR BUSINESS will have to change.
  2. Set no goals. Allow individual architects to find their own architecture opportunities and to do them any way they want.   Encourage cowboy architecture.
  3. Buy a tool first. Tell everyone that they need to wait for results until the tool is implemented and all the integration is complete.
  4. Get everyone trained on a “shell framework” like Zachman. Then tell your stakeholders that using the framework will provide immediate benefits.
  5. Work with stakeholders to make sure that your EA’s are involved in their processes without any clear idea of what the EA is supposed to do there. Just toss ’em in and let them float.
  6. Delete all the data from your tool. Give no one any reason why. You were just having a bad hair day.
  7. Get in front of the most senior people you can, and when you get there, tell them how badly they do strategic planning.
  8. Change your offerings every four months. Each time, only share the new set of architectural services with about 20% of your stakeholders.
  9. Create a conceptual model of the enterprise that uses terms that no one in the enterprise uses. Refer to well known business thinkers as sources. When people complain, tell them that they are wrong. Never allow aliases.
  10. Every time you touch an IT project, slow it down. Occasionally throw a fit and stop an IT project just for fun. Escalate as high as you can every time. Win your battles at all costs.

Your career will be short. 🙂

10 years, 1 month ago

Has in-person communication become the unwilling victim of technology?

by

In Enterprise Architecture, one of the most important aspects of the job is not only to communicate, but to lead change.  In other words, it is great to have the data to point to a problem in an enterprise.  It is better to help that enterprise overcome it by changing something (processes, technology, training, staff levels, departmental structures, roles and responsibilities, artifacts, governance mechanisms, etc).  Change requires more than simple communication.  It requires a kind of in-person, face-to-face, listening and hearing and absorbing interaction that is difficult or impossible over written mechanisms like e-mail, word documents, and powerpoint presentations.

Our technology has led us to the point, in modern business, that we consider outsourcing and remote work to be a net benefit for all involved, but each of these “distance” mechanisms introduces the RISK of poor communication.  That risk is magnified when the person on one end of the line is hoping to change something that the person on the other end is doing.  Change is harder across distance, and that difficulty becomes magnified when dealing with the array of different interactions that are needed at the enterprise level.

I wonder if the PC revolution, that brought us personal access to written communication, has created a deep reliance on written communication in corporate processes.  I wonder, further, if that access to technology isn’t directly harming our ability to look a person in the eyes and communicate with them.

As a culture, we have moved from the age of face-to-face all the way to text-messaging-someone-in-the-same-room in the course of a single generation. 

Enterprise Architecture is more difficult because of this shift in communication patterns.  All forms of face-to-face communication are hampered by it.

Modern technology has done more to damage interpersonal communication than any other paradigm shift in human history.

This worries me.

10 years, 9 months ago

Podcast on the Enterprise Architecture profession–Interview with CIPS’s Stephen Ibaraki

by

Way back in April, I announced the first of two podcasts with the Canadian Information Processing Society.  I just realized this weekend that I had not announced the availability of the second of those podcasts.  Error corrected.

The second podcast, once again hosted by the inimitable Stephen Ibaraki, focuses much more on the growth and progress of the Enterprise Architecture profession itself.  Specifically this podcast reflects upon:

  • The role of Business Architecture in Enterprise Architecture?
  • Does an Enterprise Architect have to be able to discuss technical issues like cloud computing?
  • How would you define Enterprise Architecture?
  • The value proposition of the Enterprise Architect?

 

For full details, and a link to the podcast, visit the Canadian IT Manager’s Connection, a TechNet site. 

10 years, 9 months ago

Speaking at TechEd New Zealand on Business Architecture

by

Haven’t  been to New Zealand yet, but I will be there soon… From September 4 through 7 in Auckland, for TechEd New Zealand.  I will be presenting two topics (Business architecture for non architects, and Aligning IT with capabilities).

Now, normally you wouldn’t see Enterprise Architecture topics on a TechEd calendar.  However, in the NZ market, there just isn’t the demand for multiple Microsoft conferences every year.  As a result, all the conference demand is bundled up into TechEd.  Due to the efforts of Terry Chapman and the hard working architects in Microsoft New Zealand, the TechEd conference there has developed quite a reputation for hosting an advanced architecture track. 

I’m fortunate to be attending and presenting.  If you live or work in the region, I’d love to see you at TechEd New Zealand.  If you would like to see more information about the sessions at TechEd NZ, click here.

10 years, 11 months ago

Conversational Antipatterns on Message Boards

by

Architects argue.  I have, over the past year, spent a good bit of time on LinkedIn Message boards.  I’ve watched a lot of people argue.  I’ve learned a great deal about Enterprise Architecture, and a few things about myself, as I’ve compared notes with individuals who have different perspectives and motivations. 

That said, some patterns have emerged, good and bad, for conversing with other architects on these message boards.  In the spirit of the GOF Design Patterns, and the subsequent work on Antipatterns, I’d like to point out some of the antipatterns I’ve noticed repeatedly on the boards, and in each case, these antipatterns cause some level of anxiety.  This is borne out by observing the responses, where frustration is often explicit.

There are nearly always two roles in this kind of argument.  The provocateur ( a person who makes a statement that is challenging or innovative ) and the responder ( a person who responds in a way that triggers the antipattern behavior ).  

Conversational Antipatterns

  1. Don’t misrepresent me with my own words
  2. The problem with your general message is this specific use of a word
  3. If you don’t understand, you should read my published papers
  4. My argument has been validated with my years of experience, so you must be wrong
  5. My certification means more than you think it means
  6. You are using “my” terminology wrong

 

Antipattern 1: Don’t misrepresent me with my own words

In this antipattern, the provocateur will make a statement that appears to conflict with something that they said previously or said in another discussion.  If the responder points out the conflict, especially if done with a direct quote, the provocateur get’s offended and becomes defensive.  Conversation ends.

How to avoid: People are inconsistent but believe that they are quite consistent.  If a provocateur appears to be inconsistent, the responder should simply ask for follow up details.  Don’t pounce in public.  Find out what their real underlying thinking is, rather than picking at words.  If they remain inconsistent, the responder should reach out in private.  In the private message, the responder should point out the text from the other thread and ASK them to explain how these two positions work together. 

How to address: The forum moderator should look at the value of the conversation.  Has the provocateur added useful thinking?  Has the responder?  Normally, the answer to both questions is “yes.” If so, send a warning message to both asking them to assume positive intent and consider the emotional context of the other.

Antipattern 2: The problem with your general message is this specific use of a word

In this antipattern, the provocateur will make a general statement designed to express a “grand idea.”  The  responder will either agree or disagree (usually the latter) but then point out that a particular word, in the response, was used incorrectly.  Perhaps they said “process” when they should have said “capability.”  Perhaps they said “activity” when they should have said “process, activity, and practice.”  Perhaps they said “business” when they should have said “enterprise.”

How to avoid: The responder should start by stating whether they agree with the main idea, or not.  If they disagree with the main idea, offer a reason “why” that has NOTHING to do with the detailed wording.  Take the time to think about what the big idea is, and follow up to understand it, before focusing on a word.  Disregarding a “big idea” because you disagree with a minor distinction in the wording is frustrating to everyone on the community, and stifles the sharing of ideas. 

When you get to the point where you understand the big idea, the responder can offer a suggestion to improve the understanding the idea.  For example, “I agree with your core concept.  It appears that we have similar experiences and I find your description innovative.  It may help, as you go forward to share this idea, if you are careful about the use of the word “zyzzix” because I understand that word to be a synonym of “fryzzam.”  I understand that you make a distinction between these terms, but not all of your audience may agree that these two terms are distinct.  You may find it easier to reach people like me if you use the term “golozarat” instead to refer to this muddy concept.”

How to address: Either of the participants can pull back and “get to the point” by reframing the “grand idea” and ask if the other person agrees with a simple “yes” or “no” answer.  If no answer is forthcoming, no learning is happening.  If you are asked to consider a new big idea, take some time before you respond to think about that idea.  Be willing to learn and grow, not just pontificate.  My father used to say, “sometimes, the best way to open your mind is to close your mouth.”  It’s good advice.

Antipattern 3: If you don’t understand, you should read my published papers

In this antipattern, the provocateur will make a specific statement that appears well thought out, but may be innovative or controversial.  When the responder asks questions for follow-up, the provocateur replies “I explained this in rich detail in my book” or “please read my paper in the Journal of EA Innovation, September 2005, page 14.”  This generates frustration on the part of the readers who cannot hear the full discussion because some of it exists in a book or article that they may not have access to.

How to avoid: First off, if you are an author, you must realize that publishing a paper or book does not give you the right to force others to read it before speaking with you.  You will never be out of the “business” of educating others in your ideas.  Get used to it.  Getting defensive is counterproductive.

To avoid creating frustration, it is OK to point others to your work, but then ALSO offer a summary of what you said in that work and be willing to continue to discuss the problem in the forum.

How to address: When this happens to you, it is probably safe to assume that the author you are speaking with is looking for some validation.  Compliment him or her, and ask them to provide a summary of their thoughts from the book or article so that progress can continue.  If you are a moderator, and one provocateur does this a lot, or gets defensive when others DON’T read their articles, remind them privately of this antipattern.  If they persist, suspend them from the board for 30 days.

Antipattern 4: My argument has been validated with my years of experience, so you must be wrong

In this antipattern, the provocateur will make a statement that appears to be too directive or too specific for others to understand or agree with. If the responder challenges the position, the provocateur claims that their “years of experience” have found their position to be true.  The provocateur remains unbending, and repeatedly argues against any alternatives.

How to avoid: This is tough to avoid.  People form their own mental models of reality and when challenged, they can listen to alternatives, or defend their model.  The problem with listening to alternatives is that it is risky.  They may discover that a past “success” was not as successful as it may have been.  In the words of my friend Jack, “their ears are filled with their ego.”

Often the best way to avoid the problem is to model good behavior in your own contributions.  When posting an opinion, lead with “in my opinion” or “in my experience.”  Use phrases like “I’ve found this to be true in my situation,” and then ask others to share “their situation.”  That way, when someone does respond with a statement like “you are wrong,” you can follow up with a moderation message, like “I believe that our experiences may be different in this respect. I’m glad that you shared your experience.  Can you tell me how we should reconcile our two different sets of experiences to come to a mutual understanding?”

How to address: Usually the best way around this is to respond as above, asking for a common understanding.  However, if that doesn’t work (and it often will fail), then you have no leverage to “require” someone to change their opinion.  Ask if it is OK for the two of you to “agree to disagree” and move on.  There is no point in discussing the same issue over and over.

Antipattern 5: My certification means more than you think it means

In this antipattern, the provocateur will state that a concept that he or she is fond of, applies to the discussion at hand.  When the responder questions the concept, the provocateur responds that they are “certified” or otherwise demonstrably educated, and their certification tells them to use that concept.  Upon inspection, it is clear to all that the certification in question does not cover the same scope as the provocateur claims it does.  An example would be an IT person, certified in the development of software interfaces called “SOA Services,” claiming an understanding of business services or customer services.  Another example would be a person with substantial training in financial risk management claiming that all business decisions in the enterprise begin, and end, from a risk management viewpoint.

How to avoid: As with most of these antipatterns, we have a situation where the ego of one or more of the people may be getting in the way of open communication.  The “certified” individual may, in fact, have broader experience than their certification prepares them for.  However, there is often a predisposition, among those that have been formally trained in a field, to believe that the training describes the world “as it is” rather than the world “as it should be.”  More often than not, the training is simply out of sync with the reality on the ground.

As a result, of the “ego factor,” this antipattern is somewhat inevitable.  It will occur more in some areas than in others.  Unfortunately, in the EA field, it occurs often because of the explosion of certifications and the lack of consistency among the field participants.

How to address: One good way that I’ve found to address this problem is to point out your own experiences, using words that reflect that you are not dictating some universal truth but rather the experiences you’ve actually had.  Use first names of people (replace the actual first names, to protect your friends), and explain how they used the terms and concepts of the space.  Then describe how you worked in that situation.  Try to use successful scenarios to lend credibility to your position.  You want to help them to see that their position may not be universally true.  You don’t want to prove them to be wrong, because that would simply be your ego trying to stomp on theirs.  There are names for this kind of ego-vs-ego behavior.  Avoid it.  It hurts your credibility to engage in it.

Antipattern 6: You are using “my” terminology wrong

In this antipattern, the provocateur will state that a concept has one, and only one, meaning.  The responder suggests an alternate meaning, and the provocateur responds defensively, citing sources for their definition of the term.  This is where you see a “dictionary grudge match” where someone cites a definition from an authoritative source, and another person responds with either ridicule of the source or, even better, another authoritative source with a conflicting definition.

How to avoid: Firstly, if someone questions your use of a word, don’t immediately go hunting for a reference definition.  In other words, model good behavior.  Admit that your definition, regardless of how well sourced it is, was created by other (fallible) people with a particular context in mind. It is entirely possible that the provocateur also has a different context than you, and that the author of the definition that you are painstakingly citing would have created a different definition if he or she had the same context as the provocateur.

Of course, if someone asks you for a reference, it is perfectly appropriate to give one on a message board.  In writing a research paper, you would assume that the reader wants to know your sources, and you would always provide them, but for conversation on a message board, you should wait to be asked.

Secondly, don’t be “possessive” about the terms that you use.  Your openness will reduce the likelihood that others will be possessive about the terms that they use.  If someone wants to use a synonym, agree. 

How to address: One good way that I’ve found to address this problem is to ask the provocateur for their help in explaining their terminology to you.  Most people will be flattered by the request, and will go out of their way to describe what their use of a term means.  If you respond by “reframing” their statement, using a smattering of your own terminology, then you will quickly discover whether that person is interested in conversing with a shared set of terms, or if the conversation can only proceed by acquiescing to their use of language.  If the latter, it becomes a judgment call, on your part, about whether you should continue to interact at all.  It is better to end a discussion on a good note than to fight on forever over the meanings of words.

—-

That’s my list.  I’m sure that there may be more, but these are the ones that crop up often enough for me to want to write about them.  I hope this is helpful for folks who want to discuss things on message boards, like LinkedIn, without becoming entwined in endless arguments.

11 years, 24 days ago

On the road to a Business Architecture Manifesto

by

One very powerful metaphor that has reverberated throughout the technical community, in the past few years, was the Agile Manifesto.  Created by a group of folks who wanted to communicate the principles that drove their thinking, the Agile Manifesto has been a very useful tool for deciding if a particular practice is being done well.  I think it may be time to build one for the Business Architecture space.

That said, I am by myself, sitting in my living room.  I am in no position to speak for the community of business architects.  So, this submission is a suggestion for content that could be useful when the conversation begins.  It is my personal opinion about the principles of business architecture.  I would hope to bring this material to a group of other BA practitioners, as my contribution, to develop a full consensus on business architecture manifesto.  

First off, in order to develop principles for business architecture, we need to describe the problem that we are trying to solve. 

The problem that business architecture solves

Business architecture is a relatively new field that addresses an old problem.  Most business people recognize the underlying truth: the structure and practices of your organization directly impacts your ability to deliver the intended value.  Whether we are talking about a military service, a civilian government agency, a non-profit organization, or a for-profit business, the structures and processes that a leader chooses to employ will impact the results that the organization will produce.  That includes both intended and unintended results.  So the basic problem is this: how do we deliver on our mission while maintaining our values?

Business architecture gets to deal with a slice of that problem.  As people, we need to organize around a common shared mission.  We need to know what we want, and we need to go get it.  Humans can be pretty haphazard.  Business architecture does not address every issue.  Business architecture attempts to answer this question: what is the optimal way to organize?  Business architecture typically does NOT answer questions around the integration of corporate controls, or supporting activities like how to find staff to fill new roles.  Business architecture is focused on the narrow slice of “how to organize.” 

So why do we need business architecture to solve this problem?  There are literally hundreds of good, well researched, books that offer useful insight for solving this problem.  Why use a business architecture approach?  Because BA brings a novel approach, one based on the rigorous application of conceptual traceability, process improvement, information science, and mathematics.  While most of the business analysis methods prior to business architecture were founded, fundamentally, in social science, mechanical engineering, and even education, business architecture focuses on the newer sciences that have emerged in the computerized age. 

How does business architecture solve the problem

Business architecture’s unique value proposition is to focus on answering the questions of business structural and organizational effectiveness in a way that is rigorous, quick, clear, consumable, and value-focused. 

We are uncovering better ways of developing business insight by doing it and helping others do it.  Through this work, we have come to value:

Consistently reusable methods over Piecemeal assortment of best practices

Rapid insight over Deeply accurate models

Clear choices over Nuanced decision trees

Consumable deliverables over Consistency with external frameworks

Value-driven prioritization over Justification of the status quo

 

That is, while there is value in the items on the right, we value the items on the left more.

 

To break that down:

  • Repeatability, Reuse, and Rigor.  There are many ways to understand a business.  Business architects will expect you to pick one of those ways (one conceptual model) and then stick to it.  The rigor comes from sticking to the model.  If your enterprise is focused on creating a smooth customer experience, then the business architect will leverage the customer experience work done elsewhere, and will drive a business stakeholder to follow along rather than make something up.  While products must be creatively and freely developed, the organization itself must be architected and engineered.  Rigor matters.
     
  • Rapid Insight. There are many ways to analyze a business.  Business architects will work to reduce the overhead of their analysis methods so that they can produce valuable answers in a very timely manner.  Business people are not rewarded for taking a long time to do an excellent job.  Most will be better rewarded if they do a reasonably good job in a shorter timeframe.  While accuracy is great, the value of information is inversely proportional to the time needed to produce it.  Speed matters.
     
  • Clear Choices. If a business person cannot tell what the recommendation is, they won’t follow it.  If the business architect cannot produce insight that is clear for the business stakeholder, the architect will not effect change.  It is not good enough for a business architect to be quick and correct… they must also be clear. 
    The amount of information, and the coarseness of the decisions, depends on the level of the stakeholder.  At any level, a decision maker should be provided a short list of options (often 2 or 3) where the distinctions between them are clear.  This rule applies at all levels of the organization.  One strategy from a senior manager may require a choice among three different tactics for a department head to choose from.  No one person needs to be concerned with the entire decision tree, except perhaps the business architect himself.   The ability to make decisions is proportional to the clarity of the choices.  Business architecture favors clarity over nuance.
     
  • Consumable Deliverables.  In order for business architects to be successful, they must deliver a plan for the execution of business strategy.  That plan has to be something that the impacted stakeholders can understand and use.  In other words, the output of business architecture must be consumable.  Reams of technical detail are rarely useful.  At the other end of the spectrum, vague goals and promises of value may be just as inappropriate.  Recommendations must be provided using words and metaphors that the actual impacted business stakeholders understand.  They must be provided using forms and templates that the existing organization will recognize and can quickly use.  While consistency with frameworks and practices are important, business architects value consumability more.
     
  • Priority based on Business Value.  Business architects can spend their time on many tasks.  In addition, they can recommend that the organization spend time on many tasks.  Sometimes, even an efficient use of business architecture would be a waste of time if the resulting advice is unlikely to deliver strategic insight.  The selection of tasks, which to do now and which to do later, is of critical importance to a business architect.  While all supporting tasks can be justified, business architects will give priority to tasks that directly lead to actionable, consumable, value-driven business advice.

 

I’m always looking for insight and feedback from the community, so please feel free to add your comments. 

Please note: if your comment is long, the software will sometimes have trouble.  Write it in notepad or Word first, and then cut and paste into the comment edit window.  Don’t be afraid to send it more than once.  I will delete duplicates.  If all else fails, e-mail your comment to me and I’ll put it in.