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):
- Absence of clear directives
- Lack of accountability
- Rationalizing inferior performance
- Planning in lieu of action
- Aversion to risk and change
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!
References
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
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
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 lastI 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:
- Built to change (flexible)
- Embody business processes
- adaptive
- agile
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.
- 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?
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
I just read Joe McKendrick's article IT departments don’t have time for SOA which states thatIT may actually like SOA, but they are simply too consumed with day-to-day tasks and ongoing maintenance.
The statement "we don't have time" is one of my biggest pet peeves. The reason why most IT shops don't have time to be proactive and do the right thing is because they never take the time to truly architect anything. IT shops love to dive into code with weak requirements, non value add business processes, and quick and dirty designs. With each release of software they add more maintenance heavy code into production thus creating even less time to do anything the right way.
If IT shops would take the time to architect systems that improved speed to market, decreased maintenance costs, and optimized business processes, maybe we wouldn't have to send so much of our dirty work offshore!
I found this piece of research from Duke University that discusses outsourcing, labor shortages, and graduation rates of engineers. This is a very long article so I will try to summarize it for you.
First, the researchers tackled the issue of graduation rates. They questioned the data that is reported by the popular media and policy makers which state that the....
United States graduates roughly 70,000 undergraduate engineers annually, whereas China graduates 600,000 and India 350,000....China and India collectively graduate 12 times more engineers than does the United States....
The researchers found major flaws in the above mentioned numbers. They found that the definition of engineer varies widely in China and India from the definition in the US. Comparing the graduation numbers by using source data from the different governments does not give us an apples to apples comparison. The researchers shared this example....
We were told that reports sent to the MoE from Chinese provinces did not count degrees in a consistent way. A motor mechanic or a technician could be considered an engineer.What they found is that the US is graduating nearly as many engineers as India. China does have more graduates but not as a percentage of their overall population. So the theory that there is a shortage of engineers coming out of US colleges seems to be false. Based on this finding, they tried to answer the following questions:
What skills would give U.S. graduates a greater advantage, and would offshoring continue even if they had these skills?44% of the respondents said the US engineering jobs were more technical then outsourced technical jobs versus 1% who said the outsourced jobs were more technical. Then they found that over 80% of the companies surveyed were able to fill onshore engineering jobs in four months or less which shows that there is no labor shortage.
So if we are graduating enough engineers and there is no labor shortage, what is the driver? What they found is that the driver is pure cost reduction. High salary demands and rising health care costs are causing employers to look offshore for cheaper alternatives. Other benefits are the 24x7 work days accomplished by having teams work in the US by day and offshore at night. Work ethic and long hours also contributed to outsourcing.
I have read a few articles recently claiming that US companies are seeking offshore development due to superior technical capabilities and innovation. What this report tells me is that it is still all about cost. I would love to see another report done about the total cost of ownership of outsourcing. I agree that you can get the job done cheaper offshore, but I wonder if executives understand the true costs. It is much more complicated then taking an offshore resource's hours and multiplying it by $25 to compute their cost. There are many other costs like infrastructure costs and software licenses, the cost of your own onshore resources who must manage them, review their designs and code, and the overhead dealing with communication and cultural issues.
I am not here to criticize outsourcing or to discourage people from engaging in it. I understand why companies are pursuing outsourcing and there are many success stories. I just found this research interesting because it disputes some of the myths about labor shortages, talent levels, and graduation rates. It clearly shows me what I already knew which is it's all about cheap labor.
I was on Microsoft's website trying to understand the business benefits of upgrading to Vista. I found this article called Key reasons to upgrade to Windows Vista. To sum it up, here are the four reasons from Microsoft that justify this expensive upgrade:
- Empowering users to find and use information
- Enabling mobile workers to stay connected and productive in and out of office
- Helping companies to make corporate systems and information more secure
- Making it easier to deploy and manage company PCs
- XP will eventually not be supported by Microsoft (currently targeted for 2014).
- As other businesses upgrade, your company will not be able to open Office 2007 documents unless you install the Office Compatibility Pack.
Second, enable mobile workforce. A lot of nice to have's here. Most companies already have tools that address the security and the collaboration. These features do not justify upgrading all of the hardware in your enterprise, especially when most of your hardware is not mobile.
Third, security. Wasn't this one of the selling points for going to XP. I feel like Bill Murray in Ground Hog's Day. Security is one of the main reasons why people are looking at alternative operating systems. Yes we need better security. Do I think that Vista is the answer? The jury is still out.
And finally, easier desktop management. These are commendable features. Many companies already have enterprise tools for managing their desktops and others are already moving to a desktop server approach that centrally manages desktop images and automatically updates client PCs when they connect to the network. I think the advancements in desktop management in Vista are great, but it does not justify the upgrade by itself.
So of the four reasons to upgrade to Vista giving to us by Microsoft, only security is compelling enough for me to even consider it. The shelf life of XP is the real business driver. We can argue all day long whether Vista is more secure then XP or any other OS for that matter, but other then a few reports from Microsoft's own Jeff Jones, I haven't seen any compelling facts to make me want to start an upgrade tomorrow.
I did stumble across a good article from Kelly Martin from SecurityFocus called The New Vista Waiting Game. He predicts that XP will be the corporate standard for years to come. Here is a quote from the article:
“ Despite all the coming advertising and sales pitches about early Vista installations, most businesses would be foolish to upgrade to Vista in the coming year. Businesses want stable, reliable environments. They want to see service packs that address problems even before they encounter them. They want secure environments as well, but to senior executives and other decision makers, this is still a function of Security Risk Management that can be mitigated in various different ways. ”The good news is that XP will be supported for several more years. That gives corporations time to wait for Vista to become more stable and mature. It also gives corporations time to test different distributions of Linux and have an alternative to Vista once XP gets put out to pasture.
My good friend James McGovern asks, "I wonder if Mike Kavis understands why SOA shouldn't be sold" to the business and references the article Most enterprise SOA deployments fail to deliver ROI. This article makes some good points about the total cost of ownership (TCO) which includes extensive training and expensive tools like registries and repositories. The article continues with this quote:The survey found that companies using SOA did experience an improvement in developer productivity by an average of 28 percent; however, the productivity savings do not warrant broad SOA deployment.
A little further down in the article, a very important point is made.Despite these obstacles, Nucleus Research’s survey found that SOA is assisting companies in the areas of business process improvement and portals, followed by master data management and partner integration.
I think this sentence is where many of us EA bloggers start to disagree on whether you should sell SOA to the business or if an ROI is even achievable. In a previous article I described my view on selling SOA to the business. In my case, I was not trying to implement SOA by itself. Instead, SOA was being implemented in conjunction with BPM and Master Data Management (MDM). If I was only trying to implement SOA, I would have to agree with James's stance. But since SOA is part of a larger project, which includes business process reengineering, and the funds are coming from the business, I had to sell SOA to the business.
For James's sake, no I did not Power Point them to death or talk about web services and JMS queues. Instead I explained SOA in business terms and as a major contributor to the overall ROI. In an earlier post James states that if the business trusts IT then IT shouldn't have to sell SOA to the business. Once we convinced the business that SOA was the key to maximizing their BPMS investment, they trusted us to go figure out what tools we needed. Not once did we have to sell the concept of the ESB, MDM, repositories, training, etc.
Back to the ROI. The ROI will be achieved through huge operational efficiencies that lead to increased sales, improved customer support, better quality, and improved speed to market. One could argue that the ROI is a result of the process reengineering and not SOA. I am fine with that argument although SOA does allow us to leverage our legacy systems without causing major disruptions to our business and current projects.
So hopefully we can put an end to the "Selling SOA" discussions and move on to implementing SOA. As far as SOA and the ROI goes, SOA by itself is a cost of doing business. SOA in conjunction with BPM can pay for itself if done right.
James McGovern put out a call for more EA blogs a few weeks back. I'll take that one step further and call for more EA collaboration. There are a lot of different opinions about how to approach SOA, process, and many other topics. James has some strong opinions and calls out his peers when he disagrees with them. I love constructive criticism and I sure get it from James. The problem I have is that he doesn't post my comments and allow a discussion to take place. That is not collaboration, that is being closed minded.
I have been having many healthy debates on how or if to sell SOA to the business with fellow EA bloggers Nick Malik, Jack van Hoof, and Alastair Bathgate. I think it benefits the readers to see all of the different solutions to a problem. James just flat out says that I am wrong, end of story. So here is my challenge to James McGovern. Let's collaborate and post your readers' comments so we can see everyone's point of view. Let's have more collaboration. If we want more EAs to blog, let's provide a platform for them to share ideas and give and receive constructive feedback.
I just read two really interesting articles (Giving proprietary vendors a run for their money & Could Linux become the dominant OS?). These articles and a discussion I had yesterday about budget constraints for the next calendar year makes me think that Open Source Software (OSS) is on the verge of becoming mainstream over the next few years. I have already seen the statistics where 51% of companies are using OSS in mission critical applications. This is starting to look very similar to the days where everyone was fleeing the mainframe for client server technology. The client server craze was driven by lower cost and greater flexibility. Does that sound familiar?
Back to my budget discussion. I was having a discussion with a peer about budget constraints for the upcoming year. Our budgets typically remain flat or slightly increase each year. But each year the cost of doing business rises so we really have less to work with. We have been leveraging newer technologies, like virtualization, disk consolidation and compression, and others that have been driving costs down. Over the past few years we have been dealing with our budget constraints through technology improvements in the hardware area. Now its time to look at software.
As I look at the back end servers, I can't see how we can continue to justify spending the money on licenses and maintenance for proprietary operating systems like AIX or SCO or Windows 2003 unless the applications we are serving up mandate them. For example, we obviously need a Windows server to run Exchange, but many third party packages we buy give us the option of Windows or Linux. For those worried about support for OSS, read this article about open source service providers. With the advancements in virtualization, I should be able to create as many test and development environments I need as long as I don't have to continue paying for the OS licenses. Linux gives me that flexibility. I think a good strategy this year is to look at all of your software assets to see if there are candidates to move off of proprietary solutions to open source solutions. Once you have identified the candidates, put a plan together for replacing these systems over time.
Then I started looking further down the road. I have written many articles about my concerns with Vista and how this might be the right time to start a Linux on the desktop pilot. With the potential of Linux on the desktop being introduced to the enterprise over the next few years, coupled with applications moving towards SaaS models and rich AJAX enabled interfaces, does it still make sense to leverage .Net technologies and force the .Net framework and ActiveX controls on clients? If it makes sense to reduce licensing costs at the middle tier, Java, Ruby, or LAMP technologies sure look like better solutions.
So as I look down the road and see a continuous push to reduce costs while increasing value, I wonder how much proprietary software companies will be purchasing 5-10 years from now. Will it be like the mainframe where the only systems left standing are the ones that have no cost justification to replace? Will the norm be that new applications move to OSS? I know we are still a few years away from this but OSS is becoming more mainstream and widely acceptable in corporate IT whether we want to admit it or not.
In Part 1 of this series, I explained my reasoning behind creating an open source strategy. In Part 2, I will discuss our progress. But before I start, here are some predictions from Gartner:
- By 2010, 75 percent of mainstream IT shops will have a formal open source acquisition policy in place.
- By 2008, open source will compete with closed source in every infrastructure market.
- By 2010, mainstream IT shops will consider open source for 80 percent of their infrastructure software needs.
- By 2010, mainstream IT shops will consider open source for 25 percent of their business software needs.
There is a lessoned learned here. Since the company as a whole still has not fully embraced OSS and still looks at OSS as the red headed step child, individuals have gone into stealth mode and started assembling a massive inventory of products that help them get there job done at a very low cost. What I found out is that we have a lot of duplication of products including various different versions. Some of the products are best of breed while others are questionable. If there is ever a need of a strategy, the time is now! Since we rely so heavily on OSS, we must embrace it as a strategic part of our enterprise and put the necessary governance around it. This takes us to step two of our strategy.
Today we spent a couple of hours with Sourcelabs, an open source service provider. This was another eye opening event for me. I knew open source service providers provide support for a wide range of OSS products. But here are a few things they do that I didn't know:
- Stress test and certify OSS products
- Contribute code to numerous OSS products
- Provide a one stop self service portal with information on numerous OSS products, including patches security alerts, product roadmaps, known issues, etc.
- Provide advice and guidance for product evaluations
- Assist in the creation and/or validation of your Open Source Strategy
- Fix product bugs and submit to the product's community for the next patch or release
- Provide certified Java middleware suites
- Provide open source policy and process best practices
So much for the myth that you can't get support for OSS. So to recap where we are with our strategy:
- Step 1 - create an inventory
- Step 2 - educate IT - this started today with our discussion w/Sourcelabs
The hot SOA topic the past few days has been how to sell SOA to the business. I have seen many authors talk theory on this topic. I am getting a little annoyed of when "experts" who don't actually have to sell SOA to their business partners tell me what works and what doesn't work. I am here to give you a real life story.
There are three camps on how to sell SOA to the business. Some experts recommend that you sell executives on the technology aspects of SOA only. The second camp recommends that you speak only about the business aspects of SOA. The third camp, which is where I go camping, recommends that you speak to both the business and technology aspects of SOA.
My recommendation, which comes from a very successful real life example, is to start with the business benefits of SOA. In my case we were pushing both BPM and SOA. We sold the business on the benefits of BPM and then explained how SOA was the key to allow the BPMS tool to talk to our legacy systems. This approach is much simpler then drawing multiple layers of an architecture on a white board and describing what an ESB is, what MDM is, and how web services or JMS queues work. In fact, we were able to get the funding for our SOA initiative without having to describe in gory detail what the different software modules were. Once the business knew that SOA was the enabler for their BPM initiative, which happened to have an eight figure ROI over five years, they didn't need to hear anymore. They only wanted to know how much!
For bonus points, we discussed how SOA (over time) would allow us to rapidly deploy applications because of reuse, increased flexibility, leveraging existing assets, and modular development. This became a win-win conversation. The business was getting a huge return on investment from the operational efficiencies gained by process reengineering, while IT was finally getting the funding they needed to build the architecture that they could never justify in the past.
I am sure there will be many more arguments on the "right" way to sell SOA to the business. The right approach depends on many factors that are unique to each project and each culture. My recommendation is to talk to people who have successfully sold SOA to the business and learn from their experiences. I shared my success story, who wants to share theirs?
My article Open Source and Microsoft Free was posted on Slashdot last week. I woke up on Saturday and looked at my traffic on Sitemeter. My daily traffic before this day was in the 100 range. That morning it read 2000+. I rubbed my eyes thinking that I was not quite awake yet and hit refresh. It shot up another 100. I was averaging several hundred hits an hour. Holy Smokes, I thought to myself! I then went and looked at my referrals and it was all Slashdot. After lunch, I looked again and I was over 6000. A quick peak at the referrals and I saw the Diggs coming it. The next few days were incredible. The article drew over 50,000 hits in a week! Then came the Del.icio.us, StumbleUpon, Craigslist, Linuxworld, Linux.org, and Japanese & Polish versions of Digg & Del.icio.us. It is been over a week now and I still get a few hundred hits a day from that post. That's the good part of being Dugg.
I probably received north of 500 comments across these sites. I am used to the comments that I receive on ITToolbox where I host my main blog. The comments are usually very collaborative in nature, even if the commenter disagrees with my point of view. I have built a very nice network of experts from the professional community on ITToolbox. Compare that to the discussions going on at Digg and some of the other social bookmarking sites. My article turned into an all out war between Microsoft and Linux fan boys. There was so much negativity, profanity, and non fact based opinions going on that I received very little value from the 500+ comments. As a matter of fact, I stopped reading it after a while. I would have had more factual conversations had I walked into a bar loaded with Yankee and Red Sox fans and argued whether Big Papi or A-Rod was a better hitter!
So being Dugg is nice from a traffic point of view, but my real goal with these posts is to share my opinions and collaborate with professionals to refine, defend, or validate my opinions. On Digg, it's all a bunch of noise.
I read this article today about outsourcing that claims that outsourcing is not just about cost anymore. The author points out these four reasons for outsourcing:
-Accessibility to right talentAfter I finished choking on my cornflakes I decided I must offer a different opinion on this matter. First I want to differentiate between outsourcing and offshoring. Offshoring is obviously when you send work to other countries. Outsourcing is when you send work to companies outside of your corporation that may or may not be in the same country. Since the article was based on this link from The Times of India I know that they are really talking about offshoring.
-Geographic expansion
-Reinvention of their business model
-Promote innovation
Here is my take (from a US point of view). Offshoring is a cost savings exercise, period. There is a lot of overhead involved with offshoring due to language barriers, cultural barriers, and time zone challenges. To successfully offshore development, the paying customer must provide a maximum amount of oversite and process to overcome these barriers. Outsourcing is different. With outsourcing, I can bring a team of consultants on site for any amount of time without paying the expenses of flying them in from the other side of the planet. You still need oversite and process but not at the same level because the language and cultural barriers do not exist and the time zone differences are manageable (if there even are any).
I wrote this article a while back about agile development and consulting. In summary, if you want to be agile, don't engage with an offshore partner. Agile development requires face to face interactions and loosely defined requirements due to the iterative nature. The requirements get nailed down over time by cycling through requirements and protoyping. This model is a recipe for disaster if you are using offshore resources. For offshore to work you need to have a more waterfall type approach were the requirements are fairly static.
The article that I came across did not link back to the original research provided by PWC. If you read the PWC article you will see that over 50% of the service providers surveyed are US companies like PWC. So the findings in the research make a lot more sense to me because we are really talking about outsourcing and not totally focusing on offshoring. US companies are definitely leveraging consulting companies like IBM, Accenture, and others to foster innovation, reinvent their business models, and access the right talent. They don't use these companies to save money (they cost an arm and a leg). Saving money is all about offshore development.
The lesson learned for me is be careful what you read on the net. The PWC article is a very good analysis of what is happening in the marketplace. The problem is all of the offshoring blogs are using it to say, "See we are more then a cheap alternative", which does not represent the facts of the PWC research. For those who just read the headlines and don't take the time to read the details, beware!
According to opensource.org:
the promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.But that it is not the biggest driver for our Open Source strategy at my shop. One of our biggest drivers is budget constraints. Every year our IT budget remains flat or increases modestly. When you throw in merit increases, promotions, rising health care costs, and maintenance on software and services acquired during the year, you must get creative to stay within budget. With the exception of Linux on some of our back end servers, most of our enterprise software comes from the major vendors like IBM, Microsoft, BEA, Oracle and many other big names. But when it comes to developing software, it is hard to justify spending big dollars on the large numbers of tools we need to do our job when there are cost effective alternatives.
Our Open Source strategy that we are putting together addresses this. The purpose of our strategy is two-fold. First, we must educate our peers in the enterprise about Open Source. There are many myths that must be addressed to get everyone on board and feeling comfortable when leveraging Open Source. Tim O'Reilly listed 10 myths about Open Source in this 1999 article that still prevails today. Here are a few myths that we will address in our strategy:
Debunking Myth 1Myth #1. It's all about Linux versus Windows.
Myth #2. Open Source Software Isn't Reliable or Supported.
Myth #3. Open Source projects are written by a small group of amateurs in their friend's garage.
Myth #4. The Open Source movement isn't sustainable, since people will stop developing free software once they see others making lots of money from their efforts.
Go to this page on Sourceforge.net and you will see the wide range of software categories that have active and established Open Source projects. If you wanted to, you could run your entire enterprise on Open Source. There is more to Open Source then Linux on the desktop.
Debunking Myth 2
For well established Open Source projects, it is not uncommon that you can get faster and better support in forums then from the expensive "Gold Support" that the major software providers charge you an arm and a leg for each year. It is not uncommon for small and medium customers to see unacceptable levels of support despite being a paying customer. The less money you spend with a vendor the less pull you have escalating support issues. There are plenty of Open Source service providers who provide support for a suite of Open Source products which is an extremely cost effective way of doing business. Traditionally, we pay vendors 18-20% of the cost of the original purchase price of each product. Support and maintenance can take up a huge chunk of an IT budget. With the service provider approach, we can pay the provider one flat fee and get support for several products at a much cheaper rate. What is even better is that the service providers core competency is support. That's all they do and their mission is to do it well. For purchased software, support is pure overhead and usually not the strength of the company.
Debunking Myth 3
Some of the most popular Open Source projects have hundreds or even thousands of developers world wide contributing to the overall code base. Scores of people respond to questions and support issues often within minutes after posting on the forums.
Debunking Myth 4
I wrote an article called Still Afraid of Open Source a while back that discussed how companies like Google and Yahoo are leveraging Open Source while the big guns like IBM, BEA, and Sun are investing big money in support of open source initiatives
The second purpose of our strategy is to identify software needs that we currently can't fulfill with our existing budgets. There are many development, testing, and software development lifecycle tools that we could benefit from but never have the funds to acquire. We need additional testing tools for our SOA initiative, a new defect tracking system, a portfolio management suite, and many others.
By putting a strategy together that identifies needs while addressing the concerns that people might have with Open Source products, we stand a better chance of fulfilling our team's needs with the support of our management.
Once we create a culture that sees value in Open Source, then we can start talking about evaluating Linux as an alternative to Windows when Microsoft drops support of XP in the future. I wrote this article called Open Source and Microsoft Free that discussed why I believe it is important to at least test Linux to understand what the issues would be in a production environment.
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.So what is your Open Source strategy? When you evaluate software, are Open Source products even considered? If it was your money, would you think differently or do you always buy the biggest and most expensive toys? As IT professionals, our job is to bring value to the organization. If you are not even considering Open Source alternatives for any solution, are you really looking out for the best interests of your company?
I have been blogging about my SOA & BPM implementation for the past few months. My earlier posts talked about how we sold SOA to the business, the vendor evaluation process, and our bottom up approach. We have been partnering with a SOA implementation consulting company for the past 10 weeks practicing an agile approach to delivery. In this short time frame we have installed our stack (BPMS, ESB, Data Services) and built a beta version of a B2B portal. Life is good!
So why can't I sleep at night? Because I have only a few months to ramp my organization up to take this over from our consulting partners. This may be the biggest challenge of implementing SOA that we have faced so far! We have formed a business process management organization in the business and hired our first Process Analyst. I feel good about that. We created a team of architects including a testing architect to help build out and govern the architecture. I feel good about that. We have access to network and hardware architects and moved someone into the role of administering the stack. Real happy there! But that was the easy part.
The hard part will be getting the rest of the organization on board with SOA. There are numerous challenges. First, SOA introduces numerous new roles and responsibilities for our staff. We will have to move from being SMEs (subject matter experts) in an application to becoming SMEs in a layer of the architecture (see chart below)
Second, we are moving away from our current methodology which is slightly waterfall in nature to a more agile and iterative approach. We are currently ramping up to implement our governance model.
But the biggest challenge is organizational change management. SOA concepts are drastically different then the way we currently develop applications. We are moving away from thinking about stovepipe applications and moving towards building business services. We still have some legacy apps that are written in VB6. For the folks maintaining those apps, they have not been exposed to web services yet. The world of testing changes drastically with this layered and loosely coupled approach. The DBAs now need to create a logical representation of data to hide the complexity of the joins and relationships from the services. The business analysts role is practically a different skill set now. Traditionally, our project managers have been assigned to applications and work side by side with the development manager who has a fixed team of resources. With SOA, we are moving more towards the classic PM role where the PM drafts a team from a pool of resources. I could go on and on.
So as you can see, every single person's role is changing. At the same time, we have a third party who is cranking out code faster then we ever dreamed of. We are unintentionally setting an expectation that we will be able to move this fast once we take this over. We are not getting incremental head count so we need to figure out how to transform our existing staff from application SMEs to specialists within the architecture over the next few months.
Anyone who has been responsible for managing culture changing initiatives understands the challenges that this presents. For each individual, we must answer WIIFM (what's in it for me) , how will this help the business, what's wrong with the way we do it now, and many other questions that cause resistance when left unanswered. At the same time we need to quickly educate everyone on SOA. Meanwhile, everyone has a current full time job and are assigned to existing projects.
A while back I wrote an article about the role of the enterprise architect. Many people only consider the technology side of the equation. There are days where I don't even have time to deal with technology. Some days are spent evangelizing to create more buy-in throughout the organization. Other days are spent working with business owners on a plan to reprioritize projects to free resources up to work on our SOA initiatives. And even more days are spent working with the development managers on plans to free up resources for temporary assignments (learning opportunities) on SOA projects.
So as we continue down the road with our SOA implementation, I have discovered that the most challenging part of the project thus far is adapting to change. The technology part seems easy compared to this. I will write more about this as we work through future opportunities and challenges.
