IT Hyper-Specialization and Outsourcing: Guaranteed to Fail

What happens to a computer program when you divide all of the key functions into 16 subprograms and you make the program execute via in-process methods?

Now what happens when you take those 16 subprograms and move them into separate processes on the same computer?

Now what happens when you take those 16 subprograms and move them to separate computers all around the world?

Now what happens when you take those 16 subprograms, all over the world, and every time these subprograms need to pass information to one another you do the following:

1. Print out the data to be passed
2. A person picks up the document off the printer
3. The person figures out which subprogram this information is destined for.
4. The person sends the document via interoffice mail to the office that has the right server, running the target subprogram.
5. At the target location, a person takes the message, and types it into the server program by hand.
6. The person waits for a response.
7. If there is a response, the person at the target location prints out the document.
8. The person send the response document back to the correct site.
9. A person takes the return message and types it in by hand and waits for another message.

In the first case, you have a system that can perform about 100 million operations per second given today’s processors.

In the last case you have a system that can perform less than 16 operations per day. Over time it will probably be more like less than 1 per day due to contention issues and wait states.

Now, lets take the model above that no Computer Scientist would contest as being an extreme failure, and apply it to business.

What happens to a business process when you divide up all of the key functions into 16 tasks and hire an expert that can complete all 16 tasks - where all communication and problem solving occur between neurons in the experts’ head?

Now what happens when you take those 16 tasks and move them to different, low cost workers all located in the same shared space?

Now what happens when you take those 16 tasks and move them to low cost workers based around the world?

Now what happens when you take those 16 tasks, performed by low cost workers based all around the world and between each person you add change control, governance and approval steps?

In the first case, you have a system that can perform complex problem solving and task execution in minutes.

In the last case, you have a system that can perform a many tasks at the same time, but because of contention issues, wait states and communication millions of times slower than neuron to neuron communication, processes which used to take a few minutes can take many months or even years now. This is the model that most companies are selecting as optimal for their IT organizations.

I am constantly amazed that IT staff understand so little of computer science that they cannot understand that the current hyper-specialization and sourcing models not only are significantly more expensive when you look at all costs, they are literally millions of times less efficient and productive. It is as if our competitors are designing our organizations. There is no better model for high expense and catastrophic failure than the current model.

Most companies could replace hundreds of IT staff and departments that are over specialized with a handful of experts who were allowed to control all aspects of their role.

REVIEW: Balsamiq Mockups

Very rarely have I successfully used a tool to prototype a GUI. If it looks like a computer program with the standard menus and buttons, people expect it to be a functional computer program. Very few customers are sophisticated enough to understand the distinction between a functional program and a non-functional prototype that looks like a finished program.

Balsamiq Mockup changes the rules of the game. This easy to use tool allows me to quickly create an interface (like one would in a GUI builder) and at the end I have a series of what looks like hand drawings instead of what looks like a finished computer program. It runs on Adobe AIR so I can use it on my Mac and my PC (when I have to) seamlessly and I have the same great functionality on both platforms. I have never had an issue with it to date and it just works.

I am using Balsamiq Mockup for my non-profit work on the Feed The Need redesign (this link is to the original version - new version is in progress) and have been able to communicate design issues and decisions better than ever before. I am excited about the product and dream of the day when all GUI designers use something like this first to make the first design models. I know I will use this for all the design work I do in the future.

Service Organizations and the Pyramid

Most corporations larger than a few hundred people grow pieces of the organization that serve other parts of the corporation instead of their primary customer. This approach is so common-place, that author Max Barry was able to use it as a backdrop to his plot in his third book, Company. This book takes things to the extreme and the hero of the book finds the company he works for actually has no external customers, each department is just selling their services to other departments within the same company.

I have worked in a few companies as they have gone through growing pains of building shared service organizations. I have spoken with friends from other companies who have had similar experiences. I think of the desired and actual outcomes of a shared services organization as a pyramid.

Pyramid: For the purposes of this example, we will limit our discussion to corporate IT. In that case, the narrowest point of the pyramid is the group that works directly with the business group they support. In the case of the manufacturing & supply chain, these are the IT people who sit with the business, understand the business and deliver solutions to the business. The next layer down in the pyramid is the group that liaisons between the business facing IT and the most specific shared services. In our example, this may be the group that specializes in business processes and architecture for manufacturing and supply chain. The next layer down will be the group that liaisons between them and groups like DBAs and Network engineers. So, overall, the pyramid is narrowest where the IT has direct interaction and impact on the business and is broadest where that shared service group is used by all divisions in the organization.

Desired Outcome in Pyramid form: The desired outcome is that the pyramid be narrow point up. The higher levels (towards the tip) have increasing ability to make judgement calls and decisions based on business need. All of the layers support and deliver through the Business Facing IT. The shared service groups exist to support the project teams that are delivering direct business value. The work comes out of the "top" of the pyramid - in this case, the business facing teams, who ensure that the value / dollar is maximized for their clients.

Typical Outcome in Pyramid form: The usual outcome is an inverted pyramid with the narrow point down. The actual behavior seems to turn to protecting and limiting asset use. In this case, the higher levels (at the thickest end) have the remit to make all of the decisions and thus the shared services are in a position to say "no" and "you have to prove to me you need this". Instead of supporting the business facing IT, this common form of shared service, becomes a bottle neck and a roadblock to real business impact. The work comes out of the "top" of the pyramid - in this case, the shared service teams, who ensure that their assets are protected, their Q.A. is satisfied and their financials are in order. This is usually a very expensive proposition and tends to rarely deliver real business value.

Example: A colleague of mine went to a seminar. His leadership team asked the organization what was the one thing they could do to help them all be more successful. My friend stood and asked for a very short, no nonsense objective for IT like, "We help make our scientists smarter." Bold, yes, but that was the point he said. One of the senior management said that they already have a few of those objectives. He said "they are 'Build repeatable solutions' and 'Use shared services'". My friend sat down and was not surprised, but was disappointed. He said he knew then, that with an upside-down pyramid as heavy as theirs, that many important business facing initiatives and high value projects would be crushed by the weight of the generic, one size fits all shared service.

Moral: If you want to know what kind of IT organization you work in, ask your senior most IT management what the objectives of the IT organization are. If these objectives are simple and short and detail specific business value then congratulations. If the IT objectives are generic and could apply to IT organizations in NASA, just as easily as they could apply to Amazon or Gartner, then your pyramid is upside down.

The 3 Flavors of Enterprise Architect

I work in a very large company and I am the lead architect of one of the divisions. I have had various architecture positions at different companies and I have had this current role for more than a year. I work with some very smart architects who are organized to business domains or disciplines and we are working together very well. There are many other architects and architectural organizations that are not having similar success. We meet sometimes for lunch and sometimes we talk about what it means to be an architect. I realize some of you have just thrown your computers out the window or tried to commit seppuku with some powerpoint printouts, but I continue.

In my experience, I have seen thee classes of working Enterprise Architects. There are others who are in Enterprise Architect roles and I will have a fourth bucket for them, but I would point out that they are not functional architects in any capacity. The classification solidified for me when I thought about where people I know came from - what is their background. Then it all clicked. For your pleasure, and so I can remember them, here are the categories of working Enterprise Architects I have seen in the wild.

Operations => Enterprise Architect

This architect has a background in process and operations. They are good to great at running a meeting and good with schedules. They need a lot of help understanding some of the things that are discussed if the topics get too technical. The value this person brings is that they can make things run if they are surrounded by people who know the business and the technology. This person does have a difficult time in making those architectural decisions as they have to depend almost completely on others. If you can find a good one of these they can really help your team be more effective. If your whole team is made up of people with this heritage, look for a new job.

Q.A. => Enterprise Architect

This is the one I have seen the least and like the least. This group of people came through some sort of QA organization and specialized in compliance of some kind. They are typically good at knowing corporate policies or common standards. The weaknesses are similar to the above. This "breed" of Enterprise Architect became most clear to me when I watched this. I am sure the presenter in this video is a nice person, and she adds value to her clients, but people I know with this heritage have been a death knell for any project / program / initiative I have seen.

Tech Lead => Program Architect => Enterprise Architect

This one is the most interesting to me and possibly the most difficult to find. It is clear to me that one of the primary signs of a person who will be successful in this area (besides having deep technical skills) is in both thought process and discussion, they must have the ability to move between levels of granularity incredibly rapidly and communicate clearly while doing so. The successful EA from this background needs to be able to communicate effectively with technical leads, executives, business analysts, business customers and project managers all about the same topics in language they each understand and does not pander to them. Sometimes in the same meeting. I know very few technical people who can make this transition. Many great technical leads cannot get past speaking at a very detailed level in strategic discussions. They may try to dominate discussions with things they feel they can contribute that really have very little to do with the subjects at hand. I have never met anyone who learned this skill. The reason I like this one the best, and why I try to find people like this to work with is because, if they are successful in making this transition, they "get it". They know how things work and they can communicate clearly with anyone so that it makes sense to the person they are speaking with. They are also the one class of Enterprise Architect who can be neutral when deciding who to invite to a brainstorming session as they can tie all of the discussion and best thinking from across the enterprise together. They have the most value and the most power because they can use all of the best thinking in the enterprise and they can communicate back to the enterprise what the value of any particular initiative is.

Everyone Else => Enterprise Architect

I know many other people in Enterprise Architect roles in many companies and I can fairly safely say that none of them are operating in any "Enterprise-Architecture-Like" capacity. Sometimes people get put here as you would put someone on special projects. Stay away from these folks for anything important and help them where you can as they are fish in a galaxy that has no water.

I guess in a nutshell, my view of the value propositions of each are as follows:

Operations => Enterprise Architect: I can plan things and create and run teams really well. Where process will streamline I can add that.

Q.A. => Enterprise Architect: I can tell you that what you did does not meet compliance with something.

Tech Lead => Enterprise Architect: I can do things. I can work with the smartest people in the company to progress our portfolio.

Misc => Enterprise Architect: Self referencing null object. Help them find a place in the organization where they can be successful.

Pragmatic Services

It seems that the discussion about REpresentational State Transfer (REST) vs. SOAP as the preferred approach for service development is over for many people. There articles about SOAP being irrelevant seem less emotional and seem to lack the fevered pitch they used to have.

You look at the vendors though, and I don't see movement in this direction. One could review the offerings and speculate that a primary reasons vendors are spinning with SOAP is that have not figured out how to monetize REST. You talk with people developing RESTful systems and the point is they are solving business problems instead of using a technology. It turns the whole discussion towards solving a problem - what real SOA is supposed to do. I love that. That may be another reason the vendors are having trouble getting traction in this area; they need us to focus first on the technology stack.

Cost of Storage in Fortune 100

I have this friend who was telling me about the storage constraints (read costs) at his company.  He told me that for 10TB storage they were billed $1.500,000 by their internal IT group.    I call him up now and I cannot stop laughing.

I juxtapose this with a post @ 37 signals about their experience with Amazon's S3 storage offering.  The article is here.  The part that struck me the hardest is as follows:

The fact that S3 is priced so reasonably (our last bill was $2,004.12) and the fact that it’s generally hassle free has enabled us to drastically increase the storage limits for all of our applications....

March 2008:

• 8.8TB of data stored
• 1.5TB uploaded
• 2.9TB downloaded
• 12M requests

The thing that is so surprising and the thing that really prompted me to post this is these two data-points side by side and then someone commenting at 37signals that 2k/month is a "crap load of money".  At my friends company most mid-level (non-management) staff has approval for that much money and more.  This is a very reasonable charge for this amount of storage and the maintenance and backup of the storage.

I am glad that Amazon S3 exists and I hope at some point, the people selling storage to my friends company sees that the obscene margin they have historically had is just not sustainable.

My Sister is in Newsweek

How cool is that? Story is here.

In the past, women dealt with that reality in two ways: some buried their femininity, while others simply gave up their techie interests to appear more feminine. "For most of my life I hid my passion for all things scientific and tried to focus on pursuits that were 'allowable'," says Cathy Malmrose, a Berkeley, Calif., mom who, at 38, is now the CEO of a computer manufacturer. "Instead of getting to play on my brother's TRS80 [computer] and study the sciences, I went into elementary education."

Hey everyone - that's my sister. In Newsweek. Being a CEO of ZaReason. Now that is cool.