Enterprise Initiatives

After writing an article that discussed embracing open source, one of my colleagues entered my office and gave me the "Eat your own Dog Food" speech. So he downloaded Ubuntu Desktop for me using BitTorrent and burned me a CD. The install was simple and I was up an running in minutes. I have been running without one piece of Microsoft software on my laptop for three weeks now and I am loving it. Free at last, Free at last!


There are some challenges though. Open Office is a great replacement for Microsoft Office but I can't find a replacement to read existing Visio diagrams. Today I received an MS Project file that I couldn't open. I am sure if I search the net I can find an open source tool to do the job. I also had a problem with my printer driver which took some time to resolve. Thunderbird is a great email client but it doesn't have hooks into my Outlook Calendar so I can't use it for my corporate mail. I am using Evolution which is only marginal. When time allows I will test out Sunbird and Lightning.

But with all of that aside, I no longer wait for 5-10 minutes for my laptop to boot up. I don't wait forever for Outlook to come up in the mornings, and I don't get any system crashes. The blue screen of death is a distant memory and the daily reboot routine is no longer required. There are no stupid paper clips popping up asking me if I am sure that I know what I am doing.

I am sure my freedom will end when somebody in desktop services realizes that all of their Big Brother software is not being run on my laptop. I will enjoy the ride while it lasts.

I know the majority of the corporate world isn't quite ready to replace their Windows desktops with Linux yet, but I can tell you from my experience that Ubuntu is ready for prime time.

More war of words between giants. Ballmer laughs at the IPhone.

First Ballmer laughs at Google, now he mocks the IPhone. My dad is a long term Microsoft stock holder. Every time I hear Ballmer talk I tell my dad to sell.

Many of the folks I know who have issues with Linux, lean on unproven myths and perceptions to prove their point. I prefer to back arguments with research and real data. In doing so I stumbled across a well-researched article that answers many questions about the Windows vs. Linux security debate. It is a rather long article so I'll highlight a few sentences out of it.

While discussing the myth, "Windows only suffers so many attacks because there are more Windows installations than Linux, therefore Linux would be just as vulnerable if it had as many installations", the article states:

...according to Netcraft, 47 of the top 50 web sites with the longest running uptime (times between reboots) run Apache. None of the top 50 web sites runs Windows or Microsoft IIS. So if it is true that malicious hackers attack the most numerous software platforms, that raises the question as to why hackers are so successful at breaking into the most popular desktop software and operating system, infect 300,000 IIS servers, but are unable to do similar damage to the most popular web server and its operating systems?

Malicious software is so rampant that the average time it takes for an unpatched Windows XP to be compromised after connecting it directly to the Internet is 16 minutes -- less time than it takes to download and install the patches that would help protect that PC.

While discussing the myth, "Open source is inherently dangerous because the code is readily available", the article states:

Windows Server 2003 has experienced the most severe security holes. Microsoft's own classification of the flaws shows that 38% of the patched programs are rated as Critical. If we apply the metrics outlined in the previous sections, we would have to raise that to between 40-50%.....In sharp contrast, of the 40 vulnerabilities listed by Red Hat, only 4 are rated as Critical by our metrics (Red Hat does not list a severity rank for its alerts). That means 10% of the most recent 40 updates are of Critical severity.

There is a lot more good information in this article so feel free to read more...


read more

Business executives often hear a mantra from their IT departments that goes something like this: "We can't measure the value of IT. It's too intangible." If the line works, and IT leaders persuade business executives that IT investments are somehow fundamentally different from other types of business investment, IT is relieved of the re



read more | digg story

The most important part of a healthy SOA lifestyle is an organization built on trust



read more | digg story

I have read and posted several articles about the many business and IT benefits of SOA. I haven't seen much talk about the benefits it creates for the individuals within IT. This article focuses on the potential career path opportunities that a Service Oriented Architecture can create.

Many IT shops that do not have a well defined architecture have a limited career path for those folks who want to stay technical and not go into management. There are typically a few levels of development (programmer, programmer/analyst, sr. programmer, etc.) followed by an architect role. There is only room for a few architects so most people with over 10 years of experience get stuck in the sr. programmer role for long periods of time. People stuck in this role tend to do one of the following:

1) Go into management soley for the purpose of getting promoted. Many of them return to development, leave, or do not perform at previous levels.

2) Leave due to lack of opportunity.

3) Become miserable and unmotivated

Enter SOA. Companies moving towards SOA may develop a layered architecture like the one in the following picture:

Within each layer you can see specialized roles and job responsibilities. Some of the roles (DBA & Configuration Management) will likely already exist in your organization. Some of the others may be new or the job responsibilities may change dramatically. The point here is that for those organizations with many talented IT professionals who are stuck at a dead end technical career path, SOA might be the answer to your prayers.

Some of these roles (Process Analyst and Enterprise Architect) are best suited for technical folks with great communication skills. These people will interact often with the business. For those who would rather not be exposed to the business, there are many other roles for you (Configuration Management, Object Librarian, Information Architect, etc.). Your more junior developers or people who prefer web development can live in the presentation layer. They will be extremely productive since most of the business rules and services will be available for them to assemble into the UI's. The folks who just love to bang out code can live in the business rule layer where they can develop components and services. The more seasoned developers will build enterprise components and services (i.e. encryption, authentication, error handling, etc.) while the others can focus on application specific components and services (i.e. create order, print invoice, etc.) .

Most IT shops will have pockets of people who don't like change. They may not be interested in these new roles. Those folks can focus on maintaining the legacy systems.

In summary, SOA has many benefits. For IT professionals, many new roles will be created and your company's IT career path will most likely be extended. Over the next few years, more companies will be moving towards SOA and the demand for SOA professionals will be great. So embrace SOA if your company is implementing it. SOA will create many opportunities for those who take advantage of it.

I have been in IT for over 20 years. I have seen people do or say some real bone head things over the years. Here is a short list of some of the bone head moves that come to memory.

5) In an interview, I asked one guy to describe his worst boss. He went as far as to name his worst boss. It just so happened that the fellow he named was a good friend of mine.

4) I had one guy call in sick his first day of work because he had a fight with his girlfriend (he actually told me this). He wound up calling in sick 7 times in his first two months. I fired him before his 90 day probation period ended. He called me three days later and asked if I would be a reference.

3)I was showing a demo of an inventory system I wrote to the head of a hospital. The big wig decided to drive so he started entering data into the forms. At one point he was prompted to "press any key to continue" and he asked me, "Where is the any key?".

2)We had a user who was complaining about issues with a floppy disk. We asked him to send us the disk with a note describing the problem. When we received the disk it had the note stapled to it. We told him we found the problem, there was a staple in his disk.

1) I worked for a retail pharmacy for a number of years. Once a disgruntled former help desk person called up a pharmacist and walked him through the process of cutting the Ethernet cable from the store PC.

I was recently asked by CIO.com to contribute to their blog section called Advice & Opinion. The name of my blog is Delivering the Goods.

My most recent post is called The Proof is in the Pudding which discusses the importance of Proof of Concepts (POC) during vendor evaluations.

When evaluating BPMS vendors beware of the eye candy. Many of the pure play vendors have some of the finest charts, graphs, simulation tools, and optimization tools. The real value in BPMS tools is the modeling and integration capabilities. This is where the stack vendors excel. The eye candy can really get the attention of the business users but those features only account for about 10% of what the tools will be used for. At the end of the day, the software must integrate with your back end systems and your business and process analysts must be able to be productive with the modeler.

So buyers beware. Take off the rose colored glasses, roll up your sleeves, and look under the hood. Don't buy the fancy wrapping, buy the goods inside the box.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 5, I will focus on Lack of Process.

Many people in IT think of process as paperwork, overhead, or even a total waste of time. I have seen some processes that fit those descriptions. But in those cases, somebody implemented processes for the sake of having processes instead of implementing a set of processes that help IT deliver quality software and services.

Companies with no processes or ineffective processes have the following issues:

1. Reactive mode, constant firefighting
2. Consistently deliver late and over budget
3. Sweat shop mentality, working hard instead of smart
   
4. Low morale
5. High turnover

All five of these issues are extremely expensive. If you owned your own company and it had these issues would you ignore them? Many IT shops that have these issues look to offshoring as the answer. Can you say doomed? If you can't manage your own internal resources and projects, what makes you think you can manage a group of people in another country? Even if you pick the best offshore resources in the world, the overall success of your projects still rely on your ability to manage them. In other words, it depends on your processes.

There are many types of processes and methodologies that are proven. They range from strict methodologies like CMM and its 5 levels to Agile Methodologies and Extreme Programming (XP). The proper methodology depends on your company culture, your products and services, and your budget. If you are sending a man to the moon, you should use a very strict methodology like CMM. When lives are on the line or millions of dollars are at stake then no short cuts should be taken. If you are implementing infrastructure projects then the PMI methodologies can be a good fit. They provide a good step by step or check list approach that helps you assure that you have not missed a step. If you are delivering applications on the web or providing features for internal or external customers then you probably want speed and that is where Agile and XP come in. With these methodologies, you want to iterate through all phases and deliver in quick intervals. These methodologies focus on getting the right features into the hands of the users quickly and discourage trying to anticipate every user need.

But process isn't just about delivering new software and services. Project prioritization and production support are two critical areas that need to be managed effectively. If either of these two areas are not under control, your chances of success are greatly diminished. Here are the effects of not having a good prioritization process:

1. Over allocation of resources
2. Not working on the most important projects
3. Constant changing of direction, lack of focus
4. Frequently run over budget and delivering late

Here are the effects of not having effective processes to manage production support:

1. Putting out the same fires on a daily business
2. Poor quality applications due to constant patching
3. Poor customer satisfaction
4. Low morale and burn out
5. IT unable to launch strategic initiatives due to high cost and resource constraints
   

So what should you do? Two things. First, implement portfolio management. I wrote an article that could help you get started quickly. Second, look at implementing change management or service management best practices like ITIL or Cobit. By using the best practices for managing change and support, you can reduce your costs, improve your quality, and free up resources to work on high priority projects.

I grew up in a family business and brought the entrepreneurial spirit with me into corporate America. I struggle to accept how some IT leaders do not manage IT like it is their own family business. These leaders are smart people (usually) and I know that they would be taking a different course of action if it was their own family fortune that was on the line. For you IT leaders that live in the world of chaos and firefighting like I have described throughout this series, if you won't drive change for your company, consider doing it for your people. Working hard instead of smart is not what we all envisioned when entered the exciting world of computer science.

This wraps up the 5 part series on running IT like it's your business. I will follow up with a conclusion that discusses how to implement some of these initiatives. Thanks to those of you who have stayed with me for this long series. Please provide some feedback. I would be happy to clarify any points or dive deeper into any topic.

It looks like Steve Ballmer's new strategy is if you can't beat 'em, sue 'em (here). Maybe Ballmer has finally seen the writing on the wall. More and more articles keep popping up like this one. Here is an excerpt:

A CIO Insight study of 90 companies with revenues below $500 million finds that 90 percent will use Linux by the end of 2007. Most companies that use Linux plan to expand its use, and are building applications to run on the operating system. What's more, Apache, Firefox, and a broad range of other open source Web and application tools, database systems and development tools are also taking hold. These products are proving so successful at lowering costs and meeting corporate requirements for flexibility, integration and security that four of five companies plan to expand their use, too.


Couple that with the Microsoft's issues with Vista (Microsoft admits Vista failure & Speech recognition demo gone bad) and the future suddenly does not look so bright anymore for Ballmer. Ballmer continues to laugh at the notion that Google is kicking his butt, but instead of becoming innovative, he continues to deliver bloated operating systems that force companies to upgrade or buy new PCs.

So Ballmer's new strategy is to sue the open source community on 235 patents, although he "refuses to identify specific patents or explain how they're being infringed". Maybe his next strategy will be to link Linux to Al Qaeda.

There's an interesting aspect of Google's impact on our daily lives. The Internet is so useful - despite its quite chaotic organization - and Google is so good at retrieving information, that we don't bother to remember anything anymore.



read more | digg story

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 4, I will focus on Lack of Metrics.

Many IT shops are stuck in maintenance mode and live the life of fire fighting and working hard instead of working smart. These shops struggle to meet the demands of the business and spend most of their time and money keeping the lights on. The business is reluctant to release more funds to IT to fix their issues because they don't see the value that they are getting for their current spend in IT. Your CEO is telling you to do more with less and you are asking for more resources to stay afloat. What gives?

I have heard the grumbling within IT wondering why the business "doesn't get it" or why "they can't see that we need resources". The business has a full time job and expects IT to do their job. They don't have the time to sympathize with IT because they have their own battles to fight. What you have to do to get their attention is to tell a meaningful story that is based on facts (metrics) and discussed in business terms (dollars). So before spending another day complaining about the current state of affairs, start brainstorming about what metrics you should be collecting to allow yourself to paint a picture for the business.

Metrics can be used a couple of ways. First of all, I am not a big fan of coming up with metrics to try to measure the productivity of developers (function points, lines of code, etc.). These types of measurements do more harm then good. I am not looking for metrics that show a distrust in your teams ability to do their jobs. I am looking for metrics that can capture opportunities to make improvements in the enterprise. Tracking where time is being spent can be a valuable exercise. You should know how much time you are spending on product support and maintenance and put plans in place to reduce these numbers by some percentage each year. You should also measure defect types and severity by application so you can put task forces in motion to improve the problem areas. If you ever want to get out of support hell, you must be proactive.

If the business does not think that IT is providing value, you can use metrics to show them otherwise. Metrics about availability and uptime, SLAs, change requests implemented, money saved due to process or performance improvements, and many others can highlight the things that IT brings to the table. Create executive level dashboards that sell the value of IT real time. One of IT's biggest faults is that IT rarely celebrates its success stories. IT falls victim to the "what have you done for me lately" routine. If you got it, flaunt it!

Once you have your metrics in place, you can start the long journey of continuous improvement. Attack your top problem areas and tie your metrics to dollars. The business listens and understands money. They typically don't listen to or understand technology. When you do need to go to the well to ask for resources, you should have plenty of facts that you can tie to dollars to sell your story. Despite some of the griping within the gallows of IT, the business is not blind. IT has just never provided them with enough data to see the light.

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 3, I will focus on Lack of Tools.

If you owned your own construction company, would you equip your workers with hammers or nail guns? Many IT shops create budgets that focus mainly on business demands and infrastructure but forget about funding tools and initiatives that increase the staff's overall productivity.

Human labor makes up a large part of IT budgets. So why not invest in tools to allow your IT professionals to deploy faster, provide more visibility into operational efficiencies, provide better access to information, and automate administrative and repetitive tasks?

If you don't want IT to be viewed as a cost center, then look for ways to make your resources more efficient. There are vendors like Mercury, Rational, and many others that provide a suite of tools from project management, to development, to testing, to change management. These tools allow you to enter requirements, automatically generate test cases, and provide visibility into requirements traceability. These can be time consuming and error prone tasks without the use of tools. If you are a .Net shop, investing in MSDN, Visual Studio Team System, and the new Silverlight product provide tremendous productivity gains. If you are developing with Java, Ruby on Rails, or a variety of other open source technologies there are a ton of great development tools and they are free! But don't stop there. There are tools for configuration management, source control, defect tracking, modeling, and the list goes on and on. If you have home grown systems to perform these duties then you don't understand the term Total Cost of Ownership (TCO). Why build and maintain these types of applications when there are companies and open source communities that have massive amounts of resources and R&D efforts to continually improve these products while ensuring they meet standards and keep abreast of modern technologies? Although some of these tools can be expensive, nothing is more expensive then having IT professionals performing tasks that can be automated by these suite of tools. And let's not forget testing automation. If done right, regression testing can be fully automated and executed as part of your daily build process. How many times has development delivered a build to SQA only to have it fail simple regression tests? I have seen several days wasted as build after build is failed by SQA and returned to development. With automation, all builds should have already passed regression testing before even showing up on SQA's door step.

Investing in PPM (project portfolio management) and problem management tools gives IT professionals the ability to proactively manage projects and production support. By having visibility into the progress of projects and the health of production systems, IT can prevent issues from occurring or at least address the issues early before they become catastrophic.

Access to information is an extremely valuable tool. This is often known as Knowledge Management. Tools such as portals, collaboration, wikis, blogs, and knowledge bases, are great tools for sharing best practices, training materials, standards, and various other forms of documentation. Investing in quality search technologies can be a huge productivity enhancer. Here is an article that claims that employees performing ineffective searches and wasting time looking for information can cost companies up to 10% in salary expenses. Ten percent of your staff's salary can easily justify the costs of search technology. Some enterprise portals, like BEA's Aqualogic UI, are implementing many of the new Web 2.0 features like tagging and ranking which are an extremely effective way to present relative information to IT professionals.

And finally, how many times have you seen your development staff rapidly develop and test some new feature only to have it take days or weeks to labor through a whole host of manual processes and procedures in an effort to deploy the functionality. All of these processes should be automated through work flow, including the approvals and audit trail. The work flow provides visibility into the status of the request and can automatically deploy the features if designed correctly.

In summary, when looking at tools think about the TCO. The more effective your staff is, the lower the cost of deployment becomes. In addition, by increasing speed to market you also create more throughput. More throughput means more business value. One last note. If you are still scared of using open source for enterprise applications, there is no better place to test open source's value at low risk then with development tools.

In part 4 of this series I will discuss metrics. Stay tuned.

I had written a few articles about Web 2.0 and how the younger generations have a tremendous influence on the technologies we use to communicate on the web (here and here). One of my main points was about ease of use. As IT professionals we should take lessons from the web and apply them to work. As I was drafting part two of my five part article "Are you running IT like it's your business?", my 8 year old daughter wandered in my office and asked me what I was doing. I told her I was writing a Blog and she asked me if she could write one. I created her an ID on Blogger and sent her on her way. A few minutes later she comes into my office and says, "Check out my Blog, Daddy". I typed in her blog, which was innocently named, "theseareaboutmycat.blogspot.com" and I stared at my monitor with my mouth wide open. With no instructions and no help from me she had a cute little blog about cats and dogs.

So why can't we build applications this easy for our users? Do we try to anticipate our users' every need and over design our applications? Are we making things too complex? Hmm, I see a few more articles on this topic brewing in the near future.

In the mean time, I have showed her how to add video and Site Meter to her site. I can't wait to see what she creates next!

In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

In part 2 I will focus on Lack of Resources.

What are some of the most common phrases you hear when attempting to promote change within your organization? The top one I hear is "I don't have time", followed by "I don't have money", followed by "I need more resources". These are the biggest cop outs in the world. The reason why nobody has time, money, or resources is because they don't put any initiatives in place that allow them to do anything other then put fires out.

At some point you should reach a threshold of pain and realize that there must be a better way. Everybody is working 50-60 hours, all the projects are late, production support continues to increase, and the users are screaming. Everybody is working hard, but nobody is working smart.

If this sounds like your shop, you might want to take a step back and put a plan together to stop the madness. If you owned your own trucking business and you spent most of your time repairing your fleet of trucks you would probably be out of business. So why do so many IT shops spend countless hours every day in repair mode? It's time to make time, time to spend your shareholders' dollars effectively, and time to maximize your precious resources.

Let's start with time. Where are you spending your time? Do you have any metrics that allows you to proactively manage and control your projects or your production support? In many shops, the main cause of all these issues is lack of a sound project prioritization process coupled with a lack of a resource allocation model. If projects get accepted at will, priorities change like the seasons, and you have no data to show that your resources are over allocated, you will become a reactive culture. If you are not practicing Portfolio Management, you should make that a priority (view this article I wrote on Portfolio Management). If you have no visibility into how much time you are spending in production support, what categories of issues you are encountering, and how long it takes to fix issues then you should make change management a priority. If you are meeting with the business to discuss the next wave of new projects and do not have a clear picture of your resource capacity, you need to start practicing human resource planning.

Next is money. Obviously, if you are spending too much time keeping the lights on then you are wasting money. But are you wasting money on infrastructure? Are you still pouring millions of dollars into big name vendors like Microsoft, IBM, Oracle, and HP? Are you paying huge amounts of money for "Gold Support"? You need to start evaluating Open Source alternatives. If you believe in the myths of Open Source, it's time you start doing your homework and read about these 50 Open Source success stories. Oh, and that Gold Support you are paying for each and every product...there are many Open Source Support Providers who can support a variety of open source products at a fraction of the cost. What is better is that these folks earn their stripes supporting customers and are actually extremely interested in helping you resolve your issues. This is their core competency. I wonder how much effort Big Blue would put forth to help a small $100M company resolve its problems. The days of saying, "Nobody every lost their job buying Microsoft and IBM" are long gone. If that is all you are buying you are definitely not seeing the big picture and your CEO might start giving you that look.

Are you still buying rack after rack of servers to support your test, development, staging, and production environments? Have you embraced Virtualization Software like VMWare yet?

And what about human capital? We already talked about spending too much time keeping the lights on and spending too much time maintaining rack after rack of servers. But what about development and testing? Do you have an architecture that allows rapid deployment and reusability? Have you separated your business rules from your applications? If your business rules are embedded in your applications then you are creating additional work to maintain and test your applications thus increasing your chances of creating defects.

Let's say you are a retailer with 1000 stores and you have a business rule for defining what a high volume store is. You have several different systems that use this business rule (billing, inventory, eCommerce site, financials, etc.). Now you want to change the definition of a high volume store. You now have to make that change in each of these systems and implement all of the systems at the same time. This simple change has turned into a project. Wouldn't it be better to go to one place, make the change, test it in one place, and roll? You don't need to practice agile methodologies to be agile. You just need to be smart! My recommendation is invest in your architecture. Create a business rule layer that sits between your applications and your presentation layer. I would go one step further and create a service layer to orchestrate your business rules and allow other applications and/or customers to access your business rules.

Well, I have rambled a lot longer then I usually do so I will pause until part 3 which focuses on Lack of Tools. I will add a conclusion after part 5 that tells you how to prioritize these initiatives and how to get started.

There are several good articles about running IT like a business (here and here). I would like to ask the question, "Are you running IT like it's your business?" What are some of the barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?

• Resistance to change
• Lack of resources (time, money, and human capital)
  
• Lack of tools
• Lack of metrics
• Lack of process

If you owned your own business would you let those obstacles get in the way of making your business more profitable? I didn't think so. So why should your shareholders tolerate it? In today's world of IT, there is a lot of pressure on CIOs to cut costs, pursue outsourcing, improve delivery, and enable the business to grow. If your shop is spending most of its efforts "keeping the lights on" are you really just managing a cost center?

Let's discuss the five barriers to success that I listed above. First is resistance to change. According to Prosci, the experts on change management, the top reasons for resistance to change are:

• Lack of understanding around the vision and need for change.
• Comfort with the status quo and fear of the unknown.
• Corporate history and culture.
• Opposition to the new technologies, requirements and processes introduced by the change.
• Fear of job loss.

In order to overcome these obstacles you must manage both the human and business aspects of change. To manage the human side of change you must define WIIFM (what's in it for me) for people at all levels. That equates to having distinct communication plans for Sr. management, mid level management, and non management personnel. You also must constantly reinforce and adjust your communication plan throughout the duration of your change initiative. It only takes one respected person to doubt the initiative and the whole house of cards can come tumbling down.

So define a clear vision, get executive level buy-in, communicate early and often, manage resistance, and measure your progress. I also recommend that you find a partner to help you foster change. Why learn everything the hard way? Accelerate the learning curve and secure a change management partner to guide you to a successful implementation of change.

In part 2, I will discuss the next barrier to success, Lack of Resources.

Stay tuned.