Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.

I wrote Vista first impressions a few weeks ago and shared my less then happy initial experiences with Vista on the new laptop I bought for my wife. It has been two weeks now and my wife, a typical non-technical user, refuses to use the new laptop. She no longer thinks her four year old laptop running XP is slow because it is twice as fast as her brand spanking new laptop with the resource gobbling Vista on it. So my kids share this laptop and I constantly hear screams of "it's shutting down again!", "why is this so slow?", and "can we trade it in?". This is not what I had in mind when I dropped a grand on the new Dell.

So I keep searching the web to see if anyone is happy with Vista. I go to Microsoft friendly websites like eWeek and PCMag.com and find articles like these:

Night of the Living Vista

The Vista Irrelevancy

Ok, so it's not just me, a pro-Linux guy who is feeling the pain. Popular blogger and pro-Microsoft fan Chris Perillo is not a big fan of Vista either. The more I search the more complaining I encounter. I realize that some of this is people's resistance to change. But I don't recall an all out revolt like this when XP came out. When XP came out, it was a significant improvement over the blue screen, crashing Win95 & Win98 operating systems. Those two versions were absolutely pitiful from a reliability and performance standpoint.

So what the heck was Ballmer and the boys thinking when they spent years developing this bloated resource consuming beast they call Vista? Were they seriously targeting business? Any IT shop that would buy all new computers to upgrade to Vista definitely does not understand the economics of business. Where is the ROI? What do the users get for the investment? Are they ready for the increase in support calls? I've said it before and I'll say it again, the majority of business users spend most of their time using email, browsers, or a third party application (CRM, ERP, etc.). Most users don't need a ton of hardware to perform their daily tasks. Doesn't Microsoft understand this?

For me, I have two options. First is to call Dell and beg for an XP license so I can get off of Vista or second, move to Linux. With the new laptop, we now have five machines in the house. I am moving three to Ubuntu and keeping two on XP. My wife doesn't play any games so she will be fine on Ubuntu. She has been using Firefox, Open Office, and Thunderbird on XP for years so the switch to Linux will be simple for her. My kids play a few Microsoft games like Zoo Tycoon so they will need XP. For me, the only thing I need XP for is Battlefield 2. I have been using Ubuntu at work for six months now and don't miss the constant rebooting, messed up registries, and blue screens.

Yesterday I was on the new laptop and I dragged the Open Office install and setup icon on the desktop to the recycle bin and I got a status bar that went on for over a minute. I finally canceled it, highlighted the icon, and hit the delete key and it deleted it. Little annoyances like this are becoming so common in Vista that I start to question Microsoft's ability to test. We are talking about a new laptop with next to no new software installed on it and minimal usage thus far. What the heck is the user experience going to be like after my kids mess with the laptop for the next few months? All I now is that if my team at work wrote software this bad we would be out of a job.

I'll leave you with this funny Vista installation video on YouTube.

One of the most critical tasks that the champion of your SOA initiative must perform is to quantify the total cost of ownership (TCO) of the SOA initiative. Some executives might think that once they buy the ESB they are done. This is far from the truth. Here is a list of items you should plan for up front and create a road map for how much and when each of these items need to be procured:

  • The Stack (BPMS, ESB, Data Services, Portal, etc.)
  • Testing tools
  • Training, training, and more training
  • Professional services from the Stack vendor(s)
  • Professional services from the implementation partners
  • Conferences, site visits, partner meetings, and other learning opportunities
  • Acquiring personnel with new skill sets
  • Organizational changes
  • Annual maintenance costs
  • Network infrastructure (if necessary)
  • Additional security hw/sw (if necessary)
  • Funding a project and tools to implement SOA Governance
I am sure I missed several others. The key here is that to successfully implement SOA, your company must make a long term financial commitment to architecture that never ends. Investing in SOA goes far beyond buying the Stack.

The Stack
Depending on your project's objectives, you may need to purchase a variety of products that make up the Stack. In my case, we already had an enterprise portal. We purchased an ESB, a BPMS solution, and a data services tool. With each tool you need hardware, racks, floorspace, etc.

Testing Tools
Unless you already have a robust testing tool for testing enterprise architectures including web services or JMS messages, you probably need additional tools. We have many modules in the Mercury suite, but nothing for performing testing in a service oriented architecture.

Do not underestimate this one. Not only do you need to train administrators for every piece of the stack and for every additional tool you purchase, you need to train a large number of IT staffers about SOA, Governance, and developing and deploying with the new products. There are five different courses offered just for the BPMS tool we bought. One is for administration, two are for programming, and two are for modeling. Training is also a continuous process and not an event that occurs by sending a few people off site for three days.

Professional Services (Stack vendor)
Take my advice on this one. Use the vendor's professional services to install the products. Do not, I repeat, do not try this on your own or with consultants. The beauty of SOA is how it easily integrates across different technologies. My lessons learned is that this is true once you suffer through the upfront configuration nightmares required to create the initial environments. If anyone other then the vendor sets up the environment, you may not get the support you need from the vendor to fix it. Use the vendor to implement the products and have them come back when you have built something and have them certify the environment with your code running on it. Tweak the system now before you go live!

Professional Services (Partners)
Unless you are fortunate enough to have the necessary skill sets within your current staff, I highly recommend finding a partner with years of experience implementing SOA. Choose your partner wisely and embed your staff with them for knowledge transfer.

Learning opportunities
Don't underestimate continuous learning opportunities. I still attend conferences, webinars, lunch and learns, and various other opportunities to talk to people and learn from their experiences. Get out of the office and see what the rest of the world is doing. Learn from their mistakes and their success stories. Don't forget to budget for travel.

New skill sets
Our SOA/BPM initiative introduced a number of new skill sets. You may need to hire incremental headcount or replace existing roles with new roles. SOA talent is in high demand and is not cheap. Don't forget recruiting costs, relocation expenses, and the overhead of onboarding.

Organizational changes
You may find that your current organizational structure is not optimal in the new world of SOA. Reorganizations sometimes have costs associated with relocations, promotions, merit raises, administrative costs, new reward and incentive programs, etc.

Annual Maintenance
Expect to pay between 18-21% in maintenance costs for everything you buy.

Network infrastructure
Your current network infrastructure may not support the requirements of your SOA initiative. More sophisticated load balancers, additional monitoring tools and agents, and hardware accelerators are just a few things you may need to consider.

If you are exposing business services externally to customers and partners, your security requirements are more critical then ever before. There may be additional purchases required for authentication, auditing, logging, encryption, ID management, etc.

SOA Governance
This might be the most underestimated piece of the entire SOA financial model. Implementing SOA Governance is a project within itself. It requires dedicated staff, training, and tools for enforcement. Don't cut expenses here. Invest in governance because the success of your SOA implementation for years to come is heavily dependent on your ability to enforce policies and best practices. Buy a repository. Don't try to manage this manually or you will drown.

To sum it up, SOA is not a tool you buy. SOA is a new way to develop software and touches every aspect of your enterprise. Invest in SOA or the money you spent on your stack will never reap the benefits that SOA can offer.

Last fall, my company embarked on a business processing reengineering effort that focused on the the sales creation to product delivery life cycle. In just over two months we documented the current state of our business processes, identified the desired future state, performed a gap analysis, identified a roadmap to get us to the desired future state, and built a portfolio of key projects backed by key financial data including ROI analysis and NPV. This portfolio of projects is where we are focusing our BPM and SOA efforts today.

One thing I have been pondering as we get ready to launch our second business process reengineering exercise for another business unit is.....

Is it better to start with the current state and then analyze future state


should we focus first on the future state and then analyze the current state processes that are barriers to achieving future state?
There are two reasons why I feel that doing future state first might be better.
  1. Focus more on where you want to go and less on where you have been
  2. Allows you to start your analysis with the overall business objectives and drill down instead of focusing on deficiencies and working up.
It feels like going from current state to future state constrains you when you start defining the future state. When we had business users in the room brainstorming about the future, they would start with the current business environment and start trying to improve upon it. Wouldn't it be better to start with a blank slate and define what the future state should be like without any restrictions? Once that work is complete, we could perform the current state analysis and then figure out how to get from current to future. Granted, some of the future state ideas may not be feasible but why not get all of the innovative ideas out on the table before they are written off?

This is the same approach we are taking from the architecture viewpoint. We are starting with a clean slate. We are establishing a methodology, standards, and best practices purely targeted at a services oriented architecture. Our current methodology is not really built for agile development so why should I try to make it fit for SOA? Our current design standards hardly apply to enterprise wide development. Most of the development we have done before SOA was very application specific. Again, why put a square in a round hole?

I am really just thinking out loud here and not really recommending one versus the other. I have experience starting with current state and moving to future state. We have been successful but it feels like it is a much slower path to the promised land. I would love to hear from those of you who have been through an exercise like this and what your opinions are.

I attended the Event Processing Summit in Orlando last week and probably the most interesting presentation was given by Dr. Mani Chandi from the California Institute of Technology. Mani did a great job of explaining the important role that event processing plays today but it was his vision of the future that really caught my interest.

Mani described what he said would be the next big thing in IT that the analysts would be talking about in 2017. He took us through history and explained how innovation focuses on the most scarce resources. In the 60's the most scarce resource was the mainframe, namely the computation power. From that, innovation led us to the distributed model of client server computing. The next wave of innovation dealt with the scarce resource of communication and bandwidth which led to the great internet revolution and high speed access. The current wave of innovation is in the area of integration and information, both internal and external. There is such a high demand for systems to talk to one another that SOA has become mainstream.

So what is the next scarce resource? According to Mani, it is time and attention. Now that we have solved the issues with computing power, communication and bandwidth, and application integration, the next hurdle to overcome is dealing with the enormous amount of information we have at our fingertips. The next wave of innovation may be focused on some combination of Web 2.0 technologies, complex event processing, and business intelligence. Here are Mani's predictions:

  • Systems will predict your needs without explicit work on your part
  • "CEO need in 2017 is what kids use today"
  • We will move from a reactive web to a proactive web
Mani marveled over how incredible kids' sensors are today and how they easily consume the continuous flow of information they subscribe to. He sees a move towards user contexted BAM (Business Activity Monitoring). Mani left us with some good advice:
Focus your development effort on the scarcest resource.

Both Adobe and Microsoft are fighting hard to be the preferred vendor for RIA development. They both are awesome tools that will change the way we use the web in years to come. But when it comes to deployment, there is only one option for me and that is Flex. The main reason, 99% of all PCs and laptops have Flash installed on it.
If you look at this chart you don't even see the Silverlight plugin. That is because it is so new that it will take a while to penetrate the market. But even Microsoft's most popular desktop add-on, Microsoft Windows Media Player, only reaches 83.6% of the desktops.

Silverlight will struggle to get widely adopted just like Winforms did. The problem with Winforms is it requires the .Net framework to be installed on the client PC. According to Microsoft's own website, the .Net framework is at about a 58% penetration rate. Keep in mind that the framework only comes into play on Windows operating systems. I don't know about you, but I won't have any success convincing all of my 500 manufacturer and retailer clients to install the framework on all of their desktops. But my Flash applications will work fine since they all already have Flash installed, regardless of which operating system they run.

Microsoft did learn from the failed approach with Winforms and addresses this issue with the Silverlight plugin. The problem now for Microsoft is how will they get the necessary penetration that customers like me require. Microsoft is also working with the open source community so Silverlight will work on Linux (see Moonlight). This is a great strategy. But I can't wait 2-3 years until Silverlight penetrates over 90% of the laptops and PCs across all operating systems.

Don't get me wrong, I like what I have seen (download plugin at own risk) from Silverlight as far as ease of use and functionality. If you are building applications for users that you have total control of their desktop, then Silverlight is an awesome choice for you. But for those of us who have no control over the client, Adobe Flex beats Silverlight every time.

I attended the Event Processing Summit in Orlando today and will summarize my understanding of event-driven architecture (EDA) and how it is different from service-oriented architecture (SOA).

EDA is not a new concept. Like BPM and SOA, EDA has evolved to the point where it is mainstream enough for vendors to make a profit from it. Vendors have been aggressively working on being the first to market with an easy to use and open platform for customers to add to their stack.

So how is EDA different from SOA? SOA is a request/respond type architecture. The users request information from the system and the system produces a response. EDA is a sense/respond type architecture where the user is alerted or notified of some condition(s) that the system predicted or discovered. Think of EDA as a tool to teach the computer how to respond to events.

To get a better understanding of these terms, let's look at the following pictures. The first picture depicts the classic stovepipe or silo type architecture where applications do not integrate well with each other.
In this example, a customer calls a customer service representative (CSR) and requests information that spans multiple systems. The CSR goes into each system and manually collects the various data points. Once finished, the CSR responds back to the customer. This type of architecture is inefficient, error prone, and time consuming.

Enter SOA. SOA allows you to build composite applications while leveraging years of investments in your legacy applications.
In this example, the CSR was completely eliminated and the customer was given a self service portal that has a single view into the various legacy systems. To keep the chart simple, I did not display the service bus or BPM workflow. The idea here is the customer has a single view into all of the data that is relevant without dealing with the complexity of interfacing with various different backend systems. This is SOA's sweet spot. You can see from the picture that the composite application is made up of data from various legacy systems both internal and external (Salesforce. com) and across different platforms. SOA, like the old silo architectures, is also request/respond. Wouldn't it be nice if we could anticipate our customers' needs and notify them in advance of events that took place or conditions that require their attention?

Enter EDA. EDA creates a composite view of data from your legacy systems and analyzes the data to identify patterns or trends.
In this example, the EDA system is constantly evaluating data that is being pulled into a composite view in real time. Once certain events are identified based on some set of rules, the EDA system alerts or notifies the customer. This is extremely efficient, timely, and very cost effective. This is proactive computing.

EDA can be implemented stand alone without SOA, but it is very complimentary to SOA. EDA can leverage your existing SOA assets (BPM, ESB, Repository, Governance model, BAM, etc.).

I like to think of EDA as Proactive SOA. It is a natural extension of SOA. If you are implementing SOA today, keep an eye on EDA. Once you reach a decent level of SOA maturity, EDA will take your SOA to the next level.

I'll be back tomorrow to summarize more great insights from the Events Processing summit.

I just finished reading a great book called Kiss Theory Good Bye by Bob Prosen which preaches focusing on the basics for driving company results. Bob has turned around numerous organizations throughout his career by following the KISS (Keep It Simple Stupid) principles. In his book he gives 5 habits that cripple a company (Prosen, 2007, p.6):

  1. Absence of clear directives
  2. Lack of accountability
  3. Rationalizing inferior performance
  4. Planning in lieu of action
  5. Aversion to risk and change
These same principles should hold true for your SOA initiative as well. Let me explain.

Absence of clear directives - You should clearly define what your objectives are, what your roadmap is, and how you plan to get there. Just saying "we are implementing SOA" is not enough. SOA is an evolution, not a project. Implementing SOA is a journey made up of many individual projects. Set realistic goals.

Lack of accountability - The death of many big initiatives is a lack of strong executive sponsorship. Identify a sponsor (CIO, CFO, CTO, business partner, VP of IT, etc.) and help that person hold the organization accountable for delivering SOA. Everyone's goals and objectives should reflect contributions to the various SOA related projects. Create the appropriate incentives and attract the change agents.

Rationalize inferior performance - Don't tolerate mediocrity. You should have your "A" players working on these projects. If the work isn't getting done don't make excuses like "we don't have the skill set" or "lots of companies struggle". Identify the issues and resolve them immediately. Remember, part of your sales pitch to management was agility. Don't let problems fester for long.

Planning in Lieu of action - Don't jump into development. Think things through. Governance is a critical success factor for delivering and maintaining SOA. Implementing governance is a project in itself. Don't under estimate training. You may even need to change your organizational structure. Invest the time in change management throughout the project.

Aversion to risk and change - Don't stick to the old ways of delivering software. SOA works best when using an agile approach to development. Take a holistic view of the enterprise. You are no longer delivering silo applications. Now you need to think about the entire organization, your customers, and your partners. Testing is a whole new ball game. Don't even dream about applying the normal testing methods to SOA testing.

If you are a member of senior management within IT or any part of the business, I highly recommend the book. The KISS principles apply to all aspects of business. Focus on what's really important, don't bite off more then you can chew, align your initiative with the business's needs, and have fun doing it!


Prosen, B. (2007). Kiss theory good bye five proven ways to get extraordinary results in any company. Austin, TX: Distributed by Greenleaf Book Group.

Eric Roch, CTO and Chief Architect of Perficient did a nice job of summarizing when to use Web Services and when to use JMS. Here is a link to his article at the ITToolbox.

read more | digg story

In response to some feedback from my favorite critic James McGovern, I will discuss the impacts of leadership on corporate behavior. But first I want to clarify for James the intent of the article that he critiqued called Blogs- the innovation escape hatch. In this article I discussed how social networking allows people to speak more freely and be more innovative then they can be in a corporate environment. I was not discussing social networking in terms of a corporate technology or tool. I was just reflecting on how great it is to see people like James express their views without having to be politically correct all of the time. Oh, and one last thing. James, I don't work for CIO.com. They asked me to participate in their blogging community (for free). So anything I write is my opinion and does not reflect the opinions or beliefs of CIO.com. Enough of that.

Leadership drives corporate behavior. Many people confuse management with leadership. I have seen many people in leadership positions over the years perform entirely tactical duties and not put forth and execute anything strategic. Managers are tactical and are responsible for getting work done. Leaders are transformational and focus on people and culture. There are two basic approaches to leadership that produce two entirely different outcomes, production-oriented leadership and employee-oriented leadership. The production-oriented leader is one who focuses mainly on the technical or task aspects of the job. This type of leadership focuses almost entirely on the bottom line. Organizations with this type of leadership tend to have the following characteristics:

  • Sweatshop mentality
  • Strong reliance on outsourcing
  • Frequent layoffs
  • Low morale throughout the workforce
Production-oriented leadership can be very successful in terms of financial numbers, but it is usually at the expense of people. In cultures like this, introducing intangible technologies like social networking is a challenge. Without a cut and dry ROI, most initiatives don't stand a chance. Social networking is a transformational technology that can create huge increases in productivity, improved communication, employee morale, and innovation. But production-oriented leaders will be challenged to see the benefits and embrace the change.

Employee-oriented leadership emphasizes interpersonal relations and focuses on employee needs. When these leaders say that "our most important assets are our people", they actually mean it. They understand that higher morale leads to higher productivity which results in improved financial results. Organizations with this type of leadership tend to have the following characteristics:
  • Thrive in innovation and creativity
  • High productivity
  • High morale
  • Low turnover
Technologies like social networking can thrive in cultures with employee-oriented leadership. Social networking's strength is the power of groups. When people can collaborate freely on an idea, the idea gets continually refined and improved with the collective intelligence of many. If a corporate culture encourages this type of behavior, the sky is the limit on the gains in productivity and innovation. Social networking doesn't just happen within the corporate walls. Corporations can create powerful social networks that branch out to their customers and partners as well. Would we still need to do those painful annual customer and employee surveys if we had a social network in place? Social networking gives you real time unfiltered feedback that you don't need to hunt for. This is information at your fingertips that you can act on immediately.

Here is a great video from YouTube for those unfamiliar with social networking.

I ordered my wife a new laptop from Dell for her birthday. Unfortunately, Dell did not offer Ubuntu for the Inspiron 1720 model. So Vista it is. Having to use Vista, being the Linux advocate that I am, is the equivalent of a die hard Yankee fan having to wear a Red Sox shirt to the ball park. I tried to go into it with an open mind and document my first impressions. My initial impression is that Vista is slow, buggy, and not as intuitive as XP. The intuitive part might be attributed to my familiarity with XP but it sure seems like it takes a lot more clicks to get to where you want to go.

So let's start with slow. This brand new laptop, with double the memory and cpu power of my wife's previous laptop running XP, takes at least 3 times as long to load. My wife's old laptop has been through the abuse of my kids downloading various rogue software applications loaded with spyware. I am constantly cleaning up the registry and removing stuff from the old laptop. The new powerful laptop is clean and still takes forever to boot up. When I have more time I will probably shut down a ton of unnecessary services that Microsoft defaults to automatic startup. Even connectivity is slow. I put my wife's old laptop and new laptop side by side. Both are connected via wireless to my Linksys network. I simultaneously request the same web sites and consistently get longer response times on the new laptop. It looks like it has some additional overhead that it performs for all requests.

On to buggy. When first connecting to both my wireless network and my shared printer from my main server, Vista displayed a progress bar that went off into no man's land. In both instances I canceled and retried and it worked instantly. Weird. Here's the classic one. So I am on the bed with laptop plugged into the outlet. My wife walks by and accidentally unplugs the laptop when she stumbles over the wire. She plugs it back in and I get a message that says something to the effect that Vista does not recognize my power cord and will now run in degraded performance mode. Huh? So we unplug and plug it in again and all is good. It's the old "jiggle the handle" mentality. That was one of the most bizarre errors I have seen in a long time.

Finally, not as intuitive. I remember when XP came out. I totally hated the previous version of Windows. When I first got my hands on XP I was skeptical. I was presently surprised to find that it was much easier to use and crashed a lot less. It still did not live up to my standards but it was a drastic improvement over its predecessor. I don't think this is the case for Vista. It took me a long time to figure out how to find stuff. It seems to lack a lot of the flexibility of normal operating systems and forces you down certain paths. It rebooted itself twice for reasons unknown to me when I was trying to get it set up. I realize that some of this might be because I am a Vista newbie. I can tell you that the first time I ever used Linux and XP, I was able to get setup in a lot less time.

I will add that I have not spent more then an hour or two using Vista and don't have enough information at this time to make any final assessments. From the brief time I did use Vista I was slightly disappointed. My Ubuntu CD waits patiently! On the bright side, it's still better then wearing a Red Sox shirt!

I wrote an article several months ago named Built to last is a thing of the past. Yesterday, at BEA World in San Francisco, a speaker mentioned the phrase...

Built to change, architected to last
I think that this is a great motto and one that teams starting SOA implementations should use as a their vision. Built to change, architected to last is all about agility and flexibility. BEA is touting their own new acronym called Dynamic Business Applications. This new term refers to an architectural mindset based on four principles:
  1. Built to change (flexible)
  2. Embody business processes
  3. adaptive
  4. agile
This mindset is BEA's response to today's business environment where the business is changing faster then IT can keep up with. The solution is to provide a platform of business processes and services which allow users to design and/or assemble their own composite applications (mashups). The days of buying enterprise third party applications and forcing the users to use the canned processes and features are over. The business changes so fast that third party packages become a crutch over time due to their long release cycles. Simply put, the packages can't keep up with business needs. The answer is take the best of breed features and services from the combination of third party packages, SaaS solutions, and custom code and present a common interface that integrates all of the functionality together into a single view of the users' workflow.

Dynamic Business Applications is a shift to a world where applications are human made and designed for the way people work. The IT team delivers business processes, business services, core infrastructure, and integration services. The business can then create their own composite application by assembling all of the pieces together. Think of it as the Lego approach. The IT team builds the rectangles, squares, wheels, and various connectors in all different shapes, sizes, and colors. If the users want to make a boat, the choose all the pieces necessary to make the boat. If they want to make a plane, they choose the pieces necessary to make a plane. The users did not have to wait for IT to build them a boat or plane.

To accomplish this, IT must work closely with the business to identify the core business processes and services. This is where it is extremely helpful to establish a SOA roadmap. Once you have identified the collection of business processes and services in some key area of the business, you can then prioritize your deliverables by delivering the processes and services with the highest chance of reuse first. This greatly improves your speed to market in the long run.

Another shift in thinking that should be mandated in organizations is to move away from creating reports and move to creating information. My philosophy on this topic goes like this....
You should only develop reports if it is an output of the system (ie. bill, invoice, purchase order, etc.). Otherwise, IT should leverage business intelligence and deliver data as content to the users with a tool that allows them to format the output and drill down into the data as needed.
Why do we continue to pay developers to write custom reports only to get frequent change requests to change or add new columns, create multiple output formats to please different individuals' preferences, and make changes to group or sort things differently? Not only is this expensive and an inefficient use of people's time, but the users typically have to wait for IT to make these changes. Although these changes may be quick to make, it may be a long time before the change is high enough on the priority list to get worked on. Wouldn't it be better to present data to the users and give them self service capabilities to define their own reports, create their own dashboards, and do their own what-if analysis?

IT needs to become an enabler instead of a bottleneck. We should stop building custom applications and start building the building blocks that can be assembled into Dynamic Business Applications.

  1. Reduce dependency on closed source vendors. Stop being dragged through constant product upgrades that you are forced to do to stay on a supported version of the product. Aren't you tired of telling your customers to wait because you have to spend a month or two upgrading to version 7.01G of Product X and following it up with an incremental hot fix?
  2. Your annual budget does not keep up with increases in software maintenance costs and increased costs of employee health care. Your budget remains flat, you bought five new tools last year with new annual costs in the range of 18-20% of the original purchase price for "gold support", and your employees' health care costs shot up 25% again. What gives?
  3. More access to tools. You can get your hands a variety of development and testing tools, project and portfolio management tools, network monitoring, security, content management, etc. without having to ask the boss man for a few hundred thousand green backs.
  4. Try before you buy. Are you getting ready to invest in SOA, BPM, or ECM? Why not do a prototype with out spending huge sums of money? First of all, it allows you to get familiar with the tools so you can be educated when you go through the vendor evaluation process. Second of all, you might find that the tool can do the job and you don't need to lock yourself in to another vendor.
  5. Great support and a 24/7 online community that responds quickly. Despite the myths that you can't get support for open source software, the leading communities provide support far superior to most closed source vendors. Most communities have a great knowledgebase or wiki for self service support. You can also post a question and one of the hundreds of community members throughout the world will most likely respond in minutes. Make sure you chose software with strong community backing.
  6. Access to source code and the ability to customize if you desire. You can see the code, change the code, and even submit your enhancements and/or fixes back to the community to be peer reviewed and possibly added to the next build. No longer do you need to wait for a vendor roadmap that doesn't have the feature you need until their Excalibur release in the Fall of 2009.
  7. Great negotiating power when dealing with closed source vendors. Tired of vendors pushing you around because you don't have options? I wonder if companies like Microsoft would be more willing to be flexible with their pricing if you have 20 desktops running Ubuntu as an alternative desktop pilot initiative.
  8. Feature set is not bloated and is driven by collaboration amongst the community. Tired of products that consume huge amounts of memory and CPU power for the 2000 eye candy features that you will never use? With open source software, most features are driven by community demand. Closed vendors have to create one more feature then their competitors to get the edge in the marketplace.
  9. More secure then most closed source vendors. This topic is highly debated, but studies like this one from Trend Micro show that open source software is typically more secure.
  10. Bug fixes are implemented faster then closed source vendors. Actually, many bugs are fixed by the community before they are even reported by the users.

Oh, and #11.....it's Free!

I was having a coffee with a friend and mentor of mine the other day. Tom is a PhD in Psychology and specializes in leadership and organizational change. I was explaining to him why he should look into blogging as a way to express his opinions and views on his thirty plus years of working with corporate executives.

Tom started talking about a topic that he has been researching. He talks about how people enter the corporate workforce at an early age full of hope, promise, and energy. Over time they become conditioned in a system that stifles creativity and innovation and focuses more on rules, guidelines, and "staying the course". He talked about writers, artists, and musicians and how they are able to express themselves and how they innovate. Unfortunately, those professions are a tough way to make a good living and only a small percentage of people actually prosper in that space.

Tom talks to many people in corporate America every day. He explains to me that some of the people he talks two seem to have two different personalities. One being their true inner self, capable of displaying emotional intelligence, cognitive reasoning, and are innovative and generally curious. But then they transform into their corporate personality where they assimilate, follow orders, and don't rock the boat.

Being addicted to blogging like I am, I started thinking about how this applies to the blogging community. The more I thought about it, the more I realized that blogs are a great outlet for expressing our inner self and escaping the handcuffs that are placed on us in our daily corporate lives. We can express our true opinions and be heard. It's Ok to "rock the boat" and provide radical alternative solutions. One of the blogs I read daily is James McGovern's From Incite comes Insight. James has very strong opinions both technically and politically. He has created a platform for himself where he can express his opinions with no constraints and without being bound by the walls of a corporation. He can do this because he keeps his company's identity hidden and does not represent the views of his employer. I am pretty sure James speaks in an entirely different tone at work.

Without an outlet like a blog or any other social networking platform, we would not be able to witness the true expression and innovation of technologists like James and others. For me, to discuss many of the things at work that I write about, I would have to devote a substantial amount of additional time crafting "politically acceptable" messages to cater to an audience that has certain expectations and guidelines. Although, I am not known to be a politically correct speaking individual at work and do tend to speak my mind, I still tone it down way more then I do in my blogs. With social networks, you simply express yourself and those that like it will embrace it and those that don't will either ignore it or give you opposing views. In corporate settings, especially in IT, there are many people who just won't express themselves at all. Many of them have a lot to offer but shy away from public exposure. Social networking gives these people a platform to express themselves without having to expose their identify.

I asked my buddy Tom to put his thoughts down on paper. I am educating him about the power of social networks. He is a baby boomer who is not current on technology and I am trying to show him this powerful world where he can enlighten us with his views and allow his readers to build upon his ideas in a collaborative fashion. I have been stuck on his thoughts about how people act contained and constrained in corporate settings. I think this is one of the reasons why social networking is becoming much more attractive in the last few years. What are your thoughts?

The more I read about SOA the more I realize that people don't really understand what it is. It is almost as if it is a magic pill that can fix all of your technology problems while solving world hunger. I get concerned when I see articles like this one (Does SOA threaten developer jobs). If anyone thinks that SOA is a way to downsize an organization and free up resources, then give me some of whatever that person is smoking!

First of all, if you are signing up for a SOA initiative, you are probably adding resources or at least moving resources off of other initiatives. No way are you eliminating resources. You can't simply stop doing the other hundred projects that your business partners are depending on you for.

Second, you don't "do" SOA in one project and then you are done. To do SOA right, your company needs to make a long term commitment to it. You must fund it, invest in people and training, change your culture, possibly change your organizational structure, align more with your business partners, radically change your approach to testing, and put a governance model in place. If you don't do all of these things then don't even bother with SOA. This is no different then when everyone was jumping on the OO (object-oriented) bandwagon a couple of decades ago. Many companies let their developers run wild and create all kinds of wonderful object oriented applications. But since many of them failed to set any standards and guidelines, they failed to achieve reuse and wound up creating very expensive, time consuming applications without any real benefit. SOA, like OO, is pure overhead if not done right!

Third, SOA is not something you buy from a vendor shrink wrapped in a box. I have heard so many stories of companies rushing out and buying an ESB without having a clue of what to do with it. I have this image of a room full of guys making six figures sitting in a conference room high fiving each other after they just dropped their first million on their ESB. After knocking down a few glasses of champagne one of them turns to the others and says, "Now what do we do?" The room fails silent and the real heavy drinking starts!

When the latest buzzword gets all the hype, the smart people start to get pessimistic about it (Why SOA Does Not Deliver). SOA can deliver, but only if you know what SOA is and if you set realistic goals for what you want to accomplish with SOA. Max Pucher is right when he says...

An agile organization will use IT to its best with or without SOA. SOA will not make a business or its people more agile.
It's like the housing boom. When the cleaning lady starts talking about the condo she just bought, it's time to sell!

If you are considering implementing SOA, make sure you really understand what SOA is and what your goals and objectives are. Before you buy anything, make sure you know what the total cost of ownership (TCO) is. SOA is not a product. It's a way of life.

I have been real busy lately between our SOA/BPM initiative, my MBA courses at night, and trying to maintain a couple of blogs. It's time for a road trip to see what the rest of the world is up to.

I was fortunate to get my hands on a few free passes to two conferences over the next two weeks. I'll be at BEA World in San Francisco next week (9/10-9/12) and in Orlando at the Gartner Event Processing Summit the following week (9/17-9/19). If any of you are at these conferences and would like to talk technology, drop me an email.

I'll post an article or two summarizing what I hear at these conferences.

A few months ago, I wrote an article called Open Source and Microsoft Free which discussed my switch from Microsoft XP to Ubuntu at work. In that article I discussed how after seven weeks, I was able to do my job with next to no issues. At the end of the article I recommended a small Linux pilot:

The worst thing that can happen with a small pilot is that you discover that Linux won't work for your organization. At least then you can sleep at night knowing you did your homework and made a strategic decision based on real information.
I have now been Microsoft free at work for almost five months. We had our Linux pilot kickoff meeting yesterday and are preparing to pilot Linux, Open Office, Evolution email client (not replacing Exchange), and Firefox as the standard Open Source image. We have not yet selected which distribution of Linux we want to pilot (we have some more research to do here). For applications that require a Microsoft operating system we have two options. First, we will use Wine to install applications like Visio and IE for those drawings or activeX enabled web sites that don't have Open Source solutions at this time. The second option is to leverage one of our Citrix servers to host applications that will not work well without Microsoft products. We can simply consolidate all of these applications on a single Citrix server and install the Citrix client on each Linux user's desktop.

An important requirement of this pilot is to make sure we address all of the desktop standards that are enforced on our Windows desktops. That means we must address desktop lockdowns, patch management, data encryption and cryptography, virus scanning, and many other security and management features. Our current action item is to review all of these standards and present how we will address each one on our Linux desktops.

For this first pilot we agreed to keep it simple. We will select one Linux distribution, chose a small group of 5-6 users within IT, create a standard image for all pilot users, and create a self sufficient support plan so we don't interfere with the desktop team's day to day commitments. One thing I learned from all of the feedback I received from the last article and from talking to the management team of the desktop group is that doing this in stealth mode can be disruptive and a breach of security. Although the stealth mode initiative got us to this point, I regret not taking a more formal and open approach to a pilot. What I found is that my world is not so anti open source after all. In fact, having an Open Source strategy with an active Linux pilot gives you great leverage the next time you negotiate with Microsoft for Vista and Office 2007 licensing!

Our immediate goal is to collect information to understand the potential usability and support challenges of an enterprise Linux desktop solution. Do I think that we will ever replace Windows at work? Heck no. Do I think we have a substantial amount of users who can be fully functional without the costs of a Microsoft computing environment? Heck yes. The majority of PC and laptop users barely utilize the power of their hardware. They spend most of their time in email, a browser, and in Office. There is always the power users who have much more advanced requirements. But for the average computer user, the basic usage can easily be replaced with Open Source solutions.

I will continue to write periodic updates about our lessons learned over the next several months. I would welcome constructive feedback and would love to hear your experiences if you have been down this road before.

Subscribe to: Posts (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"