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.

In an article today at AdaptivePath Kate Discusses the Role of Design in Business with Nathan Shedroff. Specifically they address the topic of design-led innovation process. There is a trend today towards design-led innovation. I foresee a twitch in the architecture field when the emphasis on EA moves from documentation to strategy, then perhaps we will pick up the best pieces from the field of design.

http://www.adaptivepath.com/ideas/essays/archives/000920.php

That’s why I named my company “desiarch” short for design and architecture.

When you work as an architect you will need to get an overview of the key metrics and events concerning your part of the EA domain. I’ve been looking into the needs I have had on this and put together a presentation on what an EA dashboard could look like and what it could contain.

You can view the slides showing the design or the cut out images showing each part and comments.

Content of each part

Activity on the EA Wiki

Here we are tracking tagged events on the EA wiki. We can see in the upper left corner which tags we are tracking. If we want to change these, then clicking on the tags would open an interface (could be a tag cloud, a list of tags or selected tags) for selection. We track what has happened, who did it and when they did do it.

We would track these tags on the wiki because the represent some of the most important tags in our change process. We would use a wiki to enable the whole network of interested parties to collaborate on most artifacts concerning our EA.

As a side note I must say that I’d like to see a so called EA tool set that uses wikis and the ideas of crowdsourcing to create EA artifacts.

Major Events

Tracking major events in the calendars of those directly involved in the practice of EA gives us the ability to quickly respond to requests for work or other tasks that need special planing. It would be a good idea to track outside events, but I’d place it on a separate part. The reason for this is that I’d like to keep the parts atomic, so there will be no doubt about their contents and functionality.

Top projects in EA work queue

By tracking the top projects in the EA work queue we are able to pick work that needs attention. Re-prioritizing our personal schedules or the team schedule becomes so much easier when you actually get to see the projects and the work that await. It simply keeps all alert to whats most needed.

Project Metrics and/or EA metrics

The project metrics as expressed here are related to how well EA is doing in the organization. By tracking these specific KPI’s we can quickly assess the status of our work. Compliant projects, measures how many projects actually comply with the work put forward by the EA. Start architecture, measures how many projects have received a package put together for them containing all important artifacts from the EA related to their project. Total work delivered, counts the actual hours delivered by the EA team to projects. Feedback delivered, measures the amount of feedback received from projects. Trained in architecture, measures the number of people who have received training in the craft of architecture such as it relates to our use of EA.

Business Capabilities

In any endeavor to create and evolve an agile architecture for business it is important to track the major parts. These parts are often referred to as business capabilities. In a SOA effort we would like to realization these or characteristics of these as services. This type of realization gives us a flexible approach to designing business processes that follow customer demands. By tracking them like this we can easily see if we are successful or not by looking at the graph at the bottom of the part. We get an instant birds-eye view of capabilities that have been brought forward by projects.

Business News

With this part the goal is to track the major influences from the outside on the organization and the domain of EA. The part is of course of lesser importance and as such we place it at the bottom right corner.

EA Review Metrics

This particular version of EA review metrics tracks the adaptation of EA in the organization. It shows the planned route from not being recognized as an issue, until it becomes a part of the strategic initiative.

The design as a slideshow