Red Flag - The Architect and Agile Methodology

Today, I want to focus on technical architects and how they document and present their vision to 'C-Level' executives and business experts and some warning signs that should cause you great alarm.

Let me paint the setting before we launch into the 'Red Flag'. You have a technical architect on staff working on a complex major project for you. You are using Agile project management methodology. That means different things to different people, but you are at least doing daily scrums, have someone that sort of resembles a scrummaster, have your staff in a common work area where 'high-bandwidth' communication is the order of the day, are focused on sprints and doing and not on reams and reams of documentation, etc. If you have done Agile before this is familiar.

Red Flag - An architect who uses Agile methodology's focus on less documentation as an excuse not to do their professional due diligence. This particular architect feels that since Agile methodology means very simple and light documentation he does not need to document his vision and explain it to people, or for that matter, think through the issues. When pressed, the excuse is always "we are using Agile methodology. We don't need to do that." After all, the focus is on doing the core 80% and then refactoring to fill out the gaps in the final 20%. Sounds good.

• Except when your architect has not thought through all the parts and pieces and is doing UML diagrams and flow charts of key pieces after the fact.
• Except when he is cursing the developers for being slow and dense because they are not doing what he wants -- because no one knows what he wants.
• Except when he asks a developer to make multiple major course changes in architecture – within the timespan of an hour.
• Except when the technical writers, QA team and user training team need an overview so they can do their jobs -- but nothing exists.
• Except when key components like security are ignored -- then hastily plugged with hacks at the end.

Any of this sound familiar? When you sit down with your business experts, technical staff and decision makers, the architect should be able to articulate the system and how it will work. This does not mean that he needs UML class diagrams of every single part of the system. In fact, when using Agile that is something I always leave at the discretion of the developers. However, the architect should articulate what technologies he is using and what is going to be used to do what.

Your architect should show that he has done the level of due diligence that is appropriate for your business and the legal and regulatory requirements it faces. He needs to demonstrate that he has thought through the issues you face and has a realistic strategy of how to solve them – especially technically. This does not mean a chart with a couple of boxes on it where he explains 'magic happens here'. Use common sense.

If you are the main stakeholder and your architect cannot do this, be worried. How are you going to plan this thing out? How are the developers going to know what to do? Are they going to meet the use cases? How are you going to budget? Don’t wait until the financial department raises the hue and cry when they realize that the project is hemorrhaging money. Agile methodology is not an excuse for technical incompetence, laziness, or arrogance.

I usually play the role of data architect or technical architect in most of my projects, sometimes both. The purpose of a technical architect is to put together a data or technical vision for the system being created. But a good architect is an evangelist; he must see the vision AND be able to articulate it. One of the first things I do after having gone through the requirements phase, gotten my use cases, activity diagrams, etc. is to draw out a basic diagram with all the moving parts of the system: what they are, where they live, who owns what, what they do and how it all fits together. For the last of these I use a Zachman-like approach where I have different layers representing everything from hardware, to ETL packages, to web front ends and reports. I have seen something similar done in David Hays work, Data Model Patterns A Metadata Map.

This diagram is an excellent tool for communicating with executive and business experts. I usually print it out on a plotter and make a wall chart then go through it with all my stakeholders. No matter what level the stakeholder is at, i.e. a subject matter expert, system administrator, etc. they can focus on their view of the world and see how it fits into the bigger picture of where we are going.

Agile - High Bandwidth Communication

As you can tell, I have focused lately on Agile project methodology. It is one of those things that is currently in vogue. Will it last? Will it be the panacea? In some enterprises it has been successful and will remain so. Others have had mixed results. It will persist in some form for some time.

One of the big promises that Agile advocates is the premise of 'high bandwidth' communication. Adherents push for in-person, face-to-face communication amongst team members and stakeholders. This is often done by putting everyone into a room and turning the team loose. They are supposed to self-organize with a scrummaster guiding the way. Under some circumstances this is a very powerful and productive way to build systems. In others, the jury is still out. An interesting thing to watch will be how SOA and Agile work together in the future.

From a management perspective, putting everyone into a room to foster team spirit, communication, etc. may be a panacea or a minefield. Two issues arise that I have seen in such situations. One, rarely do the stakeholders have time to devote 100% of their effort to a project. Often you are fortunate to get 5 or 10% of their time. The reality is that they have a job to do in addition to helping out with the new project. Their business lives do not stop for IT. Putting them into a room with the developers and everyone else, whilst potentially beneficial, is not realistic. In fact, it may seriously hinder their ability to keep the business going. These rooms where the magic happens are often noisy, disruptive environments. There is a lot of talking, lots of side conversation, sometimes horseplay (you do not see what happens behind closed doors). Stakeholders may need to meet with clients or chat with them over the phone. Having a constant commotion in the background whilst you chat with a client does not sound professional.

Second, for the non-stakeholders, adapting to the noise and commotion may significantly impact their productivity. If you are in the middle of some intense task and get distracted, for one reason or another, it may take 10-15 minutes to regain your train of thought. If that happens 3 or 4 times a day you’ve lost a lot of time.

These two points bring up a lot of issues - some of which I will deal with today. First, team composition is very important. Some personalities mix like water and oil. Some are loud and gregarious and want to be the centre of attention - always. Some are pranksters and jokers. Others are focused or introspective. There are all types. If you build a team that looks, works and operates like a fraternity house, and not everyone subscribes to that philosophy, you will have issues. They may be serious enough to jeopardize your project. Agile teams will self-organize and they will develop a personality. As a manager, you will not be able to control that, nor should you. However, you can control who goes on the team and the general tone and demeanor. As a manager you should set the tone and demeanor of your organization.

Second, having business stakeholders in with everyone may not be feasible. It may not even be desirable because the free flow of ideas may be constrained. Maybe they can be in part of the time, part of the week. Yes, they can run off to meeting rooms to meet with clients or chat over the phone with them. Ideal? No. Functional, maybe? Or perhaps there is another way to slightly bend Agile methodology and make this work. Purists will likely disagree with this as it breaks the tenant of face-to-face communication. However, as a pragmatist I opt for some communication over no communication .

One tool I have recently used with excellent success is Groove. I gave it a full run-through on a recent project with a client in Vancouver who had a team member on-site in China. If you do not know Groove, it is a peer-to-peer communication and collaboration software that allows team members to form workspaces and share documents, messages, etc. It was developed by Lotus Notes creator Ray Ozzie, who is now with Microsoft. We used it for threaded discussions, calendaring and document sharing. Each time we logged on it synced up all the versions of the documents we were working on and alerted us to new messages in the various discussion threads. And it kept this up as long as you were logged on - in real-time.

While we did not use SharePoint, you could use it to archive and make searchable what was accomplished on a project in Groove. The potential for synergy is great. Using it, and thinking of the above issues, made me think that it would be a great way to keep a stakeholder, or other team members, connected and informed while not being disrupted to the point of being unable to do their jobs. The realist in me tells me that I still get the benefit of high-bandwidth, multi-mode communication, just not face-to-face. I still get instant answers and less miscommunication, which is what Agile is supposed to do. It would work for stakeholders. It would also work in those situations where you had personality issues that could potentially tank a project but you have no option but to have team members work together.

Tuning Your WLAN - What to Look For!

Overview

There are a lot of reasons a wireless network does not perform well. Some of
them are obvious. Other are complex. I want to take you through some of the most common scenarios that result in poor performance in this article. Some you can fix yourself. Others,
you may have to call in some help. Wireless networks depend on radio frequency (RF) transmission - which is a science and can be monitored, modelled, etc. RF propagation also interacts with humans and their environment - an ever-changing scenario. So if there is a "black art" to tuning a wireless network, this is where it would be - dealing with the unpredictable and
ever-changing.

When Too Much is Bad For You

You can never have enough of a good thing - can you? You most certainly can with multiple access points for a wireless network. Unless you are laying out your home network with 1 access point, you will likely need to have multiple access points to guarantee coverage for your users. What is your first instinct - let's add a few more access points. Should work! Reality is that it's likely to cause you more headaches than you think. If you get too much overlap between cells, you get channel flapping. Clients will bounce back and forth between access points and you will have some unhappy users on your hands.

Unfortunately, just dropping out some access points is not always the solution. Then you get large coverage gaps where nobody can get a signal. So how do you deal with this. The key to a good network mesh is careful placement of your access points. Anytime you have more than 2 access points, especially if you are using VOIP over wireless, you should do a site survey. Examine where you are going to place the access points, look at their range and signal strength
and identify the overlaps. There are a lot of guidelines out there for how much overlap is best practice. If you listen to the folks at AirMagnet, who sell monitoring tools, 15-20% is best practice. If you read Cisco's 802.11 Wireless Network Site Survey and Installation, they recommend a typical overlap of 10-15%. Your mileage may vary depending on your local conditions.

Site surveys are a complex thing to do properly, but there are some tools to help out. Cisco has the Aironet Desktop Utility. A subset of features of the ADU come with the monitoring tools with most Cisco wireless cards. If you have an Intel Centrino system, it likely includes the Intel ProSet utility. It offers signal strength, noise-floor readings, transmitter retries, beacons missed and throughput. Orinoco and Netgear products also come with some basic tools. At the enterprise level AirMagnet offers both a sniffer tool (AirManget Laptop Analyzer) and a survey tool (AirManget Planner and Survey). In the open-source world you can give
NetStumbler a try.

What Happened Now?

Well, it worked before. Or it works only after 3PM. You had it all planned and tuned perfectly. Unfortunately, wireless networks rely on RF propagation. RF propagation is subject to both losses and gains as it leaves the transmitter and eventually finds it way to the client. Interference comes in many types from many sources. Did the environment change? Do you have some new walls or cubicles that are causing multipath or changing the propagation? Did someone stick up their own rogue access point? Did someone stack something on top of your access point? What about the antennas you are using? Did the people on the floor above you go wireless? Did the network security policy change - is there something in there that is WLAN specific?

If the environment changed there is no substitute for doing a walkabout. Even if everything is working normally and users are not complaining, you should periodically check on infrastructure. A lot of offices use cubicles, personnel change, things get moved around. Be proactive.

Friend or Foe?

Putting up an access point is almost a no brainer today. Pop on over to your favourite store and pick up a D-Link or Linksys, follow the instructions and you will be in business in 10 minutes. Unfortunately, sometimes access points pop up like mushrooms. That has an impact on your environment and performance. Did someone stick up their own rogue access point? Did
the neighbouring business suddenly go wireless. Do they know what they are doing or have they been listening to the local family geek (which sometimes is a good thing)?

Using the scanning tools mentioned above, take another walkabout and look for rouge access points. Look at the SSID's. Are they yours? Do they have security enabled? A lot of times they don't! I like to classify my SSID's' as either mine, neighbours, friends or rogues. The SSID's can often give you some excellent clues. Yours you should recognize. Seeing multiple access points with the same name, or systematically named, with security enabled may indicate a business. One that has the default name enabled, e.g. Linksys-A, has no security enabled, has a signal strength that varies, keeps coming and going, etc. is one that needs further investigation. Access points that exhibit a steady signal level but with which you cannot associate may be a neighbour. Check it out to make sure after you get done tracking down the rogues.

You Realize That You Are Not Alone

I hate to tell you this but you are not alone. If you take a gander over at Wikipedia, you can see what frequencies work at the 802.11 specifications. In summary the different standards and operating frequencies are:

• 802.11a - 5 GHZ


• 802.11b - 2.4 GHZ


• 802.11g - 2.4 GHZ


• 802.11n - 2.4 and/or 5 GHZ

What else operates in these frequency bands? For starters we have Bluetooth. You can read a
short paper from the NIST about it. Microwave ovens also operate in the 2.4 GHz unlicensed band (2400 - 2483.5 MHz) for ISM (industrial, scientific, medical applications). Home ovens are less of a problem than commercial ones because they are operated infrequently and usually for very short bursts. However, in an office environment with a lot of employees using it, especially around lunch times, this can become a factor. An interesting paper on the subject was written by Kamerman and Erkoçevic of Lucent in the Nederlands. Another factor that you may not think about is 2.4GHZ cordless phones - although cordless phones do operate on other frequencies as well. To make things even more interesting, we now have things like wireless cameras. Oh joy!

Unfortunately there is no panacea to cure this issue other than constant vigilance. Th environment around you constantly changes. Once again, perform a site survey. Don't just do it once when you set things up. Make it an annual if not semi-annual event. In particularly problematic instances you may have to call in a professional with a spectrum analyzer to untangle the mess.

Did You Bother to Configure your AP?

You would be surprised how many people accept the common default values on most instruments. It works doesn't it? One of the great features of 802.11 technology has been backward compatibility. You can setup an 802.11g access point and still use your 802.11b card. However, you pay a price for this convenience. The key to tracking this down is to realize that the different standards work at different data rates:

Standard	Operating Frequency (GHZ)	Typical Data Rate (Mbits/s)	Maximum Data Rate (Mbits/s)
802.11a	5	23	54
802.11b	2.4	4.3	11
802.11g	2.4	19	54
802.11n	2.4 and/or 5	74	248

If you take your wireless scanner and look at the distribution of frames at each data rate, you may see that the 802.11g access point that you thought was operating at a maximum data rate of 54 Mbits/s is actually transmitting only 40% of the frames at the advertised rate. Why? Many access points, especially Cisco, accept all data rates in their default configuration. So now, instead of operating at one data rate, you are in mixed mode. Cisco has a slightly more technical treatise on what has to be added to an 802.11n transmission in order to maintain legacy compatibility. What is clear is that there is an impact while operating in a mixed mode but no easy answer on the amount of impact. In a 802.11n design guide from Cisco, they state:

"There's no clear answer to the question of how legacy device coexistence will affect overall 11n throughput, other than to say that performance will vary. If nothing else, we can be sure of a few things:

• You will always realize some performance gain with 11n APs because all 11n devices will be able to transmit at 11n rates, even if legacy devices slow down aggregate performance when they operate in their legacy rates. Also, even if you have no 11n devices at all associated to your 1250 Series AP, the MIMO portion of 11n will still help the cell realize some gain.


• The higher your percentage of 5-GHz devices (even if they're legacy 802.11a
  clients) compared to 2.4-GHz devices, the better your overall performance will
  be.


• As time goes by, we'll see more 11n devices out there. As this occurs, your
  aggregate throughputs will rise accordingly. This is how the transition to 11g
  happened, and all signs point to the client transition toward 11n happening a
  whole lot faster. Just look at the number of laptops shipping today with
  built-in 11n support; we're far past where we were at a comparable point with
  11g adoption.

The same backward compatibility that makes 11n so palatable may make some folks declare that 11n throughput is not what they hoped it would be. Understand that your installation will be only as fast as your clients are capable of moving. If throughput is of utmost importance, look to move your legacy users over to the faster 11n spec and begin to proactively execute on your 5-GHz strategy."

The solution to dealing with this issue sounds simple but may not be depending on whether or not you need to be backward compatible and what type of infrastructure you can deploy or must support.

I Can Save a Few $ - What's The Difference?

We have all heard the phrase "all men are created equal". Well, it does not apply to radios.
A client, i.e. user, with a good radio in their system can hookup with an access point much easier than one whose power level is lower. Depends on the manufacturer. Worse, there is no standard for radio power levels. While you may have your access points properly deployed, the overlap perfectly accounted for, no interference from "wireless cowboys", etc., you may still get coverage gaps because of client radios .

About the only way to deal with this is to try and keep your clients homogenous. Set some corporate governance standards and stick to them. It also goes without saying that this is another thing that needs to be continually monitored and analyzed.

Security

Everyone's favourite topic raises it ugly head again. Yes you need it. You should never be without it. And yes, sometimes having layers of security makes logging on and accessing corporate resources more challenging. And yes, there may be some security overhead if the access point has to go out to a Certificate Authority server or a RADIUS server. The best you can do is to make sure the rest of your network is optimized and functioning properly. I have seen networks where, due to misconfiguration, it took a packet 6 hops to get to a server when it should have been 3. In other words, do not more do than you have to.