Improving EA Communications through Social Technologies

Improving EA Communications through Social Technologies

If there’s one thing in EA that can always be improved upon, it’s communication with stakeholders. Misunderstandings, confusion, frustration, arguments, and disagreements – all of these can result from poor communication. Social technologies offer many opportunities to improve EA Communications. In this blog I’ll outline some of the practical uses of social technologies that have been used by EA teams whom I have worked with.

EA initiatives generally involve a wide range of diverse stakeholders. Keeping in touch with each stakeholder, and making sure that they are up-to-date with progress can be a daunting challenge, and this task often drops to the bottom of the list – falling victim to the many other daily pressures faced by the typical architect! Sending emails, holding meetings, and distributing documents remain the basis for a majority of EA communications, but each of these options requires a high-degree of preparation and effort.

We are told repeatedly, for example in the TOGAF documentation, that architects must tailor their communications to meet the exact concerns, views and viewpoints of each individual stakeholder. And to some extent this is sound advice, and necessary. But it is also true that some of the basic information that architects need to pass on to participants is very similar. And with a good understanding of stakeholder needs, it is possible to produce standard views that explain architectural evolution to a broad range of stakeholder types.

Not surprisingly then, a blog is an excellent communication tool for passing on this common information. But a blog can easily become irrelevant or boring, and it can then get ignored by the very people who should be reading it! So here are some tips on keeping your EA blogs focused, relevant, and compelling!

• Keep a separate blog for each project, or make sure that there is simple filtering so that readers only get to see the posts that are relevant to them.
• Don’t go off at a tangent. Don’t include posts about things that are irrelevant. Keep social events and personal commentaries off of the EA blog.
• Spell out the reasons for subscribing and reading the blog posts. If there is a post about a delay to a new release of the architecture, explain exactly what this means to your broad blog audience. If you are writing excitedly about a new pattern that you have defined to solve a business concern, then state clearly how it achieves this, and what the benefits and consequences are.
• Make any diagrams and charts readable and appealing. Simplify complicated architectural graphics down to the key message and key points. Produce things that can be easily copied and reused by each of your stakeholder groups.
• Consider having a professional graphic designer on the team; someone who really understands how to make powerful communications and deliver a powerful message.

Another frequent problem faced by architects is having access to enough of the right information about EA components or how they are used. The traditional way to do this is to talk and to and have meetings with subject matter experts, business users and customers to find out what they know, or how they make use of the architecture. All of this can be very time consuming, and there is a risk that you may not invite the one person who holds the key knowledge. A good solution here is to use a wiki.

I know of several EA teams that have set up either a general wiki for gathering EA knowledge, or a specific wiki to capture things they need to know for a single project. Here are a few examples:

• An EA team were tasked with simplifying the process landscape, following a series of mergers. Without an up-to-date catalogue of all process components, the first task was to gather this information. They set up a wiki, and then invited IT staff, business users, and key decision makers to contribute any information they had about processes. Very quickly they built up a list of all processes, which were then used to prioritize changes.
• An EA team lacked detailed knowledge about some critical applications. They published the information that they had, which was often from documentation that was five to ten years old. They then encouraged subject matter experts to update this information. It only took a few weeks to make a significant improvement.
• An EA team were continuing an ongoing program to be more service oriented. This work covered a variety of architectural component types, including systems, application, modules, services, functions, and capabilities. A major problem was that different stakeholders had a different definition for some of these items. For example, the operations team referred to “systems” which were “applications” to the developers and “functions” to business users. They used a wiki to map the relationships between components and these various stakeholders. Again the process was much quicker than trying to capture the same information using meetings or interviews.
• An EA team had captured a lot of project information using a wiki. They employed a wiki specialist and a graphic designer to repackage this material and ensure that it was retained in a usable form for future projects.

This leads me to my final example, about sharing EA artifacts. Many EA artifacts are produced for a specific project; once the project is over, they get forgotten, and are never reused. There are several reasons for this: once a project is over time is rarely allocated to harvesting artifacts for reuse; and artifacts can quickly become less useful if they are not kept up-dated.

Instead of wasting valuable project artefacts, an EA team “published” all documentation from a project to a shared artefact library, which was available to many people from different backgrounds within the organization. Everyone with access was encouraged to use the materials, but with a proviso: they were to improve the material as they used it – by adding information, providing better examples, giving more detail, or restructuring the material into a more useful form. To make the library work, the organization introduced feedback mechanisms to rate the usefulness of artifacts, and a bean system to reward participants for their contributions, based on the feedback and ranking of artifacts. At first this approach was quite primitive, but refinements were gradually made to encourage participation and collaboration. The results were impressive. Not all artifacts were reused, but some key models, patterns and diagrams became standards throughout the enterprise. In particular, the approach shifted emphasis away from PowerPoint presentations towards individual diagrams or charts that became “standard” views of key enterprise components. A proliferation of individual PowerPoint decks was replaced by a core set of valued slides that were extensively reused.

Communications can always be improved – and these few examples only scratch the surface of what can be done with social technologies. I hope that they inspire you to use social technologies in your EA practice, and then to share any of your ideas or experience through this blog!