I pointed out in my prior post that there is some debate in the IT community about whether the functions of IT really shouldn't be performed 'in house' but should be outsourced. I think that the answer depends on the questioner. There are cases where it clearly does no good for the functions to be insourced. There are other cases where insourced app development, maintenance, and support operations provide a clear competitive advantage.
Regardless, the reason for outsourcing should not be laziness.
If a company finds it 'too hard' to figure out if the value of IT exceeds the cost of IT, they need help, expertise, and guidance. In some cases, it is tough to ask for help. But just because you may have a hard time reading a map... should you sell your car and take the bus? Taking the bus is a good idea, but not out of fear or laziness. It is a good idea for other reasons. Same thing with outsourcing IT.
Basically, every business that spends over 20% of their total IT budget on application maintenance must take the time and energy to create an application portfolio management. Otherwise, that cost is unaccounted for. Project management tells you what things cost but it gives you no way to dashboard that cost against value or measure amortization over time.
I had a PM recently tell me that the company should spend the money to 'get it right' on his application because 'the business will benefit for ten years.' It fell to me to tell him that, strategically, the application was providing redundant functionality and that the corporation was making plans to phase it out in three years, so his project had to yeild value in one year, or be cancelled.
That kind of information changes the nature of a project. What was originally thought of as a 'long term solution' became 'quick fix engineering.' The amount of refactoring dropped substantially. The replatforming of components disappeared. The team focused on producing better reporting and cleaning up an integration issue that improved productivity, rather than making the under-workings tidy.
That kind of information is not available without portfolio management. Sure, you can ad-hoc it. But if your company spends money on IT, and it is managing this money with an ad-hoc approach, your investors should be banging on the door, demanding the head of the CIO.
More importantly, if you decide to outsource, the information on your portfolio costs will be immediately valuable both for deciding if there is value in outsourcing and for measuring the performance of your outsource partner. Otherwise, they can make short-term cost cuts that you would never have approved, report a nice bottom line, and decieve you into believing that they have saved you money.
The mechanism for measuring the portfolio costs and value should be kept in-house. (Otherwise the fox guards the henhouse). If your outsource partner currently provides this service, bring the service in, even if you leave your IT outsourced. Then, and only then, can you independently measure the performance of your choices. That goes for all companies, whether they outsource or not.
So go ahead and outsource, but go with your eyes open.
This question has been asked before, but not often of people like the readers of this forum... the folks who write the code: Should IT be outsourced?
Reasons to outsource IT:
1. In some organizations, IT can never reach a size to specialize sufficiently, therefore permanently relegating the IT staff to generalist roles that are usually difficult to fill or may cost more to perform.
2. Many of the functions of IT provide no strategic value to the business, and therefore the business should seek the lowest cost way to provide those functions.
3. If you outsource IT, then the technical investments that are needed by any good team are not scrutinized by the business. Instead, they are hidden in 'service fees.' This allows the IT team to spend the money it needs on prevention rather than fighting forest fires.
4. Most IT shops are terrible at what they do. Rather than keeping a bad organization running, a company can do better by allowing the competitive market to pick the winners.
Reasons not to outsource IT:
1. Information buried in the corporation is difficult to secure if it is hosted at an external IT provider's site. The company is still liable for breaches in trust, even if the loss occurs because of an error at the outsourced provider.
2. If you outsource IT, you get non-strategic software. Any potential that IT has for providing strategic value is lost, because outsourced providers, by definition, are unable to deliver strategic value at commodity prices. (This statement may not apply to companies that simply outsource the staffing and management functions, but keep a team dedicated and on-site to deliver business solutions).
3. Outsourced IT workers are less familiar with your business, and may be less dedicated to the success of your business than regular employees.
4. Investing in IT is, for a large part, investing in people. Any growth of knowledge and skill earned as a result of IT money spent by a corporation is intellectual property accrued to the outsource provider, and not the company itself. Therefore, if staff changes or, heaven forbid, the company switches outsource providers, then all that investment in human minds is lost.
What do you think? Should IT be outsourced?
Did I miss an argument that you think should be in there?
Three different things. A process comprises steps, preferably in an optimal order, that leads to a business function being completed. Who owns the business process for 'enter an order' or 'validate a prospect?' Note: I'm not asking 'who does the work?' I'm asking, who decides that the process they are following is good, and is rewarded for it's goodness?
A solution is a subset of a process that involves automation using one or more applications. For example, a solution may involve adding data to three systems, checking some business rules, and/or sending notifications, seeking approvals, etc. This is an IT-specific construct used to model how the applications interact across one or more specific business processes.
An application is a set of executable components (perhaps) that delivers business functionality. (I have trouble with the definability of an application, for portfolio reasons. See my prior post).
To me, it is clear who owns what, but apparently there is some disagreement about the way it should be. Some technical leadership publications have begun to advocate that processes should be 'owned' by the business, but driven by IT. Others feel that the process is less important than the solution, and the solution is owned by IT. In other words, IT gets to change parts of the process at will and the business gets to deal with it.
On the other end of the spectrum, some folks feel that IT doesn't own any of them. That the business owns the processes, the solutions, and the applications, and that IT is just a service organization that keeps the lights on.
What is your opinion?
Personally, I'm no great fan of committees. Oh, they go by many names. Virtual teams, cross functional teams, functional groups, even alliances. At the end of the day, though, a group of people with no common management held together by someone's vision of a goal is still a committee.
In the world of IT Simplification, where you examine the portfolio of applications in an area and decide which ones will survive and which ones will be phased out, you need someone to own the decision rights for this process. There will be hard choices to make. Someone's favorite tool will die, and some tool that someone hates will become the corporate standard.
Traditionally, the area of simplification has been ad-hoc. Teams have been created out of stakeholders in a specific area, and perhaps that is the only way that it works. What I'm considering: how much of that team should be 'standing.' In other words, should specific organizational roles be automatically identified to be part of a group of people responsible for Simplification in a specific area?
The problem with this is that applications skewer the organization in ways that no heirarchy can predict or defend against. One app can have implications to marketing and sales, another to marketing and operations, another to R&D and support. It is possible, nay LIKELY, that an application's reach will end up drawing two or more people into a committee to simplify, where both have the titular responsibility for Simplification.
And when you invite two chefs into the kitchen, an argument is inevitable.
On the other hand, if you don't identify roles to automatically be part of the group, you run the risk that no one will actually own simplification for a heirarchy.
Perhaps Simplification should ONLY be owned at the CIO / Corporate IT level. Heck, I don't know. It's a puzzle at the moment.
If anyone has opinions, please share.
On further study, simplification patterns are about where capabilities move over time. Migration patterns are about how the channels of data flow change over time. They are different. While I may end up working with Matt on migration patterns, they will be a different grouping within the overall set of patterns.
I'm going to try to get back to architecture in this blog.
I spent some time this afternoon going through the simplification patterns that I have identified to date with another member of the Microsoft Enterprise Architecture team, Matt Willis. He's a very smart guy, and he was looking for patterns that could be used to describe the strategies used in migration from a present state to a future state architecture.
One of the things that became apparent fairly quickly is that there are patterns that are useful in migration, both in terms of strategy and in terms of tactics, that are not simplification patterns. They don't, in and of themselves, yeild a simpler set of systems. Yet, in the course of a series of projects that will, ultimately, yield a simpler system, these patterns are needed in order to shelter one system from changes in another, either in terms of integration protocols or in terms of data dependencies.
Yet, while these patterns yield static structures, they are just as dynamic as the simplification patterns I have identified already, because many of the static structures generated as part of a migration strategy are put in place for a specific reason, and may be solely a temporary thing.
Just as civil engineers will design a road improvement project to include 'temporary lanes' for traffic to flow through while a permanent lane is being constructed or paved, architects may have to move capabilities into temporary systems, or in less-than-final data pathways, to allow for one system to change independently of another.
One example is a contracts system that I work with. It has a very stable and well-put-together database that captures the rules for composing contracts as well as handling aspects such as formatting, red-lining, versioning, assembly, approval, activation, and document life-cycle. The front end, however, is an aging VB6 client-server app that isn't too amenable to adding capabilities.
Another team needs a contract system, and they want it to be web based. I want to end up with one system, not two. Now, the easy thing would be to give the source code to the legacy system over to the other team and walk away. They build what they want, and we are done. However, we will go from having one system to having two... hardly a good stroke for overall IT simplification. On the other hand, there is a good strategy here. By moving the second business stream to the same tool, I can improve the tool to be able to handle both business streams. Also, if I want to replace the tool with a commercial package, including Office 12's document lifecycle capabilities, I will end up killing two birds with one stone.
So short term, we will copy the database to another server, and allow the other team to build their own web interface. At this point, we will have two systems. We will then, as a step 2, migrate the data and additional functions to the web-based version and kill off the older version. There are two patterns here. The first is to extend the original tool to add new capabilities, and the second is to see two overlapping systems and to replace them with one. I have names for both patterns. (Build to Suit, and Marry Up). However, it is the two-step process that produces the resulting simplification.
That process is itself a pattern. It is not tactical, like Build to Suit, or Marry Up. It is a strategy pattern. It says "combine streams onto a tool by allowing the tool to be extended for the second team, and then to onboard the first team to the extended tool, rather than extending in place." Implementing this strategy an be done using the two tactical patterns above. However, those tactical patterns can be used in other situations as well.
This changes things for me. My article on simplification patterns now expands to cover the notions of migration strategy patterns, capability simplification patterns, and dependency simplification patterns.
I still haven't described the patterns in a public paper. I'm hopeful I'll get something up in a few days.
I just wanted to get back to some sense of life and, for me, what passes for normalicy. I'll dedicate the book to the leader of the band.