Enterprise Initiatives

I have been thinking about writing this post since I wrote this article about Second Life. As I was getting my daily updates from my Google Reader I came across Nick Malik's article called

Using Massive Multiplayer Online Concepts to Build a Shared Architecture

In this post Nick writes:

What I haven't seen yet (and perhaps it is the nature of the child-like games my kids play) is a MMO game where every person plays a role to build something instead of defeating something. It is easy to tear something down. Divide and Conquer. Building something up is much harder.

Welcome to Second Life. If you still are not up to speed on how Second Life is being used in the business world you must read this article called Alternate Universe. As I continue to follow the success of Second Life I often wonder why is it that Linden Labs can create such a successful architecture that runs a virtual world with over 8MM users world wide while most companies struggle to create an architecture to support the real world?

So I did a little homework and as I suspected, Linden Labs leverages open source technologies like MySQL, Apache, Squid, Mono, uBrowser (for online help) and Debian as its choice of operating systems to run its grid technology. Linden Labs provides developers with APIs that are simple REST style web services. They have their own proprietary XML format (called LLSD) that supports Perl, PHP, Python, and Ruby. They have a very robust portal and wiki which uses Mediwiki, another open source product.

The beauty of this architecture though is not the open source technologies that they have chosen but instead is the use of open standards which allows them to create a platform for others to build from. People can contribute to this platform as C++ developers, they can use Second Life's scripting language, they can leverage a host of third party tools and services, or they can simply use the tools provided by the user interface. This is a very open environment, much like many of the successful open source projects that exist today.

Now back to the topic of architecting the real world. As architects within an enterprise, we should take the time to review the benefits of the Second Life architecture and apply it to our work. Here are some of the obvious benefits:

1. Open; supports multiple development platforms
2. Easy to use; simple interface & documentation is easy to find on the wiki
3. Scalable; scale up by adding more nodes to the grid
   
4. Cost effective; use of open source reduces high cost of software licensing
5. Enables users; users are free to innovate and are not restricted by the architecture
6. Extendable; other companies can leverage platform to drive more revenue inward

Isn't this what we should be delivering in the real world? Do you think they spend a lot of time arguing over process? Do you think they spend a lot of time gathering user requirements? Or do they have a vision and know how to anticipate user needs? Have they tried to handle every possible exception in the world or did they create a robust set of standards that do not restrict usability and functionality?

There are still many people who are unaware of what is happening in the virtual world and others who are not taking this movement seriously. We just may be looking at the future of business where individuals and businesses do most of their commerce in virtual worlds. The architecture will definitely support it. Whether virtual worlds are the future or not, we should at least study the underlying architecture and the interactions that take place in their open development community.

I stumbled across this webcast that contains a 26 minute video explaining Microsoft's virtual licensing. When you need to spend a half hour just trying to figure out how you are getting shafted on licensing then it is time to look for alternatives.


Video: Licensing Microsoft Servers for Virtualization

Oh, and by the way, there are nice alternatives to VMWare also.

I started blogging in March of 2007 and have enjoyed the experience thus far. I have learned a lot about writing, received valuable feedback (both positive and negative), and have built a great network made up of very smart people. Heck, I even had a few people approach me about job opportunities out of the blue. The purpose of this post is to share a story about why I started blogging.

Back in February, I ran into an old friend of mine named Mary. Mary is a retired professor who co-authors a book on database management. She was telling me about her retirement and how she and her husband spend 6 months of the year driving their RV across the states. Every other year she writes a new addition to her book which is used in several graduate programs. I asked her how she was able to keep up with technology when she is on the road. Her answer....blogs. In her earlier editions of the book she spent a lot of time and money interviewing technology folks across the globe. Today, she relies heavily on blogs. As she travels the states, she stays up to date on emerging database technologies and case studies using her broadband mobile satellite dish. The blogs allow her to create a powerful network of top notch professionals whom she reaches out and collaborates with from the comfort of her RV.

Before I had this conversation, I read blogs but not religiously. On the way home I starting thinking about the conversation with Mary and came to the conclusion that there was a lot more value to blogs then I was aware of. Over the next few days I started researching blogs and seeking reasons why people choose to blog. Then I started studying blogs about enterprise architecture and was amazed to see so many relevant conversations happening in cyberspace. So I started subscribing to relevant content using Google Reader. In the past, I would buy and read book after book from Amazon to learn as much as I could about the topics that interested me. The down side of books is that they are based on the past where as blogs are based on the now. On occasion, I was lucky enough to attend some conferences where I would talk to as many people as I could to share lessons learned. The problem with conferences are two-fold. First, there is too much bias because of the amount of people who are associated with vendors and second, a lot of people there don't really have a clue and are just chasing the technology of the month.

After only a few weeks of reading blogs, it became real apparent to me why Mary was able to continue updating her book by the use of blogs. There are a lot of great minds out there sharing their experiences, refining other people's ideas, and giving writers feedback. Then I stumbled across a post where an architect described the reasons why he blogged (I can't remember who the author was). There were many valid reasons but one stood out for me. After a year of blogging the architect was able to look back over his posts and view his journey over time. That was intriguing to me. I was in the middle of launching a project that is transforming my company. We are implementing BPM and SOA. I thought that it would be a great idea to capture my journey. I also felt that I had a lot of good experiences that I could share with those who read technology blogs. So I started writing.

I have been writing for five months now and I have benefited from it in many ways:

1. It has taught me how to write better.
   
2. It forces me to research topics thoroughly.
3. I have built a network with some top notch people in the industry.
4. It allows folks at my work to see what my thoughts are on different topics (I lead the architect group)
5. I get feedback (good & bad) on my thoughts and opinions.
   
6. I am able to see other point of views. People tend to challenge ideas more readily in blogs then they would face to face.
7. Most importantly, I learn from other people's experiences

The last bullet is extremely important for me. I have been at the same company for 12 years. I have a perspective of the impact of decisions over a long period of time. Many bloggers out there like my friend Eric Roch, are consultants who have experiences that cross many companies. I have seen a company grow from an IT shop of 30 to a shop of 200. I have a ton of lessons learned on how to grow and evolve an IT shop. Eric gives me the perspective of how different companies have tackled similar issues (both successfully and unsuccessfully). This is one example of how blogging has helped me build a valuable network that I was lacking because I haven't changed companies in over a decade.

I get so much value out of blogging that I kick myself for not knowing about it earlier. I am now on a mission to bring Enterprise 2.0 technologies like blogs and wikis into the workplace so that our shop can share similar experiences within our own walls.

The architects who blog are an interesting group of individuals. They are passionate about their topics and many are extremely opinionated. We tend to argue over definitions, methodologies, and approaches. In reality, there is no right or wrong answers. The "right" answer often depends on a variety of factors including company culture, budgets, leadership, and the talent level of the team. With that said, I still get a lot of value from the back and forth arguing because I get to see things from various perspectives. One of my favorite articles was about how we successfully sold BPM & SOA to the business. Computerworld.com, IBM, and a few other web sites linked to it. On the other hand, James McGovern had this to say:

Sadly, I hate when other enterprise architects give out bad advice such as selling SOA to the CEO by tying it to cost/benefit when in all reality, a good enterprise architect would know that the CEO should stay focused on business strategy while his/her deputies should stay focused on business architecture. At no time should SOA be sold outside of IT. If anyone tells you otherwise, run in the opposite direction.

Like I said, what works at one organization, may not work at others. In my case, the CEO has claimed that this is the top priority in the company and has backed it with funding. Sorry for the "bad" advice. I do love James's blog though. He has a built a rare brand that combines technical expertise with an in your face delivery style. I am always happy when my posts make it by without showing up on his site!

I write about the technologies that I deal with at work like BPM, SOA, Virtualization, and Portfolio Management. I often write about controversial topics like open source and offshore development. Both of these topics tend to get people animated and generates a lot of conversation. This is also a big benefit for me. If I am trying to sell the value of open source at work, it is helpful for me to understand opposing views. I sure get those views from the comments on my blogs. The same for offshore development. Whether I like it or not, my company has made a strategic decision to offshore certain projects. It is my job to make it work. I have written various posts about this topic which is a great way to attract opposing opinions. Understanding opposing views helps me understand the type of resistance that I might face at work.

To wrap it up, blogs are changing the way the world gets information. We no longer have to be force fed information from vendors and paid analysts. Now we can collaborate with experts across the globe. Here are some of my favorites:

Andrew McAfee - Associate Professor at Harvard Business School
Michael Hugos - His blog on Computerworld
Nick Malik - Inside Architecture
Eric Roch - SOA Blog
Don Hinchcliffe - Enterprise Architecture
Todd Biske - Outside the Box
James McGovern - Enterprise Architecture: From Incite comes Insight
Dana Gardner - FASTForward Blog
Joe McKendrick - Service-Oriented Architecture

and my all time favorite...

Athena's Blogs about Cats and Dogs - My 8 yr. old daughters blog (story here)

Virtualization is another hot topic in IT today. It allows you to run multiple virtual or logical representations of physical machines, side by side on the same physical server. Many companies are putting strategies in place to consolidate servers and to reduce the cost of hardware, maintenance, power, and floor space. At my work we have a cluster of physical machines using VMWare that have allowed us to run 115 virtual servers on it. There is room for more and we will continue to move to that platform. Virtualization makes a lot of sense in the eyes of the system administrator.

So why is a software guy like me so excited about it? To me, it is much more then a way to control costs. It also allows us to be more agile, to react to capacity issues faster, deploy easier, and create faster applications. Allow me to expand on each one of these points. The following statements assume that you have a cluster of boxes with available capacity to add additional virtual machines.

Agile - How long does the procurement process take in your company? I have seen companies' server procurement cycles take from two weeks to six months. The norm in my world is about a month. A virtual machine can be created in 15-20 minutes without having to purchase anything.

React to capacity issues - On Friday at 10pm, your web site generates a ton of unexpected traffic which causes your servers to exceed their capacity and fail. Your systems administrator logs on from home and quickly adds five more virtual machines using a snapshot of an existing production virtual machine. In under an hour he has the system back up and running.

Deploy easier - Your application can be configured as a virtual appliance. This allows you to create a virtual machine that consists of the operating system and application software for all the tiers of your application and bundle it as a single file. Microsoft is leveraging this approach as a way to allow people to try out the latest version of Outlook without having to install hardware and software. Think about being able to deploy your multiple tier environment as a single file. Take that snap shot and deploy it at your DR site and you have knocked a huge chunk of time off your implementation phase.

Create faster applications - This is the topic that gave me the urge to write this post. Think about this architectural strategy for your web sites. Put all of your web servers, application servers, and database servers on virtual machines and create your virtual appliance. Since all of these virtual machines are on the same physical server, you could actually leverage the PCI bus instead of the Gigabit Ethernet. The PCI Bus is over 400 times faster then Gigabit Ethernet which should give you incredible response times for your application. What's even cooler, is that you can have your virtual web servers "sitting" outside the firewall in the DMZ while your application servers and database server is "sitting" inside the firewall. You read that right! Even though these virtual machines are physically installed on the same server, you can configure them to logically be located in different areas.

Think of all the possibilities. We all know the power of distributed systems. Distributed systems allow you to perform parallel processing across multiple nodes to achieve more work in shorter intervals. The downside of distributed systems is the cost of the physical servers and the management of software across the nodes. Enter virtualization. You can install several virtual machines at minimal cost and easily manage the software by updating one virtual machine and taking a snapshot. Then apply the snapshot to the other virtual machines.

To take that concept one step further, you can leverage this distributed model to create multiple virtual machines to act as an application server farm. If you are implementing an SOA and have an ESB in place, you can configure the ESB to load balance your services across these virtual machines to maximize your throughput.

The possibilities are endless. The point is that virtualization is more then just a great solution for consolidation and server management. Virtualization should be included as part of your application architecture strategy.

I stoled or as architects like to say, "reused" the title of this post from an interesting article in Computerworld by Steve Duplessie. The article starts out talking about how Web 2.0 will change our world and finishes with an example of a stupid business decision, hence the title, "You can't fix stupid". On the second page Steve has a point that gave me a reason to blog. Here is a quote from the article:

Free means crap, right? Wrong. How many of you keep Yahoo mail running on your BlackBerries along with Exchange because you know Exchange will be down sooner or later? When is the last time Google Mail was down? So my enterprise-caliber application running on an enterprise-caliber infrastructure with enterprise-caliber IT talent is less reliable than my free e-mail? Yep.

The "free means crap" perception is still shared by many people these days. Steve's email scenario is one of many real life examples that should help start putting this misguided perception to bed. I struggle to understand how smart people can refuse to at least investigate the possibility of leveraging Open Source software or Google Apps.

Many people are complaining about IT jobs moving offshore. One of the main reasons this is occurring is because IT is being asked to keep their annual budgets flat or even reduced year after year. This is extremely difficult to do when health insurance costs are going through the roof and the IT maintenance costs increase every year as we purchase additional products and services. The "easy" answer is cheap labor. Maybe it is time for an Open Source strategy. Look at how much money we are paying for Microsoft Office and Outlook. How much does it cost to purchase and maintain software like project management tools (project scheduling, portfolio management, requirements management, defect tracking, etc.)? Heck, their are even enterprise packages in the Open Source community for CRM, SOA, and BPM to name a few. Folks, there are alternatives out there that could save big bucks.

Does free mean crap? There are tons of quality free or inexpensive solutions in use by major corporations today. Let me ask you this. Does expensive mean good? Not necessarily.

I have written a couple of articles (here and here) recently about offshore development and how the success or failure of offshoring depends heavily on the US companies' ability to manage their offshore development partners. I may have come across as a strong supporter of offshore development, which was not my intent. My intent was to point out that if you are going to send work overseas you better have good processes and controls in place to manage it.

This takes me to my next point. I am a huge fan of agile development. One of the many things I like about agile development is that it does not require you to spend countless hours analyzing and documenting requirements and designs. Instead you cycle through many iterations of requirements, design, and prototypes with your key stakeholders and deliver functionality in small chunks.

Now lets look at the offshore model. Because of the communication barrier, the lack of business knowledge offshore, and often the limited experience level of the development team, the amount of documentation required to make this work increases immensely. Without the "war room" mentality of agile development, the projects tend to lean more towards a waterfall approach. Waterfall projects are rarely discussed in the same breath as "speed to market".

On my current BPM/SOA implementation, we have about a dozen projects that we wish to implement in the next 12 months. As we work with our SOA consulting partners (a US company with an offshore partner), we put together two different pricing models for our executive sponsor for each project. One price is for the most cost effective approach which leverages offshore development resources, and one is for the fastest to market approach which requires more on-site collaboration. So far the business has only chosen the speed to market solutions. Why is that you may ask? Well, all of these projects have a huge ROI if we replace our 20 year old business processes with new streamlined processes. Every day that we continue to do business with our legacy processes we are wasting valuable corporate dollars. For this reason, our sponsor is willing to pay a premium to get the work done quickly.

So if speed to market is your goal, agile development could be your answer. If you want to be agile and deliver functionality every 10 weeks or so, you must have great collaboration amongst your team and should not follow an extremely rigid methodology. In my opinion, this is when you should not rely on offshore development.

I came across this article in the WSJ where companies are testing job interviewing in the virtual world called Second Life. Huh? I thought this was another gaming environment where people could spend countless hours wasting their life away. So I Googled Second Life and looked for more business uses of this virtual world. There where way too many articles about virtual sex but I did find a few articles like this one about virtual classrooms in SL and this one where Dell set up Dell Island. As my research continued I stumbled across one grassroots initiative who started leveraging SL for streaming video of keynotes and allowed you to attend breakout sessions. Another article from Brandweek discusses marketers challenges as they try to use SL to promote brand awareness.

Perform this search and you can see countless businesses dabbling in SL ranging from recruiting, advertising, educating, collaborating, to countless other innovative ideas. Then I found this article that shows how the Weather Channel, IBM, and Cisco are leveraging SL to advertise and create brand awareness.

All of this is mind boggling to me. I can understand people using SL as a gaming environment. But for someone like myself who has a full time job, a family, and a life, how can you justify spending countless hours "conducting business" in a virtual world? As the head of the architecture team at my work, it is my job to learn about all emerging technologies. I am constantly studying topics like Web 2.0, Open Source, SOA, virtualization and best practices such as change management, project and portfolio management, and IT governance. I feel obligated to take a deeper dive into SL but after walking around SL aimlessly for 30 minutes I decided to let others do the research for now and I'll stick to reading articles on this topic for the near future. Besides, it is hard enough to get new initiatives going in the real world. I can't even imagine selling management on the virtual world!

I would love to hear from anyone who has some real experience using SL for business reasons.

Nick Malik has a great post on this topic. Here is how he defines the terms:

1. Top down - central group decides everything and the dev teams adopt them.
   
2. Bottom up - central group provides a directory and dev teams make whatever services they want. Dev teams go to the directory to find services they can use.
   

I am in the early stages of implementing a SOA. About five years ago we embarked on a project to create a component based architecture where we isolated the business rules as business components. Back then, we did not have a central group focusing on architecture. I was driving this initiative without the necessary authority to make it an enterprise solution. We successfully create a repository containing many reusable components. Another team bought in to the idea and started architecting their application in the same manner. In true Bottom Up fashion, they chose to create their own component library for their application specific business rules. They were able to reap some of the benefits of this approach but because we had no authority to govern this project we wound up with two separate repositories. This speaks to Nick Malik's warning that "Bottom Up SOA is harmful and should be discouraged".

Now, five years later, we do have a centralized architect group with the necessary authority to govern our SOA initiative. We will use a Top Down approach to ensure we don't relive the mistakes of our past. This works for us because we are a small shop (about 200 IT staffers). Development is done in three business units, two at corporate and one in Europe. Our approach is that the architect group controls our repository of objects and services. All teams can access the repository in read-only mode and submit candidates for consideration to be added to the library. If the artifacts meet our architectural standards then they will be added to the repository.

I believe Top Down SOA will work for us because of our size and because there is a limited amount of staff who have experience with SOA. If we were a large shop with several different groups actively working on SOA then this might be a major challenge. Bottom Up is a faster way to market but can lead to maintenance nightmares if any group thinks departmental instead of enterprise.

I would love to hear from those who have experience in either Top Down or Bottom Up SOA.