Visual Navigation

Yesterday I met an ex-colleague of mine at BullFeathers, which is in Capitol Hill. I didn't know BullFeathers is a burger joint where politicians met and discussed politics. My burger was good but the ambiance was mundane. However my conversation with Ren Pope, my ex-colleague, was very interesting. Whenever Ren Pope and I have casual discussions, the main focus of our conversation revolves around the data domain. I don't know alot of people like myself or Ren who really enjoy talking about data and its implications in IT. For example when we met yesterday, our discussion revolved around concepts like data density, data weights, "What is metadata?", misuse of data in the public sector and technologies which basically deal with data.

During our conversation, Ren stated that he built a website[http://rensdomain.net] using TheBrain. After visiting the website, I was initially disappointed since I didn't see any fancy graphics, embedded YouTube videos, or even much AJAX functionality. Isn't every website which has been developed in the last year or so, use or abuse AJAX? However after spending a few minutes on the website, I really enjoyed it. The beauty of the website is that it visually renders the information flow from one page to another. Like what Ren did, when you embed TheBrain technology into your website, you don't have to use the "BACK" button or the "FORWARD" button on your browser. Mr. Edward Tuft would be happy with the Brain since it does a good job of visualizing the information flow channels.

I have personally used TheBrain for a long time. It is a good tool for visually organizing information.

Can EA ever work?

A few months ago, I was sitting with my supervisor, who is an Enterprise Architect (eArchitect), and Gartner consultants discussing on how to sell the concept of Enterprise Architecture (EA) to our organization's senior management and how to create a successful EA in our enterprise.

Before we talk about whether EA can work, lets define the term Enterprise Architecture.

the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction

- Wikipedia

To capture the true essence of EA, Microsoft.com states the following about EA: "For the first time there is a methodology to encompass all of the various IT aspects and processes into a single practice.

Processes
As you can see, capturing every process and nuance in an enterprise is a daunting task. An enterprise can have mature documented processes which are known and recognized by the enterprise's resources. These processes are easy to document. There are other processes which are well known but no one has documented. There are also processes which exist but they are known by the select few. And lastly there are processes that no one is aware of but they do exist.

Resources
So who do you work for? What do you do? What projects are you working? What is your skillset? These are the typical questions an eArchitect has when he is tackling the resource view in the overall EA. The questions might be simple ones to answer however they are quite hard to ask. eArchitects don't want to invade in someone's space however they need to collect the information to complete their model and render different views of the EA to their management folks. It would be alot easier if the eArchitects went to the Enterprise's Human Resources (HR) Manager. The HR Manager might even be cooperative to share his or her information however their information might not tell the actual picture. For example, my official title in the enterprise I work for is "Computer Specialist" but my functional title is "SOA Technical Lead". Our Enterprise's HR Manager does not capture our functional titles. Therefore just going to the HR Manager and getting information from them does not give the real picture. There needs to be actual discussions between the EA team and low level managers.

Assets
What operating system is running on your operating system? Do we have licenses for this software? How come we have four versions of Microsoft Word? As you can see, assets are a big deal in an EA. Capturing assets in an EA is important since it shows an enterprise view on what, where and how did the enterprise obtain these assets. This information may be great for asset inventories however eArchitects need to make data calls with various groups to capture this information. Without understanding an enterprise's business processes, eArchitects will not be able to infer why certain assets are higher than others.

Application
eArchitects have to spend time with enterprise applications to determine if the applications are meeting some critical requirements in the enterprise. eArchitects have to work with application Subject Matter Experts (SME)s to obtain this information. (Once again eArchitects are doing a data call)

As you can see for a successful EA, eArchitects have to capture lots of information and then synthesize the information. This becomes extremely hard when other groups don't see immediate rewards in sharing their group's information. If there is no information, there is no EA and when there is no EA then the enterprise cannot be improved. For organizations to get a better view of their enterprise, they need to mandate their internal groups to share their information. If the internal groups don't share their information then the consequences are, frankly speaking, dire.

In summary, EA can work however EA will not work with extremely bright and talented eArchitects, buying the state of the art EA software nor simply creating numerous EA models. EA will work if the upper management take time and creates policy which will give power to the EA teams to capture their organizations critical information. The upper management should also investigate ways on how to automatically capture some of the EA information in their processes.

SOA from a human perspective

A few months ago I switched jobs. For my new job, I take the Washington Metropolitan Transit Authority Train (Metro) to go to my work location. Everyday it is a different experience. I get on a different train, a different car, sit on a different seat, sit next different people. Sometimes I get an announcement on the Metro that states the the train is delayed for some sort of reason. When my train is delayed then I usually send an email to my boss or call my wife that I will be late for dinner. I also see Metro law enforcement agents, who look for suspicious activities, people or items, get into the Metro and get off the Metro. Why are my observations about Metro interesting?

Well, let's say that I am a XML message and I am sent as a response message from the service providing application. All I, as the XML message, do is sit still in a ESB process (the train) and ride the ESB (Metro equivalent in a SOA environment). I might ride the ESB process with other XML entities who join me during the process. An system owner or an enterprise owner would be comfortable if some sort security mechanisms would be implemented in the ESB where my (as an XML message), fidelity is not altered and copies of myself are covertly created and sent to shady destinations. To address this issue, the system owners should enforce polices of having security agents who act as listeners in the ESB and then call other agents who take care of the corrupt XML individual. As an innocent XML message, I don't want to be tampered with and I would be happy if security controls like agents were implemented on the ESB. I would be upset if my train (the ESB process) is significantly delayed if every security agent is "frisking" every XML message. My owner, the system, would then have to send notices to his customers that I arrived late to the appropriate destination because i was frisked way too many times. Security in the ESB and in the enterprise have to appropriate implemented without significantly slowing down the system.

In airports, we are asked to take off our jackets, shoes, pocket change, cellphones, etc, and etc. This is very inconvenient however we do this because we want to be sure that there are no bad guys on the plane. Even if they are in the plane then they are stripped off of their potential weapons at the airport. This way we know we can reach our destination without much trouble. Using this example, I would like to argue how binary XML is a bad technologies for ESB centric solutions. Since SOA systems are based on distributed archtiectures where trust plays an important role between stakeholders and their systems. If binary XML or even compressed XML is sent across an ESB then rogue agents might sent encrypted viruses and other malicious malware through the ESB. If the ESB decides to decrypt the message then it could possibly infect the whole middleware infrastructure. If it doesn't then the service consumer may be "hosed". This model could bring an enterprise if the malware message sent to several destinations if the message is sent in publish/subscribe model.

Therefore binary XML is a dangerous technology and it should be used in a minimal basis. If you don't think so then please comment to my post.