In an article in Computer Sweden today, Ivar Jacobson the father of use-case wrote about being smart. In conclusion he wrote that “you don’t have to repeat the mistakes of others”.
I gave it some thought and of course you should try not to repeat the mistakes of others, but inevitably you’ll make some mistakes that others has made before you. The biggest problem in todays IT-driven business isn’t that we occasionally repeat others mistakes, it’s that we continue to upgrade the mistakes we are faced with. Thus creating one of two problems, either a highly complex environment or a monolithic inflexible structure. Worse we could create a highly complex monolithic structure. Remember that the mistakes we are faced with, might be the success of yesterdays heroes (the boss of today). So tread carefully on the marshland of change, but be swift when the sponsor is in and make the move without remorse.
Do you have samples of where the pattern of continuously upgrading mistakes has been at play, then comment this so we can learn.
Myself I’ve seen several such mistakes. One that comes to mind is an organization that installed a portal software as an organizational wide intranet. They where never able to capitalize on the capabilities of the software, mainly because lack of interest from division managers. They have decided to upgrade the software to the next generation, an even more complex product. Of course they will fail once again, since it is the same staff and the same managers, thinking the same thoughts. This is a perfect example of “continuously upgrading mistakes”.
Thank you Ivar for the spark of thought gave me on this Friday morning, now I’ll go and tear down the ceiling in my living room.
This is just to announce the first in a collection of snippets that I’ll post. All of the snippets will be posted under the same title “The art of architecture #”, they will all be used in a book project about the art of architecture in the enterprise arena.
If you feel like contributing to this project please feel free to comment and or mail me directly with ideas, snippets, thoughts. If you have a company or organization that wish to participate in this I’ll be happy to discuss most matters in person or via any media channel.
I’ve been actively pursuing what I’d like to see in an offering related to the practice of enterprise architecture. Below is a fictive offering made to the community and all other stakeholders in EA, about a great service that would cater to most of the common needs.
What if I exposed a service to you that gave you the ability to maintain all of your EA artifacts on any meta model you like
What if the service could visualize all the relations and even some things you haven’t thought of yet
What if this service came with ready made samples and explanations for most concepts in EA space
What if the service I exposed was a true in the cloud application
What if this service was localized for your usage
What if this service could build upon your present material by importing, converting and exporting
What if the service I exposed was more secure to use than your present service
What if you and your users could have a say in how the user experience of this service would feel like
What if this service had all the features of social computing and they where built in from start
What if this service had awesome search built in to it
What if this service had an open API attached to it
What if the service I exposed guaranteed a drop in EA tools licensing cost with more than 90%
What if this service was globally available
What if the support for this service was better than what you get at your mommas house
What if I could guarantee delivery of all this by 2009-12-31
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.
I’ve updated this to version 2 (2007-11-21) with additional material in the slides.
I’ve prepared a presentation on the possibilities of organizing work against a time factor in the areas of Enterprise architecture, solutions development and IT-production. The focus of the presentation is on the rate of change within three layers (see slide below).
A while back I came across a post on nform.ca, where information architect Gene Smith of the Atomiq.org blog outlined the 7 building blocks of social software.
I recently used the model to explain the key capabilities of social software when brainstorming ideas with some friends. The model worked really well, everybody felt that they understood what the foundation consisted of and we could focus on other issues.
Explaining SOA to some really smart bussines people
Sure they understood the basic concepts but when we came to more and more details such as defining a service as stateless, discoverable, autonomous, loosely coupled, composable, abstract, reusable. Then adding the concepts surrounding governance and SDLC.
Thats when I had an epifany, why not explain SOA in the frame of social software. I used Gene Smiths original model and rewrote it to be about services instead of people.
7 building blocks of SOA
Identity
A way of uniquely identifying services in the system
Presence
A way of knowing which service is online, available or otherwise reachable
Relationships
A way of describing how services are related
Conversations
A way of communicating with other services
Groups
A way of forming mashups of services
Reputation
A way of knowing the status of other services
Sharing
A way of sharing things that are meaningful to services, such as other services
