Friday, September 03, 2010 ..::  » Home ::.. Register  Login
  Polymer Clay 

Due to my better half.


Just go to her store and make your call if she's gifted :-)


1.4.2009 027 by Roni Gur


Roni Gur Etsy Store


23.3.2009 062 by Roni Gur

Current Articles | Categories | Search | Syndication

Sunday, September 27, 2009
Communicate highly complex information to a broad audience
By Host Account (host) @ 2:40 AM :: Article :: 0 Comments :: 608 Views

One of the common tasks that enterprise architects are dealing with on a daily basis is the need to explain complex IT issues to different audience, including non IT audience and CxO level. I can find many discussions around this requirement but I can hardly find any best practices or advices. In this post I'll try to share my experience and knowledge and I'll be happy to hear other experience as well.

The are 5 main principles that I follow when I have to prepare for presentation of complex domain information for non domain members.

  • Focus: I started to use this technique when I had to present to CxO, due to time restrictions that usually coming with those meeting, But I'm using it for any audience now. This technique enforce you to deliver 3 main messages to your audience, No more. The Idea is to create a matrix of 3 rows and columns. Each first column in each row should present one message that you want to deliver and the two following columns enable you to extend a little bit your message. This is quite challenging since it takes time to find out what are the main 3 messages that you want to deliver and to sharpen you message into 3 slides. The benefit is that you're coming focused to the presentation and you won't find your audience bored.  Focusing also yields simplicity.
  • Visualization (and animation): A picture is worth a thousand words. When I need to show complexity or to show some Ideas that are based on huge amount of data, I'm always looking for a way to show the message in a graphical way.  Two examples here. In the first one I want to show that IT is really complex to our CEO. So I took all of our IT assets and grouped them in to four main domains. On top of this grouping I added all mapped relationship between IT assets. The result was a jungle of dots and line. The message was transferred and accepted very fast and easy.

    The second example was about transferring the message that we're building an IT structure that will be based on shared and reused services and components. In this case we created a pipeline with two levels, external that demonstrate projects work that needed to be done to create overall business solution and internal level which represent all the common services and components. We use animation to enlarge the internal level and minimize the external layer to  demonstrate what we pursuing. We also split the internal layer to several segments the explain what type of services we want to provide.

       

 

  • Examples that everyone knows from life. I think that the most common example here is the usage of city planning when expanding enterprise architecture. People know and understand city complexity and can easily relate enterprise architecture to it.


 

  • Example from enterprise business domain. This principle works mostly when I have to present something from IT world to Business domain (VP, SVP, CxO).  The idea here is to take business example that demonstrate the same problem that I want to discuss from IT domain. If for example I want to explain the need to create MDM, I would ask the CEO if he can manage the company if any division has it own number and definition to the same product that we're selling (same product has different catalog number in different unit of business).
     
  • Break and abstract: If I have to present something that it complex and contain a lot of information (how to identifying needed, existing and missing services) , I tend to break it and abstract it as much as possible. The first thing is to break the complex idea that I need to deliver in to a list of topics ordered by relations between them. When Finalizing with the list and dependencies I can start presentation from high level process that shows what we up to. Then I'll address each entry in the list and summarize the presentation with the process again.

I hope that I didn’t miss any principles that I'm using, But what about you? What are the principles that you're using to deliver complex messages?

Comments
Currently, there are no comments. Be the first to post one!
Post a Comment
You must be logged in to post a comment. You can login here.
  Account Login 

 

  EA & IT strategy related posts 

EditHow to retire (respectfully) legacy systems
EditInformation Architecture - The bridge between Business and IT Business Capabilities and Business Strategy
EditConsolidation of CRM solutions
EditCreating IT strategy (with a little help from enterprise architecture)
EditEnterprise Architecture Meta-model, size doesn't matter
EditEnterprise architecture work Case studies
EditUsing Enterprise Architecture for forecast and implementation of Merges and Acquisition(M&A)
EditUsing Enterprise Architecture to reduce IT costs ( a cookbook for IT cost reduction)
EditBusiness Capabilities (a practical guide)
EditUsing enterprise architecture for creating long term IT planning (roadmaps)
EditWhat can be done with enterprise architecture
EditPrinciples as enterprise architecture outcome
Editblueprint - an enterprise architecture outcome
EditHow to build practical enterprise architecture team
EditModeling application dependencies
EditCan enterprise architects be young?
EditUsing Hungarian Cube to demonstrate enterprise architecture
EditEnterprise architecture frameworks are dead, long live real-life practice !
EditIT('s) Simple!
EditHow to do inormation architecture (in 20 days)
EditWhat really makes you Enterprise Architect
EditInformation Architecture (What need to be collected and modeled)
EditInformation Architecture (What is information architecture)
EditEnterprise Architecture in SAP world
EditSorting SA diagrams by EA domain
EditReference model for EA definitions and views
EditWhat I expect from a vendor EA framework
EditBusiness concept
EditWorktures
EditIt's not SOA it's IT 2.0
Edit10 standards (including standard de facto) that Enterprise Architect should know
EditProven way to run your Enterprise Architecture practice
EditThe triangle of complexity and the square of success for EA projects
EditWhat is a service (part II)
EditHow to publish your EA work
EditSOA implementation types, from the Chinese city to the European city
EditWhat is a Service
EditThe utopia of one dictionary for the enterprise
EditHow your IT chassis will look like - Part 1
EditAre your IT vehicles based on one chassis?
EditEnterprise architecture modeling example
EditEnterprise architecture is just another systematic approach
EditSOA, It’s not about the IT It’s about the Business.
EditBusiness capabilities or business processes
EditThe Data-Centric Enterprise: A Blueprint for EA - Listen to the audio and watch the - slides! (Running time: 59 minutes)
EditDoes enterprise architecture serve only for long term strategic plans?
EditIntroducing NAAF.
EditUsing enterprise architecture framework to map services and set their granularity
EditThe “Natty” method for monitoring and encouraging systems compliance with the - enterprise architecture
EditWhat are Enterprise architecture patterns and how we should define them?
EditEnterprise architecture 10 common myths
Copyright 2002-2004 Natty Gur   Terms Of Use  Privacy Statement
Portal engine source code is copyright © 2002-2010 by DotNetNuke. All Rights Reserved