EA Voices

What rules of thumb guide your EA efforts? (photo credit: Sanna R)

This is the second half of my 12 heuristics for Enterprise Architecting.  I have already started using some of them to guide me in EA exercises, for example heuristic #7.  And there are those like #11 that I need to constantly remind myself of.  Hope you will find the following six heuristics useful for guiding your work.

Heuristic #7: Eat your own dog food

When proposing a tool for use in an enterprise architecting project, one should ask oneself “Will I use this tool for analyzing my own business?”. If not, why is it being used in that project? When I was working at Oracle, the company “forced” employees to use software tools made by the company, ranging from employee directories to collaboration tools to software development environments. This “eat your own dog food” culture helped Oracle employees understand the strengths and weaknesses of the company’s offerings, and thus be better positioned to improve those tools. In the same way, enterprise architects should eat their own dog food, applying tools they advocate to their own enterprises, which can range from their family businesses, their social clubs, their churches and even their personal lives (think “Me Inc.”).

During the exercise, I wanted to show the organization how an enterprise architecting tool can bring value to what they do. I decided to try the tool on my own life first: I used it to map out my strategic objectives, and then linked it down to processes in my life (i.e. habits), and eventually connected processes with their supporting technologies (see post on “Architecture of my life“). The exercise helped me see that doing the exercise with the tool created more meaningful artifacts comparing to doing the same in Microsoft Word or PowerPoint. Subsequently, I was able to transfer that insight in my recommendations to the organization.

Heuristic #8: Don’t overlook the tools and the venue!

Enterprise architecting involves many meetings: interviews with stakeholders, internal information sharing, brainstorming, constructing future architectures, etc. Good tools and venue play an important part to the successes of these meetings. As such, it is crucial that considerable thought be given to these two items.

In our exercise, two tools that proved extremely valuable were Google Docs and post-it notes. Google Docs allow all meeting participants to look at the same document at the same time, and also to edit it simultaneously. It helped all the participants to stay engaged, as they are empowered to make changes. We often voiced our opinions by making changes to the document and then asking, “how does this look?” which sped things up as we were discussing and creating the deliverable at the same time. We collaborated in this way even when we were physically in the same room!

The other valuable tool is post-it notes, which is a must have for brainstorming sessions. The key strength of post-it notes is it enables a group to capture individual ideas first, and then later categorize and sequence the ideas, which is hard to do on a single piece of paper or electronic document. We also created an electronic version of post-it notes by using PowerPoint in Google Docs. We created small, yellow text boxes and used them as post-it notes. Google Docs’ functionalities allowed all participants to simultaneously create and edit the “post-it notes”.

As for venue, we had a brainstorming session at a pub and that made the exercise more fun and relaxing. Having a venue with a big screen is also helpful in making sure that everybody is on the same page. In addition, we experienced difficulty in collaborating with our clients who were stationed in a different location. We could not involve them to brainstorm the way we did among ourselves. This challenge was made harder as our clients could not use Google Docs or collaborate with us using physical post-it notes.

Heuristic #9: A season for good ideas; a season for bad ideas

In creating the to-be architecture, set aside a time to generate ideas, when none of the suggestions are discarded or criticized; and a time to kill ideas, when all ideas except one are bad. This heuristic helps the team in two ways: in the first phase, the team is able to cover as many possibilities as possible, since all suggestions are captured and considered. Next, in the second phase, the team is able to converge on a single idea, as they systematically shoot down options. A common trap is to bypass or speed through the first phase and jump to the second phase.

I learnt from this exercise a useful approach to separate these two phases: first brainstorm for ideas, group them into concepts, and then slowly converge those concepts by creating candidate architectures before finally selecting a single to-be architecture. I had earlier made the error of bypassing the first phase by jumping straight to creating candidate architectures. I saw the value of the idea generation phase since it allows small ideas (e.g. have a beer drinking session every week) to be captured, even though they do not have enough scope to qualify as a candidate architecture.

Having a systematic approach to converging is also very useful. I saw a useful approach from another team, where they did scoring on their concepts and then select the highest scoring ones to create candidate architectures.

Heuristic #10: Draw the house, then the beams, then the house

It is really difficult to create the to-be architecture without knowing the next level details. Often, there are constraints on the ground that make the architecture unrealistic. For example, in our exercise, we wanted to recommend a re-organization but later we realized that a re-organization happened recently and thus another one would face more resistance. Another example is when we made recommendations on knowledge management. After we found out about the organization’s existing knowledge management efforts, we realized that one of the difficulties the organization faced was the existence of multiple knowledge repositories. We subsequently amended our to-be architecture to stress the importance of a single knowledge repository. As such, it is important to chart out the next level details when creating the to-be architecture.

How deep into the details does one have to go? I rely on the analogy of building a house: as long as there are sufficient beams to support the house, the house should be okay. So go down to the level of “beams”, which are key elements in the organization that will make the architecture work, and I suspect that differ from organization to organization.

Heuristic #11: We are blind men too!

While creating the candidate architectures, my teammates proposed ideas that at that time I felt were infeasible, for I thought they were either too theoretical or things that the organization was already doing. What surprised me was our sponsors liked those ideas, and slowly I too grew to appreciate their values. Eventually those ideas were incorporated into our recommended to-be architecture.

My lesson learnt is that I am a blind man too, as my understanding of our target organization is similar to the blind men’s understanding of the elephant—incomplete and flawed in many ways. I needed to rely on other blind men to tell me that the elephant has a tail, a big ear, and legs as thick as tree trunks. As such, do not shoot down ideas too early, hear what others think of them, and remind yourself that you are a blind man too.

Heuristic #12: Make your ideas theirs

When creating the to-be architecture, it is very important to get buy-in of the architecture, as some of them will be implementing it, and some of them will have power to kill it. The ideal case is really when key stakeholders feel that the to-be architecture was their idea. The approach we took to achieve buy-in was to firstly involve the stakeholders as much as possible in the to-be architecture creation process—from evaluation criteria creation, to idea generation, to the eventual selection of the to-be architecture—so that the organization will not see the recommendations as coming from the outside but rather proposed from within. In addition, we got everybody—both the MIT team as well as people from the organization—to propose ideas and put all the ideas in a common pool, consciously not tagging any names to those ideas. The intent was so that people lose track of who came up with what idea, and hopefully find it easier to identify with selected ideas, and in some cases even think that it was their idea.