Aggregated enterprise architecture wisdom
Nick Malik So, full disclosure, I care about Wikipedia. Call me dumb, I know. Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time. The truth, as always, lies between these extremes. Well, I’m part of a small team that…
I’ve met many Architecture Managers over the years. Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant. The men and women called to serve in this unique role have a distinct, and uniquely important role to play in the success of the Enterprise Architecture function in their enterprise. Yet precious little is said about them.
In this article, I’ll touch one some of the key qualities I would expect to find in a successful Architecture Manager.
As the role of Enterprise Architect matures in organizations around the world, we’ve begun to see the tremendous impact that an effective architecture manager provides. In many ways, the Architecture Manager is the single most important role in the department, but also the most difficult role to fill. That is because, typically, the role is filled by a person who “moves up” from being an Enterprise Architect. Unfortunately, being an excellent EA is poor preparation for this particular role.
An Architecture manager is:
In my travels, I’ve met both good Architecture Managers and not-so-good Architecture Managers. The ones in need of improvement nearly always struggled at one of the above.
Enterprise Architects are rare birds… especially good ones. There are many folks who have worked to become Enterprise Architects, and a few who succeeded in recognizing the uniquely holistic role of an EA. Typically an EA has to manage through influence alone, because it’s rare that an EA has a team of resources assigned to him or her. But an Architecture Manager is in a different position. They do have a team, and unlike other efforts where they could be objective about a business leader’s business processes and functional alignment, they now have to perform architecture on themselves. Sometimes, they succeed.
If you find you need to hire an architecture manager, you’ll need a list of responsibilities for your hiring team. Just copy the following list.
The responsibilities of an Architecture Manager include:
Some of this is pretty obvious, but it’s worth stating anyway. The architecture manager has to be familiar with enterprise architecture. But they also have to be familiar with how things can work in an organization, especially if the focus of the EA program is related to IT (as it nearly always is).
In many cases, people who move into the role of Architecture Manager worked their way to that role as an architect. They may have been a technical architect, solution architect, business architect, or enterprise architect. In many organizations, these roles are deeply technical. Of all the architecture managers I’ve met, the overwhelming majority are technologists.
Unfortunately, most technologists don’t have the skills to focus on the responsibilities listed above. It is tempting to continue to be a technologist once moving to this role. It is also suicide. Your term as the “Vice President of Strategy and Architecture” will be short if you cannot step back and let your team perform the technologies or modeling activities typical of an architect. This means, for the architecture manager himself or herself: No modeling, No coding, No time spent geeking out. (Ok, exception, fiddling on the side is fine, especially if you want to “stay warm” with your technical skills… but nothing deliverable.)
First place is the same as you’d expect for any role: find a person who was successful as an Architecture Manager in another enterprise. Be careful of people who performed but did not succeed as an Architecture Manager. Most folks fail. Find out if the function continued after they left, and if their team enjoyed working for them, and if their stakeholders saw fit to provide an increased level of interaction with their staff members. Look at examples of their teams’ deliverables and ask about their ability to build and maintain new business processes.
Second option is to bring in an experienced architect and let them take on the role. Assuming the team already exists and is well accepted within the organization, this is a reasonable approach. Finding a seasoned architecture manager is extraordinarily difficult, so this may be the only rational option. The person you select should have worked for at least six years as an Enterprise level architect, with increasing levels of responsibility, and should preferably have been a resource manager at some other point in their career. If the program does not already exist, see the next section.
Third option is a seasoned manager who has no experience as an Enterprise Architect. This may be a distinguished technical architect, or the leader of a highly visible program in the past. These folks are expected to bring expert team leadership skills and deep technical skills. The biggest challenge that they will face is being able to adequately learn the role. Unlike most other management roles, the Architecture Manager must be able to SELL the value of the role of Enterprise Architect, and that is extraordinarily difficult to do if the manager wasn’t an architect first. The learning curve is very steep. To pull this off, the Architecture Manager will need a good mentor or an experienced consultant to help guide them through the first year in role.
If you don’t already have a functioning Enterprise Architecture program, your very first hire will be the Architecture manager. This role will be doing a great deal of heavy lifting in that first year. Setting up processes and deliverables. Making sure that the stakeholders buy in to collaborating with those processes. Hiring and situating staff. Creating priorities and managing resources. Setting up measurement and demonstrating value. It’s a tough road to build from scratch while providing value.
The only advice I can give: do NOT build a new EA program around an Enterprise Architect who has never been an Architecture Manager before. That is simply too much for a single person to handle. Going from EA to Architecture Manager of a new program is a huge leap, and I have never seen it be a successful approach in the long term. The person you hire may be a “survivor” who knows how to avoid being fired, but that won’t make them effective. Once they move to another role in the enterprise, the function will likely vanish.
You need the Architecture Manager to be effective. To build a program with lasting value. To build a program that matures over time.
So if you are building a new EA program, build it around an experienced Architecture Manager. Then support them with resources that they did not ask for: (a) an outside expert who can provide a neutral point of view and sounding board as they build and struggle that first year, and (b) Serious “air cover” so that they have the time needed to build the team, create the processes, build support, and demonstrate early value.
The single most important person in the Enterprise Architecture function is the Architecture Manager. This critical role is part visionary, part marketer, part people manager, and part evangelist. They have to change the organization and keep the change from undoing itself. The role of Enterprise Architecture is highly dependent upon the skills and the focus of this key role. Choose wisely.
I’ve met many Architecture Managers over the years. Sometimes they go by the title of “Chief Enterprise Architect” or “Chief IT Architect” and other times, the title is “Vice President of Architecture and Strategy” or some variant. The men and women called to serve in this unique role have a distinct, and uniquely important role…
Organizations do not work, in real life, like they work on paper. On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information. On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.
In real life, there are human beings and the tools that they use. Sometimes the tools move information from one person to another. Sometimes, they just aid in communication. People meet and get to know other people, and they learn to trust some, and distrust others. Some folks have different measures and motivations and just “pass by” one another. Some subset of these people will have shared cultural values and expectations. There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization. Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently.
Reality is a lot messier than pretty rectangles.
Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change. We are unique in that most other “change artists” are not focused on engineering and some even ignore science. (see Daniel Pink’s TED Talk on the Surprising Science of Motivation). Few even know how to spell aesthetics. Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science. Engineering is a mindset as much as a class of methods. It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things. Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.
As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise. We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter.
That is just lazy.
It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures. We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do.
The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at. Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.
We should consider sociocultural information if:
Think about it. Do you believe that any of those statements are false? I can find ample examples for each one. So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?
It’s only hard because we haven’t tried.
(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).
Organizations do not work, in real life, like they work on paper. On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information. On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people…
This is the first time I’ve done this, so I’m hoping that my friends will contribute your opinions: I’ve created a survey asking a few basic questions about how your Enterprise Architecture program is valued, or not valued, by your organization.
KwikSurvey Poll – Does your Enterprise Architecture program deliver value?
Note that this is a free survey tool that doesn’t allow me to collect text responses unless I pay, which I didn’t, so there are no text response fields. If you want to comment on the survey questions or assumptions, please jump over to LinkedIn and comment in this thread:
LinkedIn Discussion – Do you have an effective or ineffective EA Program
All comments are anonymous. I will publish the results on this blog. This is just an informal data collection exercise but one that I think may provide a little insight into how you and your peers measure the value of your Enterprise Architecture program.
This is the first time I’ve done this, so I’m hoping that my friends will contribute your opinions: I’ve created a survey asking a few basic questions about how your Enterprise Architecture program is valued, or not valued, by your organization. KwikSurvey Poll – Does your Enterprise Architecture program deliver value? Note that this is…
We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. This allows a person to live past a mistake. Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”
However, this becomes much more difficult when we consider the emerging Internet of Things (IoT). In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control. That data is called “Information Property.” It is the information that YOU generate, in the things that you do. I believe that if YOU create a bit of information property, you should own it.
That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers. That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system. Most folks will not have any problem with this cloud of data. At least not at first.
Where we will first feel the pain of this cloud of data: when you want to be forgotten.
We have been dealing with “data about you” for a while. When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts. The US Federal Government has placed some controls on this data, but not many. Europe has placed entirely different controls. You have no right to be forgotten, but you do have the right to limit their memory to a decade. That allows you to “get past” a mistake or series of mistakes. But you are always “known.” However, a mistake can be forgotten.
This is a model we can use. Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old. There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally. It is ALL personal data.
This is not (yet) true in the Internet of Things. If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data. It’s the identity of the CAR that is sent, but not the identity of the driver or passenger. That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur. You will be found. And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away. You can’t CLAIM that data because it is not directly linked to you. You don’t own it.
Think this is a minor problem? After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right? Wrong. If we don’t think of this now, privacy will be sacrificed, possibly for decades.
The environment of regulations sets the platform by which companies create their business models. If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money. Once that happens, new regulations amount to government “taking money” from a company. The typical government response is to “grandfather” existing practices (or to protect them outright). No chance to change beyond a snail’s pace at that time.
I propose a simple mechanism. Every time you purchase a device on the IoT, you insert an ID into the device. This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number. You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month. A simple app can create the GUID and manage them. Every item you purchase during that month gets the ID for that month.
Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.
Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc). Is this allowed? Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this. The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult. But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically. Let’s assume that folks can do this NOW and that you will NEVER be able to control it.
Therefore inserting an ID is not giving up control. You don’t have it now.
But it is possible, with the ID, to TAKE control. You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them. Only if you can claim your data can you delete it. By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.
It will no longer be a choice of sending a single message to a single search firm like Google. The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs.
Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense. 90% of the value of information comes from samples of that data of less than 2% of the population. In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin. If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway.
Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India.
Now is the time to ask for these regulations, as the Internet of Things is just getting started. Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition. Customers will trust these companies more, and the data will be more accurate for consumers of these data services.
You cannot delete “information property” until you can claim it. The ID is the claim.
We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. …
(Note: I’ve added an addendum to this post)
It has been many years that we have lived with the concept of technical debt. Martin Fowler did a good job of describing the concept in a 2003 article on his wiki. Basically, the idea is that you …
Many folks frame enterprise architecture (EA) as a function that is necessary because organizations need alignment. In that mind set, the primary value proposition of EA is to create initiatives that are aligned to strategy, are feasible, well scoped, and should result in a fit-for-purpose organization and information infrastructure. In this way of thinking, it is up to the enterprise architect to figure out what trains need to leave the station, where they are going to go, and when they need to arrive. All the passengers have tickets and all the conductors have schedules and everyone is set and ready to go.
Note that I highlighted two words: “create initiatives.” In this view of enterprise architecture, once those initiatives are created, their work is done. Projects teams “drive the trains” and move the people and get the work done.
Source: Train Wallpapers
I have a problem with this viewpoint. Consider this question: Does enterprise architecture “go away” after the initiative is framed, business case is proposed, and the funding cycle is complete?
The answer is emphatically “no.”
You see, the real problem is NOT alignment. It’s execution. Creating a great strategy is tough, but getting your organization to change to meet that strategy is far tougher. Sure, part of that problem is solved with alignment. Alignment is necessary because it gives you the right mix of things to do. It is essentially a planning activity.
But execution is not a planning activity. There are far more screw ups in the execution than in the planning. So if the EA is trying to bring about the changes that an executive has demanded, in order to make a strategic change actually occur, he or she cannot stop when “alignment” has been achieved. The role of the EA has to continue all the way through execution to make sure that the “train” (the initiative) reaches the right destination. That is why, within Microsoft Services, we refer to Enterprise Architecture efforts using a “framework for value realization.”
The train metaphor is problematic because we think of a train as a tightly engineer marvel of modern efficiency running on a pair of rails that are carefully laid out. Initiatives are not like that. Business initiatives are like a train built by monkeys. They are not remotely similar to marvels of modern efficiency. They are noisy, rattling, energy wasting, Rube Goldberg machines that would fall apart at the drop of a hat if not for the efforts of many people, often unsung heroes, who keep everything moving in the same direction.
What’s more, that train is running on a network of tracks that interlock and weave and visit multiple places from different directions, full of dead ends. There is rarely a central dispatching office(PMO) watching over the whole operation and even when there is, it rarely has good information on which to base decisions, reducing it to a status-reporting role. Without oversight and plenty of assistance, the business initiative “train” may end up stalled in some wayward place, abandoned.
Photo: R. Lowsek Source: Uyuni – Bolivia’s Train Graveyard
Enterprise architects have a duty to complete their mission: execute the strategy and realize business value. Creating the schedule and planning the route is not enough to deliver business value. An enterprise architect must actually ride the train (or watch to make sure it moves through a particular set of stations). He or she must listen to the rattles it makes as it switches from one direction to another, evaluate the alternatives of design and implementation, and consider whether the train is carrying too much or too little cargo (scope) for it to handle. Most importantly, an enterprise architect must be focused on making sure that the train, upon reaching the destination station, actually delivers value when it gets there.
All too often, a train (project) will drop scope or change course along the way. It may get to the right station, eventually, but along the way, the conductor had to lighten the load, so he dropped a few cars. The conductor (project manager) declares success when the train hits the station. To him, it doesn’t really matter if the time delay caused by the “Left Turn at Albuquerque” meant that the cargo missed its connection.
According to project management professionals, it is up to the business stakeholder to make sure that the value is delivered properly. The enterprise architect has nothing to do with it, right? The twist is that the operational business stakeholder rarely cares about the enterprise perspective. He or she may be interested in “local success” that can be reached, regardless of the compromises taken along the way. In this case, both the project manager and the business stakeholder declare success, while the actual value needed to reach the strategy is lost.
So success leads to failure. The train gets to the right station, perhaps even “on time,” but without actually delivering the value. The wrong cargo is delivered or it was left behind along the way. This describes countless “business initiatives” that I’ve seen over the decades. It’s so common, we have a term for it: watermelon project (green on the outside, red on the inside). Maybe we should call it a “dead strategy walking.”
A business initiative is not a smooth, well oiled machine. If it were a machine, it would be a train built and operated by monkeys. Parts would fall off, or be added on, for reasons unexplainable, and the direction taken would depend on the whims of political decisions that can seem arcane and undecipherable on a good day. Getting an initiative going is not the hardest thing you will do in your life. Far tougher is riding atop the initiative train, making sure that it doesn’t do really dumb things, or fall off the rails, and gets to the actual intended destination with the value proposition intact.
An enterprise architect is an invaluable element for ensuring that business value is actually realized from an initiative. An EA will collect metrics, prior to the initiative, that illustrate both the problem to be solved and the various other measures of productivity and business value that could be impacted as the program proceeds. He or she will do more than just collect and report on value realization. He or she will use the opportunity of collecting this information to guide key decision makers towards decisions that maintain enterprise value and away from decisions that diminish enterprise value.
The enterprise architect, in the best case, is involved in key decisions through this oversight process: how processes are to be changed, where activities (both operational and change focused) should occur, how people will get ready for change, how the change will be orchestrated to ensure that operations don’t lose value, what information will be leveraged, what systems will be impacted and in what way, what lifecycle considerations must be taken into account (both service, information, systems, and technology life cycles), and what dependencies will be created or relinquished. In most of these decisions, the EA is not the final decision maker. He or she is there to provide the “enterprise perspective” and argue on behalf of senior leaders whose strategy may be impacted. In a best case decision matrix, an EA would be able to escalate a disagreement to a governing board that includes a broad array of enterprise stakeholders.
The role of an Enterprise Architect is focused on much more than simply “aligning initiatives to strategy.” They are also called upon to oversee those initiatives as they proceeds through execution, and to advocate on behalf of the enterprise all along the way. Let’s recognize that a plan has no impact on an organization… only the initiative that follows the plan (or not) can change things. When the Enterprise Architect oversees these initiatives, he or she has the opportunity to fulfill their promise to execute strategy and realize business value.
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.
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.
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.
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.
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.
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.