#eavoices

EA Heuristic #4: Collect and analyze data with reusability in mind

by

Metal Bottle Cap Flowers (credit: urban woods walker)
(this article is part of the series “12 Heuristics for Enterprise Architecting“)
EA exercises involve collecting a lot of data and distilling insights from them.  It seems wasteful if the fruits of these efforts are used just once and then thrown away.  Instead, when collecting data and doing analysis on them, it is useful to think about how the data and analysis can be re-used.

Specifically, as discussed in Heuristics #2: Guess, Validate, Iterate: Time-bound architectural efforts, the insights are likely to contain some inaccuracies, so expect gradual refinement of the data and analysis.  To do that, how the analysis is derived from the data should be clear.  In addition, involve as much as possible the people who are going to update it in the future.  The more familiar they are with the collected data and analysis, the more likely they will reuse it in the future.

During our EA exercise, we created a chart showing the key products offered by the organization, along with each product’s importance and satisfaction level.  We created a first draft of the chart, then we explained to the organization how we did it, and then they refined it.  We hope that they will reuse this chart, and we are more confident of it since they have already updated it once.  In addition, when we created the summary of our key findings, we tried as much as we can to resist the temptation of listing down gut feels and focus on findings that are backed up by data.

A rant against 1:1

by

Everey now and again, I get really annoyed with sites that assume you have only one of something. “Please enter your email address” is a common request – except that I have several, and would like to have the opportunity to use any of them as my login …

EA Heuristic #3: Talk to more blind men to know the elephant

by

(this article is part of the series “12 Heuristics for Enterprise Architecting“)
Picture of an elephant in a gentleman outfit. Enterprises are like elephants, much bigger than this one, thus a lot harder for any person to get a correct whole picture of.
photo credit: Murilo Morais 
Enterprises are like often like elephants and the enterprises’ employees and stakeholders are like blind men in the classic story; they are each touching a different part of the enterprise and they will each describe the enterprise differently, sometimes in significantly different ways.  As such, though it might seem obvious, it is important to talk to multiple people, and if possible representatives of various stakeholder groups.  Moreover, what EA often reveals is the breakdown in information flow across the enterprise.

In our EA exercise, we got employees of the organization to suggest ideas.  In order to encourage more ideas to be contributed, we make it safe for idea contributors by not tagging names to ideas.  Later, when we evaluated the ideas, we observed that some ideas suggested by one employee was labeled as “we are already doing this” by another employee.  Clearly the initiative in question was seen as an area of improvement in the eyes of the first employee, but seen as completed in the eyes of the second.  This was a good example of different perspectives on the state of the enterprise.

Modernizing Enterprise Architecture: Address The Neurosis of IT

by

“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” – circa 1993 by nameless corporate Information Systems expert. I was shocked when I had heard this, and images of ostriches with their heads in the sand immediately came into mind. I was new…

EA Heuristic #2: Guess, Validate, Iterate: Time-bound architectural efforts

by

The spiral. Architectural efforts should use this shape as the guide, doing quick iterations that each bring the effort closer to the end goal, but never getting held back from progress by attempts for perfection.
photo credit: the pale side of insomnia

(this article is part of the series “12 Heuristics for Enterprise Architecting“)
It is very difficult to document various aspects of an organization to the lowest level of detail or even to document the high level views correctly. To begin with, people have different views of the organization so the one correct viewpoint might not exist. As such, it is important to recognize that EA artifacts are living documents and they will never be 100% accurate. 

Consequently, time-bound architectural efforts to ensure consistent progress. Guess and validate later when there is missing information. Allow for iterations to gradually refine EA artifacts.

In our EA exercise, we planned a survey early in the exercise to solicit information on stakeholder importance. The organization rejected the survey, so we created the stakeholder importance chart based on our assessment. During subsequent presentations, the organization’s executives provided inputs that helped us refine the chart. Reflecting on the incident, it would have caused us unnecessary time and grief if we did not move on but instead wait on getting that chart right first.

Event Distribution and Event Processing

by

I have recently been involved in several discussions (sales opportunities perhaps), where the answer seems to be, “We need a CEP engine”. Of course if one chooses solutions based on products there’s something wrong. And then working with the sales forc…

Event Distribution and Event Processing

by

I have recently been involved in several discussions (sales opportunities perhaps), where the answer seems to be, “We need a CEP engine”. Of course if one chooses solutions based on products there’s something wrong. And then working with the sales forc…

EA Heuristics #1: Looking for gaps? Push from top, guide from bottom.

by
A police helicopter. Police helicopter helps police gets a big picture of the city, so that the police knows what to focus on. The police still need to rely on people on the ground for details. A situation similar to the heuristic described in this article.
photo credit: metropolitan police
(this article is part of the series “12 Heuristics for Enterprise Architecting“)

When looking for gaps in the current stage architecture, a useful approach is start by “pushing from the top”—start with the enterprise’s strategic objectives, then use the objectives’ linkages with other views to assess if there are any gaps, and then gradually move down through views level by level.

It is important to start the search for gaps from the top, as gaps more closely related to enterprises’ strategic objectives would be uncovered first. This approach decreases the likelihood of missing important gaps or being distracted by less important ones.

While pushing from the top, it is useful to “guide from bottom”—use anecdotal evidence to focus the search for gaps. During our EA exercise, we gathered a number of pain points through conversations with the organization’s employees and reviewing customer satisfaction survey results. However, when we did the analysis by “pushing from the top”, we were puzzled as we could not find those pain points. We analyzed the issue further, focusing on areas where the anecdotal pain points should have shown up, and finally realized that it was because there were missing metrics, and this discovery helped us uncover a second issue—the metrics were not granular enough.  If not for the knowledge of the pain points from “the bottom”, our “push from the top” analysis would have yielded nothing.

12 Heuristics for Enterprise Architecting

by
Photo of a compass. The heuristics that I present in this articles will be like a compass for my future enterprise architecture exercises, guiding me in what to focus on.
photo credits: i k o

Lessons learnt as I reflect on a recent four-month Enterprise Architecting (EA) exercise.   In the exercise, a 4-person team helped an organization map out where the organization was at, where it wanted to be and how it could get there.

Each lesson is captured as a heuristic, a rule of thumb that I want to remember so that I can use it to guide me for future projects.  They are not truths, and will get refined with more experience and insight.  I definitely hope to hear your experiences that relate to these heuristics, regardless of whether they support or invalidate a heuristic.

What made this EA exercise interesting is that, though it is not my first EA exercise, it is the first one I took a lead role in.  Also, this exercise made use of a methodology new to me, from MIT course “Enterprise Architecting” taught by Professor Deborah Nightingale and Dr. Donna Rhodes. In addition, ideas from the book “Enterprise Architecture as Strategy” also crept into the EA exercise, as I was concurrently attending a class by the book’s co-author Dr. Jeanne Ross.