This whole post is from a comment I just made on the discussion board on the LinkedIn group Business Architecture Community.

In a value network, value is seemed to be created in a series of chained events where each contributing party creates a set of specific values to it’s closest receiver. This hints on the fact that value can transform in several dimensions (type, size, quality, importance and time) as it change hands. It also hints on the fact that you should focus your effort on creating value for the closest receiver.

There are excellent work done on this by several people and here are a few:

http://www.cs.vu.nl/~zderzsi/current/busital06.pdf more from Jaap Gordijn + the e3value tools and framework can be found at http://www.e3value.com

On the blog http://business-model-design.blogspot.com/ Dr. Alexander Osterwalder explains and elaborates on his methods for business model design and visualization.

I’ve use this notion of networked value to realign, build and strengthen teams.

Guidelines to Good Coaching Practice for Enterprise Architects

1. Always putting the success of the participants first
2. Treating all participants equally, and with respect and dignity
3. Help build balanced relationships based on mutual trust with management which empower participants to share in the decision-making process
4. Making enterprise architecture fun and enjoyable, and promoting good quality standards
5. Keeping up to date with knowledge, skills, qualifications and markets
6. Get to know the the participants management and their goals with the coaching
7. Being an excellent role model
8. Giving enthusiastic and constructive feedback
9. Recognising and honoring the developmental needs and capacity of the participants and their organization not pushing them against their will

I have been working on a way to let teams experience enterprise architecture and enterprise engineering in real life. I’ve looked into using traditional building architecture, abstractions on factories and production lines, even looked into training marathon runners. The one and only way I have found to actually get to the point is working with Lego. I think the tactile feeling of the blocks ads a tremendous advantage over any other learning experience.

Basic chain of events
Idea->Sketch->Design->Engineering->Construction->Use

Idea
Start with generating the idea, there are many ways of doing this. One can try structured methods like Blue Ocean Engineering or classic unstructured methods like workshops.

Sketch
Take the idea and make a basic sketch.

Which ever way you chose to generate your idea, the important thing is to bring the idea from ideaspace down to reality. In this case reality is a visual representation in the form of symbols, pictures, drawings, film,  sound, smell, taste or text.

Design
Take the sketch and formalise it in a design language that can be communicated outside of the group.

Engineering
Use the design to break down the requirements needed to be made explicit so that a blueprint for the design can be generated.

Construction
Depending on the reality domain your idea is placed in you will select an appropriate construction method and start constructing your idea.

Use
In the most basic form of happiness the use of an idea cracked, worked and realised by your self is a wonderful experience.

If you’d like to experience this for your self or your team then send an email to me at jorgen.dahlberg@biner.se and I’ll bring my boxes of Lego to you.

Number five is about practicing EA and making it a part of your organizations operations as well as part of it’s strategic tool set. Here are the questions I sought to answer: how can we ensure EA’s success in the organization and how can we mine the knowledge and innovative force of the corporate body as well as the corporate tail.

EA as a massively collaborative effort

If we set up a view of EA as a massively collaborative effort, then we have at least three different approaches to choose from. They are the orbital, cantor set and project centric, all of these approaches can of course be combined and intertwined to create something more fitting for your organization. A variant on the above approaches would be to use a Wiki as the repository for knowledge, then anyone in the organization could work on the EA.

The Orbital approach

If we want teams that move in and work with a core cadre then we can choose the Orbital approach. In this approach we would launch a center of real excellence (CORE) to act as the engine of the effort. In this CORE we would bring diverse teams together to create new knowledge. The members of the CORE rotate out of their regular work and in to the CORE, where they remain for three days up to three weeks. During this period they work on learning about and improving the EA. They form cross organizational teams around topics of knowledge and interest, working on issues such as strategic alignment of IT and innovative use of our capabilities to create new offerings.

Through the steady influx of new participants, this will diffuse our approach to EA throughout the whole organization.

The Cantor Set

If we have the time and money to educate a large cadre of people then the cantor set is an approach to be used. The principle behind this approach is that we educate at least three people on EA and our strategy. Those three educate the next layer, and they in turn educate the next layer. The original three remain as support for all other in the organization. We can expect the amount of information processed and knowledge of the EA practice to diminish as the Cantor Set becomes more and more like a dust cloud. This is to be expected and it is an effect we want. There is absolutely no need for people at the extremes of the organization to know all about the way we do EA. There is however a need for people to know that we do do EA and what that EA means for them.

The project centric approach

If you don’t have a budget for EA or you have a small budget but you have the buy in from a senior sponsor. Then a project centric approach would be the way to go. In this you start by establishing a baseline architecture. One way of creating a baseline architecture is to take inventory of the running projects, the established policies and architectures. Using this baseline to communicate with and thus educating the projects on the EA, you will receive buy in from many parts of the organization. Continuing to refine the baseline EA through the mining of projects you’ll build up enough traction to show the true value of EA as an instrument for strategy and operations.

Did I get an answer to my questions? Well at least one can see that using any of the three methods suggested we establish a broad sense of EA in the organization and we mine the body as well as the tail. None of the methods are explained in any detail but hopefully it’s enough to get started.

There is obviously other ways of establishing EA within an organization that has not been covered by here. If you know of one I’d be happy to learn about it.