Crosshair Planning And National Security

 

Crosshairs Diagram.jpeg

So I wanted to share this amazing crosshair diagram…


Not because we currently have North Korea in the crosshairs before they hit us with a nuclear-tipped ICBM.


But rather for how this diagram can be used in strategic planning and enterprise architecture. 


The way this is used is the following:


First, you put your goals in the inner quadrants (or other such division of the inner circle).  For example, perhaps you have a goal to reduce your weight which is now 215 lbs. 


Next you create concentric rings around your goals with each ring representing a time horizon. For example, the first ring could be 6 months, the 2nd ring 1 year, and so on. 


Then for each timeframe in the rings, you put what your target is for that related goal. For example, maybe in 6 months you want to reduce your weight to 210, and then by end of year 1 to 205.


In this way, you can easily show your goals as well your targets over various time frames into the future. 


You can similarly use the other quadrants (or other divisions of the circle) for other goals emanating from the center to the future targets. 


Of course, you can also use this for North Korea–to target above the 38th parallel for dropping a good deals MOABs to clear the enemy and their nukes and missiles from threatening the U.S. and our allies.  The same solution goes for Axis of Evil, Iran, and their endless spread of global terrorism and human rights abuses. 


Targets are for restoring the peace and for strategic planning and these two intersect when it’s comes to national security. 😉


(Source Diagram: Andy Blumenthal)

>Presentation Style and Enterprise Architecture

>

User-centric Enterprise Architecture employs principles of communications and design, such as maximizing information visualization in making information products useful and usable to the end-user.

In ComputerWorld , 24 September 2007, Michael Hugos, a principal at the Center for Systems Innovation, presents “Five Diagrams Beat A Victorian Novel.”

The article states: “Consider two methods of collecting and presenting computer system specification [or apply this to presenting enterprise architecture] to users. One is far more likely to result in disastrous development projects plagued by miscommunication and users who are unhappy with the systems that are developed to them.” This disastrous method for presenting IT, Mr Hugos calls the ‘Victorian Novel’ is based on “text specifications for systems development [and] it simply mire readers in a swamp of boring words.”

This method uses Unified Modeling Language (UML)…”they rely on use cases that seem very rigorous yet manage to reduce everything-from trivial details to important processing logic—into a monotonous blur of text that few people can read for more than a minute or two. The only diversions from this text are some abstract charts. UML documents seem to purposely designed to confuse and disengage the typical business user.”

I do believe Mr. Hugos could be equally describing traditional EA “artifacts” that mire the users in eye sore diagrams that cover entire walls or fill boxes and are they typical architecture shelfware that defies general readability, usability, and do not meet end-user requirements for information that adds value!

Mr. Hugos goes on to describe his method for presenting IT information, which aligns beautifully with the User-centric EA approach.

He states as follows: “Instead, I use a method based on the old saying that a picture is worth a thousand words. I use schematics and diagrams that give both business users and developers an easy way to understand the system under development [applies as well to EA].

Here are the five diagrams proposed:

  1. Process flow diagram—excellent, get the processes ironed out before automating, and enable business process improvement and reengineering.
  2. Logical data model—yes, capture the data requirements as the driver for the system solutions to serve up the information.
  3. Screen Map—right on, provide the end-user a storyboard of screens that show how they will interact with the system; that is User-centric.
  4. Systems architecture diagrams—nice, what is the technical infrastructure that underlies the system.
  5. Software object model—not one that I am familiar with, but sounds like it supports systems interoperability. It “defines the processing logic for the custom code and the data interfaces between custom software objects and packaged software.”

The five diagrams that Mr. Hugos proposes “enable effective communication between business and technical people so the system that gets delivered meets user expectations”.

It is truly wonderful to hear about architecture diagrams that are not typical shelf-ware, that help meet user requirements, that add value, and that are based on sound principles of communication. All too often these areas of architecture development are overlooked and at great expense to the enterprise and the end-user!