Welcome Workshop Participants

I've shared this url with my classmates, so maybe we could get some discussion going here, even after the workshop.

Welcome to everyone! And thanks to Dana Bredemeyer for the fantastic workshop!

Jim Klempner took pictures of the wall charts from the workshop. They are now posted here for your use and enjoyment.

Dana suggested we also visit Ruth Malan's blog and that of Grady Booch.

I created a Yahoo group to facilitate/archive storage. It's probably a better forum for discussion (listserv/files) than this blog. Please feel free to sign up. Click here to join.

Or send a blank email to ea_discuss-subscribe@yahoogroups.com.

...

Day 2 - Part II (The Vision)

In order to help stakeholders see a Vision of how strategy can translate into Architecture, the EA can use a Cover Story Vision chart. This is another grahical tool from Grove which can be seen here.

The tool is intended to motivate and create excitement for a particular architecture decision(s) or capability(ies). And to illustrate alignment with an architecture.

On the left of the graphic is a dummied up version of a publication important to the company. The example of the Wall Street Journal was used. The front page would display headlines important to the success of the company. Examples for the Global Broadcast ficticious company included "GB Best Company to Work For in South America" and "Global Broadcast is market leader in innovative technology."

On the right, a page listing the architectures/capabilities required to make this vision come true are listed. In our example, we came up with... "Complete Customer Model (CCM) enables single view of customer. Integrated, Realtime. (Qualities)"

In the chart, you would list quotes from supposed future customers like, "They are amazing!" and "The repair truck was almost in the driveway when I called about my problem."

From this example, we derived two key QUALITIES: INTEGRATED AND REALTIME.

These will be important as we work through the EA toolset using the Global Broadcast example.

Day 2 - Part II (Desired State Interviews)

Stakeholder profiling, detailed in the last post, is a part of gathering Architectural Requirements -- which come before the gathering of detailed requirements...

In dealing with stakeholders, it's best to interview more than less. Many times "transformative" information is available from those closer to the work in organizations (i.e. help desk worker). Err on the side of talking with too many people.

Always ask the question, is the person I am interviewing going to make a *difference* to the EA work?

In addition to Stakeholder Profiling, a Desired State Interview is recommended.

A desired state interview is more personal and focuses on the individual goals of the stakeholder. This is often done with two EA's present in the room with one stakeholder.

The following questions are typical:

1. What do you want? (now/future)
2. How would you like things to be (now/future)?
3. How do you know you have what you want (now/future)?
4. What is valuable to you?
5. What value do YOU get?
6. What value does the ORGANIZATION get?
7. What are key obstacles? What is getting in the way?
8. What is already right with the system? (key question)
9. What else is important to you?

Many things from the Desired State Interview may not end up in your requirements, but they do help the EA to know the stakeholder better. Also, there may be commonality that comes out from multiple interviews that signals additional requirements.

This also helps identify what the triggers are to make the architecture GOOD, RIGHT, and SUCCESSFUL.

This also helps an EA unfamiliar with an organization to understand the organization better (i.e. dotted line reporting relationships, etc.)

The process of gathering EA data is an ITERATIVE process, so stakeholders may be interviewed and the results shared over a period of time.

Day 2 - Part I (Stakeholder Profiling)

Howdy! It's Day Two and we are working on Stakeholder Profiling (using a fictitious company). This is an important part of gathering Architectural Requirements...

Here's the process we are modeling from the EA perspective...

1. Identify Stakeholders (who will have a potential impact on architectural decision-making? Sometimes this includes 'boots on the ground' employees.)

2. For each stakeholder, identify the role of the stakeholder.

3. Identify Business Goals
(someone suggested SMART = Specific, Measurable, Attainable, Realistic, and Timely as a way to define goals)

4. Identify System Goals (more granular)

5. State the "value proposition" for each stakeholder.
(i.e. "Future development will work like clockwork...")

A few thoughts...

This seems to be a step we do informally (and incompletely) as a part of our "system development" at SLU, and I don't think I've seen these things formally documented anywhere in our environment...

There are 15 participants here, many from major companies, but I am the only Higher Education Rep here... it is interesting to hear some of the same development and challenges we see at the University level. There was an informal discussion this morning of how important it is to have a Project Management Office (with some control over resource planning) and a strong Change Control process. Someone mentioned "business change control" which I plan to research later.

More later...

:-)

Day 1 -- notes and thoughts

Hi! It's actually day 2, but day 1 was busy up until bedtime, so here are a few observations from yesterday...

When does an Enterprise Architect get involved?

> When decisions MUST be made first in order to be successful.
> When decisions MUST be made from a whole system view.

**and**

with a MINIMALIST view; only what needs to be done, no more.

EA's should not get bogged down in minor details, unless they are necessary to answer the above questions.

EA's should not be so much of a specific technology advocate, as much as promote BUSINESS VALUE.

The graphic of an umbrella was used with the EA looking at the problem from the top of the umbrella, with functional managers and architects looking at the problem as a "local" issue under the umbrella.

EAs are concerned with BUSINESS CAPABILITIES, which must be a combination of people, process, and technology. They navigate the gap between business thinkers and technology thinkers...

EA Office must interact with strategic thinkers in order to be effective and successful.

In order to have IT alignment with the business, the strategy must be expressed in a way that makes that possible...

The Ideal EA:

1. Must be in "the know" about business strategy and have open lines of communication with the strategy owner.
2. Be involved in enterprise process improvement.
3. Be involved in strategic discussion.
4. Be involved in standards/architecture for corporate data.
5. Have architectural control over key applications.

10% of System Development process should be EA.

The Ideal EA Team should have...

Chief EA *and*
*Chief Business Architect
*Chief Information Architect
*Chief Application Architect
*Chief Technology Architect

EA's should talk about the problems in Business Terms (cost savings, etc.), not in technical terms (duh!).

We also into using a "context map" in order to help develop a strategy. This is a very graphical tool used for "brainstorming..."

(follow up --- go to Grove's website for toolkit... great for facilitate planning and strategy meetings...)

We discussed the structure of a strategy which was described as three circles...

Industry (World Outside)
Competitors (Includes Customers)
Us (Internally)

The visual tools can be used to develop "visions of the future" or scenerios that map and describe trends and forces to the future.

The focus should be on "high impact" and "high likelihood" scenerios

Book References "7 Tomorrows" and "The Art of the Long View" (Peter Schwartz)

Ok enough for now...