Global? Schmobal!

I was working in Buffalo New York in a company back when IT teams were more or less silo'd and custom development was king.  Now we are in a world were those decentralized teams have become historic artifacts of a once fun and exciting part of our job.

When the realization hit that IT was no longer going to be the business trusting IT to build things on their own in a time capsule I started to adopt the notion that we would become centralized,  On the bright side, I thought, we would be able to work more closely with our colleagues in other countries which is something that always interested me.

Along came the ground breaking book The World Is Flat [Updated and Expanded]: A Brief History of the Twenty-first Century which made it seem that we were well on our way to being able to work from anywhere, at any time, with any one.  His revelations of reporters being alone without a cameraman and only a mobile device doing video interviews.  He talks about the advanced fiber optics that have effectively bridged any and all communication gaps between countries and cultures.  It was really shocking to leaders in Western companies who wondered why they were no longer able to compete with the same advantages that they once had.

That book was written in 2005 so with the speed in which technology advances one would thing that on the brink of 2012 we would certainly be well on our way to a true flattening of the earth.  Seemingly we are stuck in a black hole in the area of true globalization.  While the technology is in place, the business and social communication framework is still sucking at the knee-caps of Bill Gates and Steve Jobs.
My current role requires frequent travel within Europe, US and Asia.  Here are some personal real life examples of how far we have to go until we are truly a global world.

My phone bills over the first two months averaged in the area of €1.500 per month.  Oh, I need to mention that the thousand separator is different depending on where you are. If the decimal mark is a point, the digit group separator is often a comma or a space. If the decimal mark is a comma, the digit group separator is often a point or a space. The problem with the point and the comma as either decimal mark or digit group separator is that, internationally, they have both often been used for both meanings, and their meaning is context-dependent (one must know which notational system is being used in order to interpret them)  I digress.  My phone bill is one and one half thousand dollars per month.

Global Schmobal Issue #1 - Shelling out the dough for mobility:
I use my mobile phone as my communication device when I am in airports, in hotels, in restaurants, or anywhere away from home.  I also use it to check for email and to hook into our IM system within our company.  I also use it as a tethering device to my laptop if I am at a location that does not have free wireless.  Everything works wonderfully.  Performance is good, minimal latency, and very few drop-outs.  Tell me though how many sales managers will be willing to shell out €1.500 euro (around $2,000 dollars, or around £1300 British Pounds) per month for their global sales teams.  I would say that number is around zero.  So now I am left with only a few options.  Scale back travel, be disconnected for the most part while I am travelling, or try to persuade networking companies to start to think globally when it comes to constructing their billing models.

Global Schmobal Issue #2 - Payment Option Madness:
Whenever you travel I'm sure that you use credit cards for most of your purchases.  Some who are still old-fashioned carry cash.  If your really old-fashioned you use traveler checks.  If your more hip you may be using your ATM card for most purchases.  (I am tempted to escalate this to using personal checks but I don't want the 60 somethings yelling at me when I go to the bingo parlor next week in Amsterdam).

So you think you can just waltz into any diner in Berlin and show your shiny new Master Card after having a delicious schnitzel with your family.  Think again.  You probably will need a new card that has a chip in it that guarantees that the card is yours and has not been stolen.  Heck, with that they wouldn't even ask you to sign it.  Don't bother taking out your ATM card as that wouldn't help you much unless it was from a European Union bank.

If you go to a cash machine you will be lucky to find one that give you the option of presenting the options in English.  I would say you have a 30% chance of English being an option.  (I have still yet to be able to change the password on my dutch credit card because I can't figure out how to do it.

On a side note, try waiting for the waiter to give you the check.  It won't happen.  In the US you get a check as soon as you say no to dessert.  In Europe and Asia they will not give you the check until you ask for it or at least an hour has passed.

Global Schmobal Issue #3 - Driving:
Obviously everyone is familiar with the differences between countries in regard to which side you drive on when you are in different countries.  The greater UK community drives on the left with the steering wheel being on the right.  India also drives on the left.  Most other countries drive on the right.

The difficulties here go deep.

Research in 1969 by J. J. Leeming showed countries driving on the left have a lower collision rate than countries driving on the right, although he acknowledged that the sample of left-hand rule countries he had to work with was small, and he was very careful not to claim that his results proved that the differences were due to the rule of the road. It has been suggested this is partly because humans are more commonly right-eye dominant than left-eye dominant.

In left-hand traffic, the predominantly better-performing right eye is used to monitor oncoming traffic and the driver's wing mirror. In right-hand traffic, oncoming traffic and the driver's wing mirror are handled by the predominantly weaker left eye. In addition, it has been argued that left sided driving is safer for elderly people given the likelihood of their having visual attention deficits on the left side and the need at intersections to watch out for vehicles approaching on the near-side lane. Furthermore, in an RHD car with manual transmission, the driver maintains his or her right (i.e. in the majority of people, dominant) hand on the steering wheel at all times and uses their left hand to change gear.

Cyclists and horse riders typically mount from the left hand side. This places them on the kerb when driving on the left.

The largest safety issue is the existence of two systems, right- and left-hand traffic. Visitors used to one system might forget that the other system is used where they are, for example, pedestrians looking the wrong way before crossing a street.

For me the worry in getting into an accident hurt my ability to focus on work.  I would believe there are others out there like me who feel the same way.

In the end working from wherever, with whoever, and whenever is far from becoming a reality.  We have a ways to go but it is not from a lack of technology, it is from the people who chose when and how to make that technology available.

CEO Poll > 68% feel IT is an inhibitor to business growth

A recent CIO Insight article a survey of over 150 CEOs showed that most of them believe that IT is an inhibitor to the overall growth of the company. Maybe not surprising to those in the Senior management positions within a company, but it should be a wake up call to those who believe that sooner or later their business partners will recognize the inherent business value that technology can bring to the table.

The problem that all IT leaders face right now is the cynicism and basic mistrust of any initiatives that IT proposes that does not show (in a traditional business sense) how it can cut the overall IT budget. CEOs and their teams are looking for IT leaders to cut costs. They fully believe and expect that their business towers can supply the resources and assets to utilize commercial off the shelf (COTS) products to sufficiently tap into the technology to help grow the business.

It's easy for someone in IT to look at that strategy as foolishness at the highest level since they have worked with those business folks expected to utilize the technology and know first hand that they have neither the background nor the understanding to leverage the proper tools in the vast COTS world. What's more is that they can only do what any other company can do with those tools. Without allowing an IT strategist to become involved and customize the solution by using not only his or her technological savvy but also their business acumen they are basically throwing in the proverbial IT white flag and considering that side of the business nothing more than overhead.

There are signs all over the the industry that this is exactly what is happening. IT is more often than not placed under the CFO. All initiatives go through the CFO and not the CEO. The CIO makes makes his or her case to the person responsible for the bottom line, usually someone with little IT background, except for perhaps the experience of how much it cost them to fix that ugly Y2K bug. Yes, they have been let down before and we in IT are all paying a heavy price for it.

Our CIOs have not been doing a good job of promoting the innate value of using technology as a strategic tool to give your company a competitive advantage. Any company or competitor can purchase COTS and by making this the core tooling strategy to improve efficiency throughout the company you are basically saying that your IT division is nothing more than an expense to the organization. If the CIO is going along for the ride and simply implementing COTS and cutting the overall budget then they are nothing more than an assistant CFO with some technology background.

While Wall Street is probably happy (cost cutting is the best way to get short term stock increases) but those who are truly concerned about the long tern viability of a company will not be able to compete with companies are are looking for IT departments not only to cut costs and to be efficient, but to also provide true value by suggesting and implementing technology that can give them a competitive advantage.

The above may sound like we are putting the blame and burden on the CFO and CIO. However it goes much deeper than that.

The initial proverbial bubble of trust between the business and IT from the business perspective popped at the turn of the century. Business leaders are still skeptical of EVERY new technological buzz word. Don't believe me? Try walking into your CFO or CEO office with the suggestion of Cloud Computing or Social Media. How about Service Oriented Architecture or Web 2.0. Now if you really want to see fire in their eyes, try walking in and talking about Oracle upgrade to 11g. How about upgrading to .NET 2.0 framework or using WPF for our presentation layer. For my final example, if you really want to get your pink slip, offer up Team Foundation Server or an upgrade to SQL Server 2008.

Shame on us for not being able to rebuild that trust over the past decade. Instead of learning from our mistakes of the past, we continue to try and force feed new technology down the throats of the business we MUST learn to think like a business partner and not like a technician. In fact we should try and immerse ourselves in the business culture and be business people with hyper technology knowledge. Further we need to be able to pragmatically propose technology solutions as business people and not as technologists. Finally we need to deliver on what we say without wasting money and later saying that "you have to expect some cost overruns in IT because there are so many unknowns". That's not going to fly in the decade ahead. Say what we are going to deliver and deliver what we say.

If we fail, we will continue to lose trust. This not only hurts IT, it hurts the company.

Microsoft MVC and flow control

I have been involved in several projects that utilized the Model View Controller design pattern. Typically these were custom J2EE or .NET applications that were modelled after the J2EE blueprint DP library. More often than not we used a package that was built internally that could plug and play with any new implementation. It worked well, the system was very stable with few to no bugs and could be used by any level of developer.

However for each unique environment or company you will need to build your own generic MVC package and that takes time and more importantly it takes buy-in from a business sponsor who could care less if you utilize MVC, XYZ or any other acronym'd flavor of the month. Even if you do get buy in, you need a commitment from internal IT leadership to ensure that all developers are in tune with the mindset required to work in a model first environment.

When Microsoft first came out with their own flavor of MVC in late 2007 I was hopeful that it would provide the standard plumbing that could reduce the overhead required for a new environment. For the most part, it did that. Yes, it was very rudimentary and was limited the amount of control you had in the separation of concerns, but it gave Microsoft Developers a good entry into the MVC world. In the past true MVC frameworks were mostly in the J2EE domain. I also came to respect the simplicity of the MS version since that should be what we strive for as developers.

The one thing that the MS MVC package is missing is proper flow control. Really the only thing within the MS model for flow control is URL mapping. I was able to speak with Scott Guthrie a few years back at a VS Live event and we spoke in great detail about this missing piece of the puzzle. He did say that it was a point of contention/discussion within the MS development team but that they ultimately chose the URL mapping model to KISS, which is again not always a bad thing. About a year after that discussion and after trying to integrate MS MVC maps into a service environment you quickly find that it is difficult if not impossible to easily take that step. The missing component is flow control.

Most SOA implementations involve heavy use of workflow and URL mapping does not integrate easily with this model. I recently gave a webinar on how to implement flow control within your MS MVC applications. I patterned my discussion (note the pun) after the Finite State Machine design pattern which basically gives every data movement a required start sate, possibly a bunch of processes against that data, and a definite end state. This meshes perfectly with the process flows that are so integral to your SOA implementation.

Adding better flow control to your MS MVC application also is crucial in allowing you to bring the business into your design discussions since the core of your state machine is based on workflow models, something business owners understand well.

Got an Idea? Put on your salesman hat!

As you know, here I try and promote the concept that building a foundation within your IT department that will allow you to setup standards, enforce them, and to ultimately give your development team the structure they need to succeed and to respond quickly to the business needs without sacrificing Object Oriented principles. Whether your IT staff is offshore, on site, or some combination of the two, there are common principles that apply that will ultimately help the entity you support save money by lower development costs, and ultimately better business tools.

From the feedback I receive, there is one common thing that is almost always overlooked. Selling these principles to the business sponsors.

I use the term selling loosely in that it can mean selling the idea of purchasing a software utility that can help you become more efficient (i.e. TFS, MOSS, Wiki) or selling a change in a process. I used Wiki as an example because sometimes selling new software is more about implementation planning and time as it is the actual cost.

Let's consider this fictitious scenario:

A company's IT department has some good architects and designers in various parts of the world, each with their own set of skills and own set of ideas. Every small to medium size company always has at least a few on their team that are well schooled in OO principles whether it deals with .NET development, Java development, SQL development, Oracle development, etc. Typically these developers are used more to keep the wheels on instead of leveraging their skills to help the IT department as a whole become more efficient and structured.

Let's say the SQL developer (we'll call him Corky) has an idea to create code blocks for common routines that are called from various applications but in different ways. He figures it would take him about two days to develop and test the code blocks in his scope and maybe another day to draft a technical document describing its usage. Being that he wants to follow the process of running ideas through the proper channels, he proposed the idea to his manager (Kim). Kim said it sounded good, but she wanted him to present the idea governance board for approval with her. Corky did the presentation and after being unable to answer questions regarding possible issues with certain environments and the implementation cost to each application that utilizes his new code blocks he got a big fat NO.

I think this has probably happened to all of us. You have a great idea that seems like a no brainer, taking to the approving body, and they turn it down.

The problem is that most of us in IT are poor salespeople. We fail to look at things from the business point of view. We know that our idea will help them in the long run, but we need to understand that they are thinking about what can help them today. If they know you are spending three days working on code blocks, and that other developers will be tied up implementing your idea, they see this as taking away from their current ongoing projects that are more closely tied to business solutions.

I am certainly not qualified to give you definitive advice on how to make your ideas "stick", but here are some suggestions.

1. Be good to your end users
   If you need approval for an idea, it isn't a good idea to make those you are presenting your idea to feel stupid. Typically the decision makers have less low level technical acumen than yourself. Present your ideas in a way that makes business sense. For example Corky could have started his presentation by saying that he can "recover 200 man hours each year which will give us time to setup that email notification system that you wanted and that we quoted 180 hours for" by implementing his code block idea, instead of saying, "this will standardize our SQL process". See the difference?
   
   In addition, always treat your end users and business sponsors like a customer who gets the full service treatment. Respond quickly to their requests whether or not you can help them right away. Try not to pass the buck. Take responsibility even if the problem is not in your area or focus. It will payoff in the long run.
   
2. Go beyond the walls of IT and learn the business
   I probably should have put this in front of number one, for in order to present things in a business sense, you have to understand the business. This is a good idea and goes beyond the scope of making your ideas stick. If you don't understand the business, you can't deliver optimum technology solutions.
   
   To understand the business, try to inject yourself into as many meetings and projects that require heavy interaction with the business. You can also use problem/resolution moments to get to know the business users. If you have been involved in delivering a business solution, make sure to check with the end users periodically to see how things are going. In fact you should probably setup periodic meetings. Ask them how everything else is going. Maybe you can learn things that you don't know. Finally, you should always read everything you can about your company. Whether it is their quarterly financial report or their newsletter. All of things can help you learn the business.
   
3. Understand the organization's structure and goals
   In addition to understanding your organization works and operates, you need to have a good understanding of their goals. This involves becoming intimately aware of the culture of the company. What does it stand for? What is their vision? Do they want to go global? Are their immediate concerns financial in nature, for example cutting costs? Be careful here. You cannot base all of your ideas on what will save money. One of the functions of any successful IT company is to create value that helps differentiate the business.
   
4. Build trust with your boss
   For fear of impugning the above three points, I will not say that this is the most important thing you can do to help to make your ideas stick. Oh what the heck, I will say that.
   
   If you have a good idea that you want to implement across the IT organization, sooner or later someone will ask your boss about the plan privately. If he doesn't trust you, you can forget about getting anything to stick. It is critical to always be honest with your boss. Never try and BS him or her with technical jargon that really doesn't make sense. Surprisingly I have found many who simply dismiss anyone who doesn't write code 9 hours a day as someone who doesn't understand technology. Don't fall into that trap. It is likely that your boss understands very well the technology. Just because he or she isn't familiar with the latest way to use delegates doesn't mean they don't understand how that concept can help the software.
   
   Also, avoid the temptation to sweep bad news about a project or assignment under the rug. It's better to over share than to under share. Management doesn't like it when information feels filtered, like something is being hidden. In that vein, it is almost never a good idea to try and go around your boss. Sometimes ambitious IT folks think they can get ahead by going around. Again, if you want to build trust you need to follow the chain of command. It will help you in more ways than just building trust.
   
   It must be said that in the end, you have to produce. You have to have some successes in the bank that your boss knows about and this takes time. NEVER walk into a new job and start pushing for changes, no matter how obvious they seem.
   

The idea (pun intended) here is that putting a new process, idea, software or game plan in place needs buy in. You can't simply think something is a good idea and expect it to get adopted. That only gets you half way to first base. You really have to get outside of your comfort area and press other buttons then your used to press if you really are trying to help the company with your plans.

Here are some references

• Four Secrets to Becoming a Rising IT Star
• Made to Stick: Why Some Ideas Survive and others Die by Chip Heath

Team Foundation Server Initial Implementation Strategy - Overcoming Inherit Obstacles

Although our company is currently going through the approval process for purchasing and deploying Team Foundation Server (TFS), we have already gone through an Application Life cycle Management review and have begun the process of conceptually applying some TFS features against some of our challenges.

One thing is for sure. TFS is a tool that can help just about any company that has an IT component become more efficient. However if you are thinking about venturing into these murky waters you have several obstacles to overcome.

Certainly you will have to deal with those individuals who are averse to change. Everyone knows people in their organization who are comfortable in their current process domain and are afraid that a change may introduce some discomfort, or worse are limited in their skill set and are afraid that a new process may expose some of those limitations.

I think it is critical that before you introduce TFS or any major change that requires adaptation and adoption you should ensure to those individuals effected that you EXPECT there to be some training and that they should not be afraid of venturing into uncharted territory. In fact the only way to learn new things is to get out of that comfort zone.

---

"By nature man hates change. Seldom will he quit his old home till it has actually fallen around his ears.... ...Thomas Carlyle (1795 - 1881) British historian and essayist

---

If you are able to get beyond the change adaption/adoption hurdles, you still have a long way to realizing your goal of implementing TFS, but I can't overstate the importance of these first hurdles.

Once you get everyone on board and excited about the prospect of finally having a single place to store your code and work through your development tasks, (well, maybe not everyone) you need to analyze and evaluate your current state in the area of source code management and application life cycle management. The first thing to do is inventory all of your digital assets and determine which ones are candidates for improved management. The obvious candidates are your source code libraries, however some may want to consider the prospect of storing associated documentation for your projects including UML docs, requirement docs, and perhaps even legacy project plan and sprint documents if you are in the agile world.

Once you have determined what you would like to see migrated over to TFS, you should prioritize the individual artifacts and move things in an organized and phased approach. I do not recommend moving everything at once. This would probably not be worth the effort since I am sure there is code out there that you will never need nor want to see again. It would also delay the actual prize of TFS which is using it in your current projects. Finally there is something to be said about starting with a fresh slate.

In our situation we had dozens of source code repositories located all over the globe, including on users desktops so we did feel that it was a good idea to bring everything into TFS. Note that there is a limit to how many projects you can setup in TFS so I recommend placing all migrated source outside of any project. Also because of this constraint you should be careful about trying to divide large project into too many smaller projects.

From Microsoft TFS site --- [Team Foundation Server can support a maximum of five hundred (500) team projects if you use the MSF for Agile Software Development process template for project creation. Team Foundation Server can support a maximum of two hundred and fifty (250) team projects if you use the MSF for CMMI Process Improvement process template for project creation. If you have more than five hundred MSF for Agile team projects, or more than two hundred and fifty MSF for CMMI team projects, you must deploy more than one Team Foundation Server]

In addition to your source migration, it is a very good idea to use a single prototype project as your first foray into TFS. You can use this as an opportunity to find out which features you will want your organization to use and which ones to avoid. In addition you can act as the guinea pig and document where you mess up. This will help others avoid your pitfalls.

Before you start your prototype, you should also go through the two process templates that are included with TFS. These are CMMI and agile. You will likely find that there are missing pieces in these templates and you can and should modify them via their XML definitions. Specifically, you should make sure that your measures align with the PM's measures. If not, you may get some complaints that the tool is not very helpful for the PM's and BA's. It is critical to consistently demonstrate value on that side of your IT organization or you will have trouble establishing a business case for future technology.

All of these recommendations are meant to help you avoid the common problems in all new IT initiatives. There is no question that TFS can provide significant value to your organization. These include efficiencies which should bubble up to the overall bottom line. But you need to remember that sometimes you need to help prove out the value because the perceived value is sometimes what matters in these early stages.

ref: Team Foundation Server Planning Roadmap

Language Agnostics

Wouldn't it be terrific if there was some lowest common denominator in speech language? Wouldn't you love to be able to go to Italy, France and Russia and be able to communicate without relying on embarrassing hand singles to find the nearest bathroom, or ever magnified head affirmations when you get a response that you don't understand?

Well, that probably is not possible in today's world and may never be. If you want to go to Italy and communicate, learn the language.

Fortunately in the programming domain, we do have that lowest common denominator in several areas of information technology.

I have been preparing a demo of Sybase Powerdesigner for the folks here and in addition to modeling tools that allow IT to communicate with the business in a meaningful way, it also allows us to write the bulk of our applications without specifying what language it is in.

As an example, for this demo I am going to show how to build a Conceptual Data Model. This is sort of the first step in the modeling process and can be created from Business Requirements and conversations directly with the business.
(Powerdesigner allows you to create Business Process Models (BPM's) that can generate your conceptual model. However for the scope of this conversation we are assuming that our interaction with Powerdesigner starts with the CDM.)
The CDM is where we build our entities and define the relationships (foreign keys) and some of the attributes of the entities.

From there Powerdesigner generates my Logical Data Model. You do this by selecting the option to generate a Physical Model, however instead of choosing a DBMS, you chose Logical Data model. From here we can define our indexes and our primary keys.

This is where we can stop, take a bow, and thank the modeling gods for allowing such a spectacular idea to surface in all of its glory. We have just created a language agnostic database. Or more specifically we have generated a DBMS agnostic model.

What Powerdesigner has done for me is collected the common concepts and features behind a databases meta data and made them available to me in the Logical Data Model. I am now King Kong. I can simply push a button and generate the code for a SQL 2005 database, SQL 2000, IBM DB2, Oracle 7,8,9 or 10, My SQL in 5 different flavors, Redbrick Warehouse, and a just about any other DBMS you can think of. How cool is that? Very cool.

Now the task is to get the rest of the IT team to embrace the concept and the value of bringing the abstract concepts discussed here and Language Agnostic modeling to generate code. Although I have only discussed database here, Sybase has the same ability to generate Language Agnostic classes which can create my code in any language I want.

I would be interested in others who have had to sell this concept and those who have been disinterested in embracing this type of culture.

More Team Foundation Server Business Case Talk

Here is a piece of advice for those of you who are trying to build a business case for TFS and are currently using VSS for source code control. Don't use as your sole business case the fact that getting licenses for TFS is cheaper than continuing with the licensing for VSS.

I know this is not true for all as Microsoft has a floating cost structure and different companies pay for different things. However in our case there was a significant cost savings by switching over.

I spoke with Microsoft reps and MVP's for TFS and most say that their customers are switching mainly for the more robust and reliable of the transactional approach to version control that TFS has. Further the ability to decommission VSS is the most compelling reason they have heard.

While all this is good and well, many companies have the problem in that the business has to approve work that IT does. It is hard to convince someone who is getting pressure to build the next great system for managing their sales force that they should instead spend on a product where the immediate benefits are not directed to the business in a way that is easy to communicate. I know, because we tried that approach and although it hasn't failed yet, it certainly didn't blow their skirt up.

If I had the ability to start over, I would not focus on version control at all. I would focus on the features that provide the most direct benefits to the business. For example I know that TFS allows for the development process to be more transparent. To me this is a huge benefit to the business. Instead of spending countless time with the business facing side of IT trying to determine percent complete on the different deliverables in a project, they can get those reports through SharePoint in a second. Further they can see quickly if projects are going out of scope, find out if they can reign things back in or if the scope creep was necessary. If so they can communicate this to the users requesting the new system and have documentation ready that explains the added cost.

Cost savings is another things that I would try and drive home better. I would not focus on the licensing cost savings at all. Instead I would try and champion the need for tighter code management, code reuse, and code consolidation. Instead of trying to manage dozens of different code repositories, we would only need one. If a developer is looking for some help in some area of functionality they can search for other code that may help them because now it is all in one place. And if I want to establish a culture of Object Oriented development techniques and have put in some standards, I have a much better chance of monitoring adherence if I can see all checkin's that are going on.

Hopefully someone will chime in on their war stories of trying to get TFS approved.