One of the challenges for selling Web 2.0 within the enterprise is explaining the value that it brings. To many long timers within IT, Web 2.0 technology is a play thing that the younger generation uses at home. Many can't comprehend the enormous potential that WEB 2.0 can bring to the table in the form of collective intelligence, social networking, RSS feeds, APIs, and folksonomies. You can show graphs and charts, talk about the intangibles and the tangibles, and power point them to death all day long but the best way to sell Web 2.0 is to do Web 2.0.
Here is an example. I am trying to sell the concepts of enterprise blogs, wikis, and RSS feeds. When I discuss these with many of folks within IT I get way more laughs then I get head nodding. When I sit down with various groups within IT and even within the business to explain SOA, I go directly to some of my blog posts and to specific wiki pages to show visual images to help explain the concepts. Look below for an example (single click for quick slide show, double click to walk through slides with captions).
Just today I was working with our SQA team to explain some of the differences in testing SOA applications versus the traditional client server applications that they are familiar with. I bounced around my blog to find a few posts that helped explain what an ESB is and what the layered approach to distributed computing (SOA) looks like. Tonight I took some of the images off those posts and created the slide show above with Google's Picasa. This is a great example of showing the power of Web 2.0. I put together another album from a presentation I did the other day that discussed leveraging some Web 2.0 tools to improve internal communication.
It you are selling the concept of mashups internally, take one of your internal applications that has a customer database and do a proof of concept that calls the google maps api and displays your customer on a map. This will easily allow you to explain the concepts of mashups to anyone within the organization. Here is an example of looking up ITToolbox.Com headquarters using Google Maps.
View Larger Map
Imagine if you could do this with your CRM application when your sales guy hovers over the customer name! Show the business what Salesforce.com is doing with mashups.
So in the words of fellow blogger James McGovern, don't just give presentations about technology, have conversations. By showing people what the technology can do instead of talking about graphs, numbers, and case studies, you can start a constructive conversation to explore the possibilities. Through conversation, people can bring ideas to the table that you never envisioned. Give it a try and feel free to use this blog post to prove your point. Remember, don't just talk about technology, do technology!
One of the many hats that those of us who are responsible for IT strategy and Enterprise Architecture wear is the evangelist hat. My IT organization has many exciting strategies and initiatives in action today such as....
- SOA/BPM implementation
- Creating an official Open Source strategy
- Leveraging Web 2.0 technologies to improve communication
- Moving towards agile development
- Implementing portfolio management
Today we had a day long strategy session to go over our OGSM (Objectives, Goals, Strategies, and Measures) for 2008. Our strategies are broken up into four areas and I own the one called "Architecture and Technology". When we got to my section I started talking about Web 2.0 tools like blogs and wikis and received many chuckles when I recommended that we embrace these technologies. When discussing Open Source strategies I needed to emphasize that this is more the Windows vs. Linux. This is about taking a cost effective approach to providing IT and the business with tools and products to enable people to get their jobs done effectively. Instant messaging is another topic that came up. There is still caution and concern about the downside of enterprise instant messaging. I call it the fear of the unknown which is similar to most IT shops first impression of unleashing the internet to their employees.
What became obvious to me today is that for these initiatives to have any chance to succeed, the architecture and technology strategy team is going to first have to spend some time educating the masses on what these technologies are, what the business benefits are, and what the impact will be to our day to day jobs. We must become evangelists, thought leaders, and teachers. For most of the folks in IT, they need us to break down all of the terminology and research into a practical, "Reader's Digest" version that they can consume and understand without interfering with the mounds of work that they are responsible for delivering. One great way of communicating this is through a blog from the architecture and technology team. We will also have to hold various presentations to sell these ideas in both directions. All of these initiatives require a change in behavior which makes educating and communicating the most critical success factors for delivering success.
Last week I wrote the first part of this series which discussed the installation of Mepis, Kubuntu, OpenSuse, and Freespire on my laptops. Now that I have had time to play with each of the operating systems I would like to discuss my impressions of the different distributions. I have not spent any time on OpenSuse yet so I will leave it out of the discussion.
One point I'd like to make is that all of these distributions allow you to use various open source products for multimedia, system tools, utilities, internet tools, etc. The difference is that they each come with a different set of products that get installed when you load the operating system. All of them have some type of package manager that allows you to easily download and install literally hundreds of open source products. So although some distributions have better tools that you get installed out of the box, this should not be considered a key differentiator for any Linux distribution. For example, I think the Adept package manager is by far the best tool for installing open source products on your Linux box. Some distributions come with it, others come with the Synaptic package manager. For the distributions that don't have Adept, I immediately download it. The major differentiator for me is the ease of install. It doesn't get much easier then Kubuntu's six step install wizard!
I have been using Kubuntu at home for a while now and have been using Ubuntu at work since April of this year. Kubuntu brings the KDE interface to Ubuntu, hence the name Kubuntu. Both have been rock solid and perform well. I prefer Kubuntu and the KDE interface. Last week I replaced Ubuntu with Freespire on my work laptop. Freespire is targeted for first time Linux users and tries real hard create a Windows-like user experience. At first I thought this was pretty cool but eventually I got tired of it. I much prefer the look and feel of Kubuntu and I have no desire to have my Linux distribution resemble the Windows environment. Freespire also seems to be a bit buggy. Open Office goes into recovery mode often when initially opening documents. This does not happen on the other distributions that I have tested. Later tonight I will move off of Freespire and give Mepis a try on my work PC.
I have Mepis running on a laptop at home. It is also rock solid and easy to work with. The install was simple and it has been very reliable. The only difference between Mepis and Kubuntu is the look and feel. Both have run flawlessly and both outperform Vista on far lesser hardware. Since I have not used Mepis in a working environment yet, I still give the edge to Kubuntu/Ubuntu. I have 6 months of real life work experience with Ubuntu in a Windows shop and I have been very productive in that time frame. I have not been as productive with Freespire due to its random issues.
Over the next few weeks/months I will spend more time evaluating Mepis and OpenSuse. I would be happy to experiment with other distributions if anyone wants my opinion on a distribution that I have not mentioned.
David Linthicum hit the nail on the head with a recent articled titled Analysts need to Focus More on Architecture, Not Buzzwords. In the article David points out...The fight here is that Forrester is considering SOA management as something that is very different from SOA governance. However, Gartner thinks that SOA management is a part of SOA governance...
Who cares? I am tired of the SOA buzzword of the day by people so far removed from architecting anything that their goal in life is to be the guy who coined the next hot buzzword. I skim through about 200 blog posts a day and am tired of littering my Google Reader with the next new buzzword like SOA 2.0. As David states in his post,Not sure it will matter in a few years what you called what technology, but it will matter if you don't create an architecture that will drive your business into the future.
So in protest of the daily dribble the shows up in my reader each day, I pronounce this the era of BOA - Buzzword Oriented Architecture. I will ignore what the analysts have to say and continue to follow the blogs of real life Enterprise Architects like Todd Biske, Nick Malik, James McGovern, Eric Roch, and many others.
Many developers work in a department within IT called Application Development. This name, Application Development, represents the way we used to approach building software. For years, managers herded developers into application teams to work on stovepipe applications like order entry, warehouse & shipping, accounting, inventory, etc. As years passed, many of these applications were being purchased off the shelf like today's CRM and ERP packages. Because of this approach developers started specializing in application silos and third party packages. In many cases, these systems had entirely different data models, user interfaces, and architectures.
Now we are in the age of SOA and we are all working hard to get these legacy systems to talk to each other. Many SOA initiatives are tied to BPM initiatives. The BPM initiatives dissolve the lines between traditional stovepipe applications and allow IT to present the users with new user interfaces that hide the complexity of the backend systems. The users now can do their work through a consistent interface guided by a business centric workflow without knowing that they are accessing multiple legacy systems.
As IT shops invest in SOA to allow their legacy systems to integrate with one another, we should stop building applications and focus our efforts on building business services. We should start building services that can be used by all systems as opposed to building code that is customized to fit a specific application. We should also be proactive and think about the different ways in which a consumer might want to use our services. It is not unlikely that a service can be consumed by a user interface by one system, feed from an XML file from another system, and called directly from another service from an entirely different system. The consumers might be a new system, a legacy system, a third party package, or an external entity like a customer system or SAAS solution.
So as we move away from our traditional stovepipe approach of application development, should we still call our department App Dev? To me, application development is the thought process of yesterday and business services is how we should be thinking today. I'd like to stick a fork in the term application development because to me it represents high maintenance, duplicate efforts, silos, and IT as a cost center. I'd like to call our department Business Services Development which represents flexibility, speed to market, business alignment, and IT as an enabler. What would you call it?
There have been many blogs that argue whether SOA is an IT only initiative or a business initiative. Regardless of who or what is driving SOA, one way to maximize your investment is to align SOA with your company's project portfolio (hopefully you have one).
Let's think about that last statement for a second....
...align SOA with your company's project portfolio.
The value that Project Portfolio Management (PPM) brings to the table is that if done right, PPM ensures that the company focuses its assets (people, products & services, hardware & software, etc.) on initiatives that align with company strategies. Now if you have everyone working on the right projects, the next logical step is to focus your architecture on the projects that bring the greatest value. If the PMO (Project Management Office) does its job and helps the business manage its project portfolio(s), then the architecture team can align with the business to maximize the value of SOA.
I recommend that a company has more then one portfolio. I will use a fictitious company called Acme Toys to demonstrate why.
Acme Toys is a 30 year old toy manufacturer who has a new CEO. The CEO is charged with doubling revenue in the next five years and removing waste from the operational aspects of the business. The IT team has recently implemented SOA and BPM and is starting to reach a modest level of SOA maturity. They have an effective governance model in place that they are constantly refining and have a few high profile projects under their belt. The next step for IT is to figure out where to leverage SOA next.
The CEO gathered his leadership team and put forth a strategy to meet his goals of doubling revenue and improving processes. The CIO and the Head of the PMO proposed creating four separate portfolios to be funded and staffed separately. The picture below illustrates the recommended portfolios.
The growth portfolio is where the company manages the projects that enable the company to double its revenue over the next five years. Within each portfolio there are programs. Programs can be defined as a collection of projects. In other words, a program is a strategy that maps to a goal, while a project is a tactic for delivering the strategy. Here is an example of a Growth Portfolio:
You can see from this example that B2C (Business to Consumer) is a program or strategy. Underneath that program is a list of projects that help deliver the strategy.
The next portfolio is the Optimize Portfolio. In this portfolio Acme Toys focuses its resources on operational efficiencies. Below is an example of what this portfolio might look like.
Acme Toys still needs to keep the lights on so the PMO recommended an Infrastructure Portfolio where IT can drive and manage upgrades, cost reductions, and modernization of its IT services and assets, as well as, deliver compliance or regulatory type projects like SOX or PCI Compliance.
And finally, Acme Toys needs to drive innovation in new products. They have a separate Research and Development team that prototypes various new potential products. This team's charter is to prove out the viability of new product ideas before the company makes huge investments in manufacturing and IT to productionize the product.
That rounds out the four portfolios. Now the IT team has clear direction on where the company is going over the next 12-24 months and can start looking at aligning SOA with the various portfolios. For the sake of this example, let's say that the architect team has enough bandwidth to contribute to two of the four portfolios. It is likely that IT would choose to align with the CEO's goals of growth and optimization. This allows IT to focus its efforts on the programs within those portfolios. The architecture team assigns a group of solutions architects to the Growth Portfolio. They now have a roadmap of projects to start identifying candidate services. With this 12-24 month roadmap of projects provided by the PMO, the architects can then prioritize the candidate services based on business value and potential reuse. By front loading highly reusable candidate services, the architect team can reduce the amount of new development required for future projects. Here is an example.
After analyzing the list of projects for the next 12-24 months, the architect team built a SOA roadmap. They identified two candidate services that would be used in every single project. The first candidate is a product lookup service and the second candidate service pertains to authentication. These two services will be prioritized high and addressed in the first project so the work can be reused in all of the subsequent projects.The architecture team staffs the Optimize Portfolio with another group of solutions architects. They follow the same process for identifying candidate services for the project roadmap within their portfolio. The enterprise architects provide oversight for both of these portfolios to enforce governance and to take on building or modifying any enterprise wide services that are identified within the projects. The solutions architects work on the application or process specific services.
To wrap up this long post, I hope I have made it clear how Project Portfolio Management can be a great asset to the architecture team in their quest to further entrench SOA into the enterprise. PPM provides a clear vision into corporate strategy which the architecture team can leverage to maximize the value of SOA. I would love to hear your thoughts on PPM and SOA.
One of the main reasons why I blog is to share my experiences with other Enterprise Architects so we can learn from each other. Today, I am not going to share a success story but instead will describe some decisions we made early on that we would probably do differently now that we know more.
The scenario:
After we sold the business on BPM and SOA, we were challenged to implement a pilot project quickly to show the value of SOA. It was critical that we deliver early and often as opposed to going off for 8-12 months without giving the business any relief from its legacy business processes. To meet this objective we established a 12 week "pilot" or "beta" project that started as soon as we purchased our SOA stack. This did not give us time to implement governance. We agreed that during the second wave of projects we would implement governance as part of those projects. As we started the second wave of projects, I mandated that all code should be delivered with test harnesses, the build process should be 100% automated, and testing automation should be part of the project deliverables.
Those all seemed like reasonable objectives, so what could go wrong with that plan?
The Reality:
A few things happened along the way that caused the initial pilot project to extend longer then anticipated. First of all, getting all of the individual pieces of the stack (portal, BPM, ESB, and data services) to work properly together took way longer then any of us ever dreamed of. Luckily the vendor understood the urgency of our issues and dedicated many resources to help resolve our issues but this cost us several weeks. Guess what? Now we are mitigating our risks for getting the next six concurrent SOA projects delivered by the end of the year. What do you think is the only thing left to cut out? That's right, governance, build automation, and testing automation.
Lesson Learned:
Don't take any short cuts when it comes to governance and automation. We will eventually get there but it will be much harder to implement this stuff at a later date then it would have been before we moved to production. I am also fearful that we might continue to prolong or delay governance and automation to hit various dates along the way. We can get by today, but several months from now when we have over a hundred services and a dozen projects in production, we better have this resolved or we will be working hard instead of working smart.
Recommendations:
Here are a couple of things I would do differently next time. Staff the governance and automation initiatives with dedicated individuals who are not tied to other deliverables. I would also define and manage these initiatives as individual projects with published milestones and get executive buy in to ensure that these deliverables get the focus they need.
Hopefully this has been helpful for those of you who are considering SOA or are early on in the process. I would love to hear your experiences and/or your recommendations going forward.
The family was gone most of Saturday so I took the chance to download and install various Linux distributions. Here is the list that I installed this weekend:
Now that I had all my tools and all my CDs ready, I started installing them on various computers. All four installs were simple and straight forward. The Freespire install is probably the best for those who have never seen anything other then Windows in their life. The partition tool was also very intuitive. Kubuntu has an extremely easy 6 step install process. Unless you are getting fancy with partitioning, this should be simple to do. The Mepis install was also very easy although not as intuitive. And finally the Suse install took a couple of tries until it was successful.
Then I tried to get fancy and install multiple distributions on the same laptop. That's when things started going south for me. Keep in mind that I am a software guy, not a system administrator so I am not a pro in this area. After several tries I finally got Mepis and Kubuntu to dual boot from the same laptop. Unfortunately I lost my ability to connect to my wireless network. It was working when I had Mepis running but I think the second distribution may be causing a conflict. I hope to resolve it soon.
My parents were over today and they were using Kubuntu and liked it. If my parents can use Linux, anyone can. They were getting frustrated with their five year old PC running XP and were ready to buy a new one. This week I will convert them to Kubuntu and their PC will start performing for them again. That should save them a few grand.
I took some screenshots of each Linux distribution and posted them on Picasaweb. Feel free to view the slideshows below and go to the photo album for close ups.
Mepis
Freespire
Kubuntu
- All of your projects are #1 priority.
- You have more projects assigned to you then you have people to work on them.
- Most of your resources are only allocated 50% or less to your project.
- The users figured out that if they pull a large enough revenue number out of the air, their project will get funded.
- You can't free up resources to work on the new #1 priority project because your executive sponsor demands you continue to work on the next maintenance release.
- You have no idea how much the project really costs.
- Your #1 priority changes week to week.
- You get half way through the project and the user decides that they don't really need the project.
- Your project is a year and a half late with no end in sight and nobody wants to cancel it.
- You have $30K/yr data entry clerks making $80K/yr developers work on non value add maintenance items.
- Focusing on the wrong projects
- No accountability for what the business is asking for
- Lack of focus due to out of balance resource allocations
- Having no visibility into the Total Cost of Ownership (TCO) of projects
- Priorities set by the "Bubba System"
- Continuing to throw money at death march projects
- Short term design decisions due to lack of time
Businesses should think the same way. They should look at their projects as investments in their company. They should have a mix of strategic, tactical, regulatory, and growth initiatives to name a few. This means that the people requesting the projects should put together business plans that map to corporate goals and show the predicted financial impacts over a five year period.
But you can't stop there. Like all smart investors, once you buy a stock or bond, you typically monitor the performance of that investment. The last thing you need is to be stuck with a few thousand shares of stock that has plummeted from $100 a share to a penny stock. I have seen companies watch projects pass the point of diminishing returns to the point where they pour money month after month into projects that are so late they will never pay out.
Many people view Portfolio Management as another wasteful process initiative. In my experience over the years, many of the issues I have seen in IT stem from an ineffective prioritization process, no visibility into resource allocation and utilization, lack of alignment with corporate goals (if there are any), and lack of visibility into project costs. The end result is a ton of people working very hard, but not working very smart.
I have many colleagues and friends who have been through messy divorces. In each case, these poor guys have gone from having the good life, to having issues, to losing half of their assets (or more). I just filed my divorce papers for Microsoft's
With all jokes aside, I recently posted my positive experience of installing Kubuntu on an old 1.7GHz machine that was taking 10 minutes to boot up XP. The registry was beyond repair and the various programs like Spybot, Adaware, PitStop, Defrag, and many others did little to improve performance. The desktop was destined for the dumpster. Enter Kubuntu and this PC now works like a champ. I installed Wine on it and got IE 6.0 running on it for those foolish websites that target only the Microsoft browser. My daughter plays various Flash enabled games on Club Penguin. On my brand new Dell Inspiron 1721 laptop running
So I installed Mepis 64 bit on my laptop and wiped out Vista. My daughter launched her game and it loaded instantly. Her exact words were, "Wow, this is so fast". My response was "Good Bye Vista!". So let's take the religion out of this discussion and talk about the investment I just made on my hardware. I bought two brand new identical laptops for $1000 each. These laptops have a Dual-core 64 bit processor with a Gig of memory. Now the Microsoft fanatics would cry, "why would you buy a laptop with only a Gig of memory?" My answer is, my budget doesn't allow for laptops that cost $2K-$3K and the main usage of these laptops are web browsing, email, and word processing. None of those functions require a ton of computer resources. I also have a monster machine (Dell XPS gaming machine) for all of our intense gaming needs (Battlefield 2, Civilization IV, Age of Empires, etc.). So two laptops for $2000 dollars was what I was willing to spend. Unfortunately, Dell did not offer XP or Linux on these machines. The cost of Vista is about $300. So 30% of the cost of my laptops was for an operating system that drained 50% of my resources and performed poorly.
I am not a financial analyst, but that is not a good spend of money. Now that I have eliminated Vista from the equation, I get a better ROI on my investment, even after acknowledging that I threw away $300 worth of software. As I mentioned in a post called Vista - What were they thinking, my wife dislikes Vista so much that she refuses to use the new laptop that I bought her for her birthday (due to it's poor performance). Now she is happy with the laptop running Mepis and the old clunker running Kubuntu.
My plan now is to move all of our computers except the gaming machine to Linux. The gaming machine will stay on XP while the laptops will leverage Wine and virtual machines for those Windows centric programs that won't run on Linux. I will install various Linux distributions and allow for the user to select from a list of distributions when booting the system. Eventually we will probably settle on a distribution like Kubuntu of Freespire that has an interface similar to Windows for an easy transition.
 |
| From Kubuntu |
So for all of the folks out there who have gone through a messy divorce, divorcing your Vista operating system is the only divorce in town where you get your assets back and still get to keep your kids!
I am doing an experiment at home. I recently purchased two new laptops from Dell for my wife and daughter for their birthday. As I wrote in a previous article, these laptops came loaded with Vista. Vista has completely frustrated my family because of the poor performance, the bugs, and the interface. My wife refuses to use her new laptop so I gave it to my son. I took my daughter's old PC (Dell 4300s with 1.7 GHz, 256MB memory, 40GB disk) that was performing poorly on XP and installed Kubuntu 7.04 on it. The install was incredibly simple despite the myth that Linux is hard to install. The total install took about 70 minutes. Most of that was due to the time it took to partition a very old hard drive. Once the install completed I plugged the PC into my Linksys access point and just like that I was up and running. I was able to see my shared folders on my XP machine and print to my Lexmark x73 scanner/printer.
As I have written in the past, I use Ubuntu at work. A friend of mine recommended Kubuntu so I tested it out at home. Kubuntu has a very nice user friendly interface. It's desktop manager is actually similar to Vista's. Kubuntu comes preloaded with Open Office, chat, dvd burning software, graphics software, the Konquerer browser, and many more open source software packages. This is the first time I used Konquerer and I found it to be equal to if not better then Firefox.
Like Ubuntu's package manager, Kubuntu has the Adept Manager which provides a simple user interface for installing software. For those users who are not hardcore Linux geeks and don't want to mess around with tar files and the like, Adept Manager is the tool for you. There are literally thousands of open source products listed by category and completely searchable. I added Wine, Thunderbird, Firefox, Gimp, and a hand full of other popular tools. I simply clicked the check box next to the desired software, clicked apply, and the Adept Manager did the rest. Who says Linux is hard to install?
So now that I have this up and running on my slowest and oldest machine, I am going to have my wife and kids test it out to see if it meets their needs. If they are comfortable using Kubuntu, which I expect they will be, I will be kicking Vista out of my house. I will always have my Dell XPS gaming machine with XP on it for the rare times where they can't get their needs met on Linux. So far the only thing I can come up with is some of the games we play. Most of the PC usage in my house is internet surfing, email, and office. We have been using Open Office, Firefox, and Thunderbird for years, so this should be a simple transition.
The next experiment will be my parents. I still have to reset the clock on their VCR everytime I go to their house. All they do is read email, surf a few web sites, and play Spades and Mahjong. I am giving them my son's old computer, which is a very good machine, and taking back their old PC. I will mess around with Mepis on that PC. Once I get that installed I will give it back to them with a wireless USB adapter and see how they adapt to Linux. They already struggle with XP so anything will be a challenge for them. If my parents are able to use Linux, then anyone can use it. I'll provide an update on their Linux experience in the next few weeks, assuming that I find time to get them set up.
We are in the middle of implementing our SOA Governance model. We have put together a ton of lengthy reference documents like the architect guidebook, SOA roadmap, developer guidebook, administrator handbook, and many others. Our biggest fear has been getting people to read these documents. In order to enforce our SOA best practices and standards, people must be aware of what they are. Giving people 200-300 page documents is not an effective way of sharing information.
Enter open source wiki tool, MediaWiki. With a little help from OpenOffice v.2.3, we took the lengthy Word documents and converted them to Wiki Markup to create easy to use, clickable, and searchable documents. Now our architects and developers can easily maneuver through pages of pertinent documentation without being overwhelmed by large sequential documents. In addition, people can collaborate by using the discussion feature in MediaWiki to help the architect team improve upon the documentation.
Our next step is to implement an open source blogging tool. One of our challenges today is to communicate both technical and project specific information pertaining to our SOA initiative in a timely manner. I have held a number of meetings with several IT teams to walk them though various presentations and white board sessions. Unfortunately I don't have the bandwidth to do this often enough. We will start to leverage blogging technology to share daily information about the initiatives. People who are interested will be able to subscribe to these blogs using an RSS feed reader. This is much more effective then pushing more email on people.
And finally, we will create an Enterprise Architecture community in our enterprise portal. This will allow us to bring all of our content together in a one stop shop approach. The community will display our blogs, our wiki, project status, tips & tricks, announcements, and various other information.
One of my lessons learned so far on our SOA project is that we do not communicate often enough. I believe a combination of monthly presentations and white board sessions, along with our wiki, blogs, and portal community provides multiple opportunities for people to keep up to date with our SOA initiative. I also think it is more effective to publish content and let people "pull" it on demand then to "push" it on them.
I just returned from a great vacation and saw that James McGovern had a few questions for me.
Question #1 (after reading Real World Open Source Solutions)
Mike Kavis believes that others should help spread the word that open source isn't just about Linux. Maybe Mike could talk about where folks get their information, such as all those advertising dollars paid by barely open source vendors and their outsourced PR departments otherwise known as industry analysts.Answer
Getting information for open source software is not much different then getting information from closed source software. Yes, there is less conferences and less marketing/advertising, but those two sources should not be where you find all of your information. Leverage your network, read blogs, search the web for case studies where other companies have leveraged open source software to address specific areas like CRM, project management, database technology, portals, etc. I like to go to sourceforge.net and other popular sites and look at the number of downloads and the size of the community. Those two numbers can clue you in on which products to start researching in greater depth. I also use my Google Reader to follow articles on these sites: OpenSourceCommunity.org, OpenSources, OSS-Biz, NotJustLinux, OpenSourceUnleashed, and LinuxToday to name a few.
Question #2 (after reading Who's Killing SOA?)
I wonder if Mike Kavis understands the simple truth that most enterprise architects don't actually know other enterprise architects in other enterprises. Many of us are insular in nature?Answer
I do understand and that is one of the main reasons why both James and I have called for more EA Collaboration. EA's need to "get out" more and see what the rest of the world is doing. Why reinvent the wheel from scratch? Throw some ideas out there and see where the conversation leads. Add your two cents to other bloggers' opinions and contribute to the overall good of the community. If you disagree with a viewpoint explain why. Other EA's can read both view points and decide for themselves which approach is best or maybe a combination of the two makes more sense. I know that EA's don't actually know other EAs in other enterprises because I knew none before I started blogging back in March of this year. Now I have a great network comprised of talented individuals who share their thoughts on important topics.
In case you are wondering why I haven't posted anything lately, it's because I was having the vacation of a lifetime. First, I spent three days in the Keys at my condo with a few fishing buddies. We had perfect weather and landed 15 mahi, 10 tuna, and a nice cobia. We took a few filets from each type of fish and headed to Lazy Days in Islamorada where they cooked up our fish a few different ways. We added conch chowder and a few Pina Coladas as we watched the sun go down from our balcony view.
The next day, I was on a plane to New Jersey to catch the Giants-Jets game. I am a huge Giants fan. It was an amazing 80 degrees at the Meadowlands. I landed some great end zone seats and watched the Giants rally (35-24) to reclaim the bragging rights for another four years.
Now I am totally refreshed and relaxed and ready to get back to work and start blogging again!
I found a few interesting real world examples of companies leveraging Open Source as a competitive advantage.
PayPal - Linux and open source software pay off for PayPal
In this scenario, PayPal processes millions of secure financial transactions equating to billions of dollars while leveraging a suite of open source products. Despite the myths, open source provides secure and robust solutions for multi billion dollar companies like eBay, the owner of PayPal.
Travelocity - Check out this video on HP's site
In this example, we are not talking about open source as a free solution. Travelocity partnered with HP to implement a Linux-based platform that improved performance while decreasing costs. Parent company, Sabre Holdings also cut costs by 40% switching to open source database solution MySql.
Amazon - Partners with Pingtel to provide open source enterprise class communications platform.
Pingtel bundles a suite of open source communications products and provides support and services. They offer low cost VOIP solutions that are robust enough for huge companies like Amazon.
I could go on for ever with real life examples of open source products making a difference in the corporate world. When hearing the words "open source", many people associate it with the Microsoft vs. Linux religious wars that rage on endlessly. In reality, "open source" software is changing the way we do business. If your company is not looking at how it can leverage open source, it is not doing its shareholders justice. This does not mean your company should replace its operating system, this means that your company should be looking across the enterprise to see where open source could provide cost reduction, flexibility, and a competitive advantage. There are many great white papers that show how enterprises are implementing open source business models and strategies. We need to educate the decision makers that open source is more about the enterprise and not just about Linux.
Yesterday I summarized my thoughts on Zapthink's article called Who's Killing SOA. Today I plan on answering the three questions that Jason Bloomberg asked his readers at the end of the article.
Do you feel that SOA is truly in jeopardy?
No. I think companies that don't approach SOA as a culture changing, long term investment are in jeopardy. The SOA value proposition is real. Implementing it is no walk in the park. You need strong executive buy in, significant funding which goes far beyond the stack, great people and great partners, world class tools, and a strong champion to take the team through the trenches and conquer the complex technology and culture challenges.
I believe that only 40-50 percent of the companies that try to implement SOA will eventually complete a few SOA initiatives. Half of them will get it right. The other half will confuse implementing a ton of web services with implementing a service oriented architecture. Those that make this mistake will not see the true value of SOA. So when the dust clears, I predict only 25-30 percent of the companies will get it right. This will cause a perception that SOA was another fad that has come and gone and left many companies in its wake. The reality will be that once again, many IT shops don't know how to manage large and complex projects.
Which forces do you feel are most responsible for the dangerous situation SOA finds itself in?
Leadership, resistance to change, and project management. Let's start with leadership. The IT person leading the charge must truly understand the concepts of SOA. That doesn't mean that they attend a Gartner summit and then start a project. This person must perform extensive amounts of research and understand the concepts of a distributed architecture, the benefits of a layered and loosely coupled architecture, and the need to view requirements and design at an enterprise level as opposed to an application level. In addition, one must understand some of the drawbacks of SOA like performance trade offs, complexity of managing a distributed environment, and the extensive investment in governance that is necessary to make it all work.
Resistance to change. One of the biggest killers to any new technology approach is resistance. The project champion and executive sponsor must constantly apply change management principles. The stakeholders must understand WIIFM (what's in it for me?), what the road map looks like, and how to get there. Roles and responsibilities will change, IT must work closer with its business partners, waterfall methodologies must be cast aside for agile methods, and new skill sets must be learned and/or acquired.
Project management. Any project that touches the enterprise and radically changes the culture and alters the existing technologies needs a strong project manager with a thick back bone. Projects like this can easily get off track. Some companies spend months and months generating documents and going into analysis paralysis. The PM must set aggressive and short milestones that force the team to show value to the business early on. The business can't afford to have IT's top talent go off into a closet for a year without delivering. Set delivery goals every 2-4 months. Show value early and often to get momentum, continuous buy-in, and to help foster change.
How can we work together to overcome the challenges, and craft SOA into the mature, ubiquitous approach we all desire?
Keep writing articles like Who's Killing SOA. Continue to encourage the EAs to collaborate via Blogs, wikis, etc. Continue to host meaningful conferences with industry experts to share the knowledge and lessons learned. One of the reasons why I blog about SOA is because I am learning this stuff on the fly and feel obligated to share my successes and failures so those getting ready to walk down the path can learn from my experiences or give me advice. Much of the valuable information that I gathered while studying SOA came from discussions that I encountered on the internet. Whether it was a good article on Zapthink or ZDNet that sparked comments from architects around the world, articles from experts who shared their experiences on their blogs on in wikis, or networking at conferences, every person's perspective was an important piece of information that I used to formulate my own ideas on how and why to implement SOA. The bottom line is that we must leverage the collective intelligence of all those willing to share their experiences.
I saw an interesting article on Zapthink today called Who's Killing SOA (you need to register to see the article). In this article they discussed the different groups of individuals who are causing some implementations of SOA to fail. Here is a quick summary.
Integration platform vendors. Some of the vendors are pretenders and have put some wrappers around their products and call it SOA.
My take. Do your homework, spend some time on a well thought out RFP, and have the finalists come on site and do a proof of concept to prove that their stuff lives up to their Power Points and marketing brochures.
Enterprise architects. Not all architects "get" SOA. Some think it is something you buy in a shrink wrapped box and install. Others think it's a bunch of web services. Some EAs are technical enough and business savvy enough, but they just don't get the concepts.
My take. Train them immediately. If they still don't get it, get them off the project before your project is doomed for failure. The EAs are key to a successful SOA implementation. Not only do they design and implement SOA, they are your evangelists for the rest of the developers who are watching the project to see if it gains traction in the organization. You need highly motivated individuals who believe in the promise of SOA. If you don't have EAs like this, don't even bother.
My take. If you are relying solely on analysts you are dead meat. Talk to other EAs, read blogs, leverage your network, talk to companies that have successfully implemented SOA. Analysts are just one source of information and most are bias.
CIOs. On this one I will quote the story.
You'd think that every CIO would be all over SOA. After all SOA can reduce integration cost, increase business visibility and agility, increase asset reuse, and ease regulatory compliance. What's not to love? For any organization that faces any or all of these problems, SOA is a no-brainer. And yet, the CIO is rarely the SOA champion for the IT organization.
The reasons for this lack of insight are many and varied. Many CIOs are nontechnical, and as a result don't understand, and often fear, architecture of any kind. Others are so driven by quarterly results that a long-term, iterative initiative like enterprise SOA is out of the question. Still others insist on project-based IT funding to meet the needs of individual lines of business, a funding mechanism virtually guaranteed to slow down any initiative that seeks to reuse assets across the IT organization the way that SOA encourages.
Fortunately, you can recognize clueful CIOs because they understand the business value SOA can provide, they are willing to fund initial SOA iterations, and as the IT organization delivers value with those early projects, the CIO authorizes more of the same. Unfortunately, however, such executives are few and far between.
My take. If your CIO is not on board you better have strong sponsorship from the business. Somebody high up needs to be passionate about this project and drive it through the organization. Make sure you capture key metrics that prove out the value proposition. Track service reuse. Continuously sell the value of SOA to those in doubt. Here is a good summary of benefits from fellow blogger Eric Roch.
Large consulting firms. SOA experience is hard to come buy. Most companies need to leverage the expertise of consulting firms to help implement SOA. Unfortunately, the skills shortage also impacts the consulting companies as they are rapidly ramping up with resources to meet the demand in the market place.
My Take. Invest some time into interviewing the technical leads of these firms. Do several reference checks. If you have purchased tools, ask for references for companies that have the same tools. Check with your vendor to poll their organization to provide feedback on the consulting firm. The vendor wants you to be successful too.
My Take. Tie your SOA initiative to business objectives. In my case, we sold SOA as the infrastructure necessary to leverage the business's investment in BPM.
I thought the Zapthink article provided a great view into the players who could derail your SOA project. I would add one more group and that is your IT department. Many IT departments have seen many silver bullet solutions come and go and can be pessimistic about all of the hype about SOA. In addition, many IT shops do not have a great history of implementing large culture changing initiatives.
My Take. Attack your SOA implementation in small manageable chunks. Create 2-4 month deliverables, spend time on change management, evangelize, advertise wins, and squash any resistance.
At the end of the article, Zapthink asked a handful of questions. I will post my thoughts on these questions tomorrow. Stay tuned!
The ZapThink Questions
Do you feel that SOA is truly in jeopardy?
Which forces do you feel are most responsible for the dangerous situation SOA finds itself in?
And most importantly, how can we work together to overcome the challenges, and craft SOA into the mature, ubiquitous approach we all desire?
