Enterprise Initiatives

I just posted my top 10 posts for 2007 and all of them were related to Linux and open source (thanks Digg!). But my real passion for writing is enterprise initiatives like SOA, BPM, Enterprise Architecture, Project and Portfolio Management, Outsourcing, and any initiative that requires a combination of leadership, technical knowledge, and people skills. So here is my top 10 posts for all non open source topics in 2007:

1. How did we become a Dilbert cartoon?
2. What does it all mean?
3. Selling SOA - a True Story
4. Top 5 Bone Head Moves
5. Outsourcing vs. Offshoring
6. Adobe Flex beats Silverlight every time
   
7. Zap Think's Who's Killing SOA
8. Another Benefit of SOA - Career Path
9. Why are you still generating reports?
10. SOA and BPM Consolidation

I would also like to list a few of my lesson learned posts because I believe these types of posts add the most value to the community.

1. SOA Lessons Learned
2. Lessons Learned from our first SOA implementation - part 1
   
3. Lessons Learned from our first SOA implementation - part 2

Happy Holidays!

I was looking back at my first year of blogging to see what my best posts were. For those of you who have read several of my posts you know that I have two favorite topics: open source and SOA. I started blogging in March of this year and have written 120 posts. The top 10 were all dominated by open source articles. The reason is simple, Windows vs. Linux is a hot topic on sites like Digg, Del.icio.us, and Reddit. There are a lot of flame wars out there and not a lot of facts. Most of my posts were related to real work experience with open source and a few were dedicated to an experiment I did at home with several Linux distributions. So for 2007, here are my top 10 posts:

1. Open Source and Microsoft Free (54,000 hits)
2. Comparing Linux Distributions - Final Results
   
3. Dumping Vista - a Divorce with a Happy Ending
4. Open Source and Loving it!
5. Linux Mint is....Mint!
6. Eating my own Dog Food
7. Another easy Linux Install, Kubuntu Style
8. Review of Linux Distributions - Part 2
9. 10 Reasons why you need an Open Source Strategy
10. Review of Linux Distributions - Part 1

The top post was a hot ticket on Digg, Slashdot, Craigslist, Stumble, Del.icio.ous, and every Linux website known to mankind. Even though I wrote it several months ago, it continues to get a lot of traffic. Obviously, I am a big advocate of Linux. I have been using Kubuntu at work at a Microsoft shop for most of the year now and have been very productive without a single piece of Microsoft software on my laptop. Linux is ready for primetime. People aren't ready for Linux.

There isn't a day that goes by were I don't encounter an EA blogger who states his dislike for process. Earlier in my career I was very anti-process. I was working on small teams and sometimes I was simply the only one on the team. There was no established architecture and no standards. Since this was the norm and nobody cared, why bother me with tons of documentation. As I moved through my career I worked on larger projects that spanned multiple user groups and application silos. Suddenly, the lack of process became a recipe for failure. Now I am working on enterprise BPM and SOA initiatives that touch the entire company and practically every application under the sun. Process and Governance are now critical success factors.

For those who don't like process, I can meet you half way. I believe in a lightweight process that supports agile development but not process that creates bureaucracy and results in 12-18 month projects that are doomed for failure. My current project requires more process then any project I have ever worked on before. In the past I would typically scoff at project charters, team structure documents, accountability matrices, and all of the non technical type of artifacts. But this project consists of a consulting partner, that is half on-site and half remote, multiple internal application teams working on integrating various legacy systems to the new business workflows, an offshore support organization who will take responsibility for the code once it is approved through UAT (user acceptance testing), and business representatives from multiple departments. In addition we are working towards 12 week deliverables where we work on multiple workflows concurrently that need to plug in together at the end. Try that without process. Are you kidding me? There are over 50 business and IT people involved, there has to be some order to the chaos.

The trick is to not create so much process that you stifle creativity and make technical decisions based on process instead of business need. At the same time we are new to SOA and must closely govern the architecture so we don't create a long term mess and not realize the benefits of EA and SOA. So does this make me a process weenie? I don't think so. I do know that our first attempt at this I blew off the charter, the structure, and the accountability matrix and that led to confusion towards the end of the project. Next time around we will invest a few days nailing those steps down to prevent chaos down the road. From that point on this stuff will be boiler plate material that will just need minor tweaks as we move from release to release.

I know James McGovern is going to beat me up on this for both the process stuff and the outsourcing. Outsourcing is a decision our company has made so my job is to make it work regardless of what I think about outsourcing. I can complain about it and allow us to fail or I can make it work. The more external people you have working on the project (especially remotely) and the more areas of the business your requirements span, the more process you need. I never thought I would be pro-process but when you are responsible for large initiatives with large budgets associated with it, you better deliver on time and on budget or you will be introduced to the exit interview process!

James always promotes people over process and I totally agree with him. However, the people must have the tools they need to do the job. One of the most important tools is clear direction and good communication. When you have 50 or so people on a project you need some process to supply these tools. I agree with James that CMM is overkill (unless you are sending a space shuttle to the moon), but there needs to be a compromise. So I'll lob this one back to my EA peers out there. I am sure some heated debate will follow. Your thoughts?

I read an interesting article from ITBusinessEdge's Lorraine Lawson today called Coping with Disruptive Technologies. She discusses some of the resistance to "Enterprise 2.0" technologies like wiki's and blogs and how the enterprise users are demanding more empowerment. Those people who resist these technologies and laugh at wikis need to first get out of their boxes before they can think outside the box.

As an architect, my job is to build for the future. To do this, I must not constrain myself with the present state. My philosophy has always been to start with a clean slate, remove all rules and constraints, and then think outside of the box. Once the vision is formed, then you can start looking at constraints and start chipping away at the vision until you form something that is attainable.

I am working on a BPM and SOA initiative which challenges us every day to forget about our years of legacy business processes and system constraints and build a future state that reduces costs, improves speed to market, increases efficiencies, and ultimately improves customer satisfaction. On the business side, there are huge opportunities to change the way we collaborate with our customers. On the IT side, this is a drastic shift in the way we approach software development. On both sides, we need to get out of our boxes to create our future state roadmap. Everybody is buying in to the reasons why we need to do this but many are struggling with the future state vision.

Most of the resistance is due to the inability to let go of how things are done today, the rest is fear of change. Today we were listening to requirements on how to deliver a particular business service. The requirements were extremely dynamic almost to the point where it required artificial intelligence to satisfy it. These requirements are all based on the manual way we meet the current business need with spreadsheets. Automating manual spreadsheet manipulation and archiving is probably not the best strategy. Unfortunately, the current business process is extremely hard to automate due to lack of standards and the emphasis on exceptions and customization. This process has evolved through 20 years of business and probably needs to be totally revamped. Everytime I mention this I am informed of the many constraints that prevent this from happening. I don't disagree with the arguments, but those arguments are based on the box that we live in today. To reengineer these processes we must leave our box and derive a solution without constraints. Once we have done that we can brainstorm the new processes and modify them until they satisfy the business needs. Without leaving our box, we will never be able to overcome the limitations of the existing processes and will struggle to accomplish any automation that can improve on our current manual processes.

On the IT side, there is concern for the new SOA governance processes, agile methodology, short delivery cycles, and the shift from text heavy artifacts to model/visual based artifacts. Most of the feedback is based on today's constraints. I totally agree with the concerns. If we constrain ourselves with these new processes the way we constrain ourselves with the old processes, we will fail. However, if we leave our box of constraints behind and think outside the box, we can be successful with the new processes.

As I look at the emerging technologies like Enterprise 2.0, BPM, SOA, and others, the companies that will take advantage of these will be the ones not living inside their box. It is time we started paying attention to social networking, software as a service (SAAS), mobile workforces, open source, and other technologies. It's time to get out of our boxes.

In the day and age of cheap disk, fast processors, high bandwidth, and cheap memory, companies are analyzing data more then ever before. As the components of the infrastructure become more cost effective and data is becoming more accessible, IT is being asked to create reports like never before. This is an area where IT can either be an enabler for the business or a serious bottleneck.

As partners to the business, we must educate our users on the power of business intelligence and self service. The business will typically ask for reports which is a reactive approach to solving problems. We need to offer proactive solutions that provide alerts and KPIs to address issues before they become critical. In other words, lets use information to optimize our business instead of creating more non-value add processes where countless clerks dig through hundred page printouts looking for issues. Here is my philosophy on reports. Static or canned reports should only be generated if the information is an output of the system. Here are some basic examples of when systems should create canned reports:

• Bills
• Invoices
• Purchase orders
• Confirmations
• Receipts

These reports are fairly static and should not change too often. When gathering requirements, the reports above would have been identified as outputs from the system. Notice that these are not really reports, they are outputs or artifacts of the system.

So what is the problem with reports? I have seen many applications that contain upwards of 70-100 reports over my years in IT. Usually, you could boil these down to half a dozen subject areas. Over time, different users come and go and they all have their own ideas on how they want data presented to them. So IT is asked to create more reports by adding a field here, grouping a field there, shrinking the font and printing landscape, and so on. All of these requests are a waste of money and a drain on IT resources. Often, these requests go into the black hole of the backlog of simple requests that IT can never find time to get to.

This is where business intelligence kicks in. IT should create metadata to represent the complex relationships of various databases and present the user with a simple view of data in business terms. Then through tools like Microstrategy, SAS, Cognos, Business Objects, etc. we should empower the users to create their own reports. Through self service, the users no longer have to wait months or even years for IT to get around to developing yet another report that must be maintained. The users can now react to business demands and can tailor the output to meet their needs.

This is a mindset that must be pushed from IT. When users ask for a report, the business analyst must ask the user, "What problem are you trying to solve?" I have seen all too often where the user wants a report as a quality check in response to issues found in the data. My response is to fix the root cause and eliminate the data quality issue as opposed to adding another non-value added process that may live on for years before someone realizes that the step is a waste of time.

So I ask, "Why are you still generating all of those reports?" If you follow the trends in IT you will notice that today's users are becoming more empowered then ever before. Users are leveraging various Web 2.0 technologies to service their needs and to build their own composite applications. We need to provide them with that same easy access to data. Don't give them reports, give them information!

There are many critical success factors for implementing SOA. They range from strong executive sponsorship and business alignment to acquiring the proper talent and implementing the right amount of governance. But even if you have all of those ducks in a row, it all comes down to the basics of project management and leadership. The biggest challenges that I see implementing SOA are the same challenges that I have seen throughout my career implementing any other large initiative. This article called Avoiding Project Failure: It's not Rocket Science, gives an overview of the things that typically go wrong:

Typical problems here are scope creep, poor work-plan, lack of change control, poor communication and poor management of risks and issues.

The article goes on to state a few more killers:

There are many occasions during the lifecycle of a project for issues that may lead to failure. Examples of these include:

• Failure to define the requirements clearly, resulting in expectations not being met
• Cutting edge or new technology that causes unforeseen problems
• A poor technical design preventing the solution from being changed or scaled in the future
• Poor change control allowing change requests to cause the project to drift
• Changing priorities diverting attention away from core work

Since implementing SOA can be a culture changing event, the basic change management principles must be applied to prevent derailing the entire initiative. Here is a summary of the high points of this article:

1. Address the human-side systematically
   
2. Top level support
3. Involve every layer
4. Clearly communicate the business case
5. Create ownership, install change agents
6. Clearly and continually communicate the message
7. Assess the cultural impacts
8. Address cultural issues
9. Prepare for the unexpected
10. Define WIIFM (What's in it for me?) for each individual

I know that early in my SOA initiative, I spent most of my time digging into the technology. Once we defined what our target architecture was going to be, my role changed dramatically. I turned most of my architecture duties over to my enterprise architects and started focusing my energy on the project deliverables and the change management. I can tell you from personal experience that figuring out the target architecture was a cakewalk compared to what I am dealing with now.

So while many people lose sleep over the technical challenges of SOA, I stay awake at night worrying about scope creep, top level support, cultural issues, risk lists, and action items. If I put enough smart people in a "war room" I know we can tackle any technology problem, but coordinating the work of all these people is where the challenge is. The big challenge in my eyes is that SOA forces many different departments (inside and outside of IT) to work together as one cohesive team. This is not a technology issue, it is a people issue. So for those of you early on in your quest for SOA, don't under estimate the importance of project management and change management.

I have been pushing wikis at work the last few months as I mentioned in a previous post called another wiki use case. Every time I mention the word to anyone outside of my architect team I either get blank stares or I get the rolling eyes followed by laughter. Today I even got a "I guess we'll see a blog about wikis" followed by laughter. What is so funny about Wiki anyways?

We are rolling out a new version of our brand new B2B portal in the near future. We were discussing online help and I recommended we use a wiki help system. We are currently creating another large user manual that nobody will ever read. We can take that manual, open it with OpenOffice Word 2.3 and export it to MediaWiki format. Then we can host it from an install of MediaWiki specifically for our B2B portal. Then from the Help function on the B2B portal we can link right to our wiki and just like that we have clickable online help at no additional cost.

Ok, I hear you laughing. Well if this is so funny then how come some of the most popular websites in the world have wiki-style help? They may be using more sophisticated technology like Adobe RoboHelp 7, but the look and feel is similar.
Here are a few screen shots of wiki-style help from some popular web sites.



So if wiki is not funny at Amazon, eBay, and Southwest, why is it so funny at my shop? I guess we need to get out more!

I have read a lot of articles recently claiming that BPM & SOA are nothing more then hype. I am here to tell you that if you align these technologies with the proper business case, you can transform your company. I am watching this transformation happen right before my very own eyes. We had an all day future state meeting today and the eighteen people from a cross function of the business were "building the new company from scratch". It was a great moment for me. Just over a year ago, IT sold the business on BPM and SOA. Last week we delivered our first implementation of a BPM/SOA enabled B2B portal. When we did our first round of process reengineering, the company was new to the concepts and skeptical of the investment in the technology. Now, one year later, we have a dedicated architecture team, a dedicated business process department residing in operations, BPM and SOA technology proven in a production environment, and BPM is one of the companies top five initiatives in our four year corporate strategy.

In today's future state sessions, there were eighteen highly motivated and deeply engaged people who believe in the vision and the technology. Our company is transforming from being reactive and heavily labor intensive to proactive and process oriented. We have extremely aggressive growth goals that our existing processes cannot sustain. By using BPM and SOA, we will totally reengineer the way we do business.

At the beginning of the session I explained how SOA will allow us to wipe the slate clean and build our new processes from scratch. I explained in business terms how SOA is the bridge between our brand new business processes and our legacy systems. In our current state findings meeting, there was a lot of concern about "blowing up" all of our systems. In order for us to not constrain our thinking, I thought it was important to start today by explaining that we do not need to touch our legacy systems, instead we simply "connect" them to our business processes with SOA. Below is a slide similar to the one I showed them:



The way I explained it was that in the past we had a separate UI for each one of the systems in the blue circles. Each UI looked different, had redundant data across the applications, and were disconnected from each other. In the new world, there will be one composite UI that is driven by our new business processes and "talks" to the legacy systems through adapters (really web services) while hiding the complexity of all the legacy systems. In other words, they no longer need to care about the order entry system, the accounts payable system, the inventory system, etc. Now they can focus on the process which is designed by the business in the BPM tool and IT can magically connect their processes to our existing systems with a minimal amount of effort (once we built the infrastructure).

Once they understood this, they started building our new company from scratch. It was almost like someone freed their minds and took the handcuffs off. At the end of the day, we had a vision of what our new world might look like and it looks good. No paper, portals, dashboards, workflow, alerts, KPIs, self service, real time data, electronic approvals, etc. That sure beats the sticky notes, emails, phone calls, reams of paper, and rows of filing cabinets. This is all possible because of BPM and SOA. So the next time someone who is afraid to change starts calling the hype card, send him/her this post. Better yet, have them email me. These technologies are the real deal!

I stumbled across a web 2.0 company today called MizPee and just shook my head. I can't make this stuff up.

MizPee finds the closest, cleanest toilets in your area. You can add and review toilets, get some cool deals in your area and challenge your knowledge of toilet trivia.

When I see useless sites like this and sites like Facebook being valued at $15B I start to remind myself of the .com and real estate bubbles of recent memory. Another red flag is when you start seeing hilarious videos about the bubble bursting like the one below.

IT driven SOA
Over the past year I have collaborated with literally hundreds of IT professionals about SOA either at conferences, through networking, via blogging, or in person. From what I have learned, most SOA initiatives are driven by IT and the biggest challenge is getting the business to buy into the technology. The advantages of IT driven SOA is IT can take a top down approach to SOA, build the governance in from the start, and gradually ramp up their staff's knowledge of SOA. The downside is the business may not want or understand SOA and all you wind up with is an exercise on "what could have been". In summary, IT-driven SOA gives you the opportunity to do it right, but you risk the business rejecting it.

Business driven SOA
Business-driven SOA has a completely different set of pros and cons. Business-driven SOA gives you the strong sponsorship and the business resources required to align the technology to the business. It also makes it easier to tie BPM to your SOA initiative which greatly increases the value of the project to your company. Not only can you make great improvements in time to market, reusability, and reduced maintenance, but you also get operational efficiencies in the business by reengineering business processes.

So what are the cons? First, the business doesn't understand or care about governance. Once you buy the SOA stack, the expectation is to start delivering ASAP. In these scenarios, IT is typically forced to attack SOA from a bottom up or middle out approach. The risk here is that over time, you may never fully achieve a true service oriented architecture if you don't bake in the governance at some point. You run the risk of building JABOWS (just a bunch of web services). In some business-driven projects that I have seen, IT does not fully support the initiative. This creates a lot of wasted energy for the architect team who has to constantly deal with negativity, resistance, and even personal attacks by those who fear change or don't believe in the value of SOA. In cases like this, IT is its own worst enemy.

Resistance to Change
So how do we overcome resistance to change? Robbins and Judge, two thought leaders in organizational behavior, describe 7 tactics for dealing with resistance:

1. Education and Communication - By constantly communicating, evangelizing, and training, resistance can be reduced by minimizing misinformation and rumors and can actually help in the selling process.
2. Participation - Getting people involved and giving them accountability makes it harder for them to resist change. If they are any good, they will quickly see the value in SOA.
3. Building Support and Commitment - You can't be everywhere all the time so you need change agents spread throughout. Their job is to evangelize the benefits of SOA and the value it will bring to the company. At the same time they must address any resistance immediately otherwise it will spread like cancer. The biggest reason for resistance is fear. The change agents need to find out what is causing the fear and communicate that to the person driving SOA so the fears can be addressed across the organization.
4. Negotiation - Sometimes people just don't believe in the vision and there is nothing you can do to change their mind. This is where you hear the cries, "That will never get done here". For these people you must identify what is in it for them. If they are non management, you can explain the potential career path benefits and point to reduction in production support and other monotonous chores. If they are on the network side you can point to centralized security, the value of the ESB, and many other things that appeal to the networking folks.
5. Manipulation and Cooptation - Steer far away from this one. This will destroy your integrity and will make you unable to deliver any project once this tactic is exposed.
6. Selecting people who accept change - This is key. There are enough people who will throw daggers at the project from outside. The last thing you need is someone inside fueling the fire. As I mentioned in a previous post, we look for motivated people who embrace change and buy into the vision.
7. Coercion - File this under unethical and see bullet 5 for consequences.

The higher up you have buy in, the easier it is to deal with resistance. If you don't have active support from the top, you can spend an enormous amount of energy fighting resistance. When I say active I am talking about participation. That means the IT leaders, even those who are not directly involved, must be actively involved in some form or fashion to show their support of the SOA initiatives. Even if the involvement is as little as inviting architects into team meetings to give updates. Any IT shop should be able to figure out the technical challenges of SOA. The hard part is dealing with people and change.

A couple of days ago I wrote part 1 of this series and highlighted the things we did that made us successful on our first SOA implementation. Today, I will discuss the things that we should have done differently. Before I start, I would like to note that we are working on six different projects concurrently under the parent program. So some of these "what not to do's" apply to all of these projects not just our initial one that we just rolled.

What not to do...

1. Not enough professional services - Our budgeting process only included enough hours to install the stack. We should have covered a few more weeks of professional services for when we first deployed code into the development and testing environments. About a month after we installed the BPMS and ESB, we deployed our first build on these environments. We encountered all kinds of environmental issues and various integration issues between the various components of the stack, especially the portal and BPMS. Since we didn't have budget for any more professional services we tried to figure it all out ourselves. Eventually we brought the vendor in and ate some incremental costs but we lost about a month which delayed the project.
   
2. Needed more vendor references - This is not for the selection criteria but for implementation. We should have sought out more companies that had been through an implementation using these products. We are networking with a few local companies now but it would have been nice to have heard their experiences earlier and we might have prevented some of the setbacks or resolved issues quicker.
   
3. Dove in too fast - This one we didn't have much control over. The downside of having the business fund SOA is that they want results immediately. We started our first project with no governance, no testing strategy, no automated build process, etc. We are trying to implement governance along the way but it always takes a back seat to due dates. Fortunately, a new budget starts in January and we can get the resources we need to get these important tasks done.
4. Threw the kitchen sink at the first iteration - I wrote a lessons learned piece a few weeks back which prompted Todd Biske to write a good article called SOA and the Kitchen Sink. We tried to do too many things currently and had a few instances where we were thrashing.
   
5. Not enough internal resources involved early enough - We partnered with a consulting firm to help teach us how to properly architect software in the new world of SOA. At the same time I have been working with the leadership team in IT and the business to free up more internal resources so we can start doing this ourselves. This has two bad side effects. First, very few of our own people were recipients of the knowledge transfer and two, the vendor does not know our business which has led to some gaps in requirements and some architectural decisions that were made that we have had to change.
   
6. Needed more change management - I did spend a lot of time focusing on communications & organization impacts but there was still a lot of "we vs. they", resistance, and confusion about the overall direction. The core team was has always been on the same page, but many spectators are still in the dark. This often leads to resistance and negatively which we deal with immediately, but it would be nice not to have to spend as much time resolving this issues.
   
7. Didn't research SOA testing enough - One of the things we did right was research the heck out of SOA and BPM. But one area that we didn't invest much time in was the testing. We are actively researching the heck out of it now but my advice to others is don't under estimate the changes required to test SOA.
   
8. Occasionally got away from project management best practices - We fell behind by a month because of numerous issues with our environments and some bugs in the stack products that the vendor had to patch. Once we resolved all of the issues we only had two weeks left to deliver our new B2B customer facing portal to our client. We threw everything we had at the remaining tasks but somehow forgot about some of the basics of project management like risk mitigation and we had several communication breakdowns. We coined it as "running around with our hair on fire". On the positive side, we all acknowledged our mistakes and are in the process of fixing this.
   
9. Taming requirements - Requirements have been too volatile and it is hard to be agile when you can't draw that line in the sand until the next iteration. With some of the business services, there does not appear to be enough ownership and accountability. This has caused a lot of rework and has been a big source of frustration.
   

If you read this article without reading part 1, it probably sounds like we failed miserably. In reality, we were highly successful. But with all of the issues I listed above, it was a lot harder then it should have been. Part of the challenge was that we were learning SOA, BPM, and agile on the fly while trying to meet highly aggressive dates. My goal here is to share my experiences, good and bad so others can learn from our success and mistakes as they prepare to take on their SOA implementation. Feel free to contact me if you ever want to discuss these experiences or offer suggestions.

I have been blogging about our BPM and SOA initiative all year long. Yesterday, we deployed our first application, a customer facing B2B portal that spans our sales order process. Although this is just the first iteration of many and we are still a few months away from delivering the features that will give us the big ROI, this was a major milestone for us. So I would like to take this opportunity to share a few things we did right. In part 2, I will discuss a few things I would do different next time.

Things we did right

1. Focused on business not technology - we performed a 90 day business process assessment where we documented current state, brain stormed on future state, and defined a portfolio of projects that each had their own ROI. This allowed us to sell the business on BPM and SOA and helped us secure the funds required to take on SOA.
   
2. We did our homework - We attended conferences, read blogs, researched web sites, collaborated with experience architects, and a got our hands on anything or anyone that had any information about SOA.
3. Thorough POC - We invested a lot of time in an extensive vendor assessment for both the BPM and SOA tools. When we narrowed it down to the short list of vendors we brought them each in for a full day proof of concept. I wrote a piece on CIO.com called the Proof is in the Pudding and another called Beware of Eye Candy that talks about some of the scary things you might find when you start going beyond the Power Point slides and start actually trying to execute processes and services.
4. Surrounded ourselves with talent - We put several of our best people on this project on both the IT and business side. Not only did we look for talent, but we looked for motivated people who embrace change and bought into the vision. We also partnered with an implementation company with years of SOA experience including working on some of the largest SOA implementations in the world. We embedded our architects with our SOA partners to accelerate the learning curve.
   
5. Strong executive support - Our executive sponsor is from the business and the person who went to the top to get the funding for the project. Like a couple of us in IT, she put her career on the line by signing up to deliver substantial ROI numbers over the next four years. You can bet that we have all the support we need. Recently, the CEO declared this one of the key initiatives over the next four years so now the whole company is behind this.
6. Squash resistance instantly - Any time we encountered or were told of resistance or negativity, we immediately addressed it head on. Some of these occurrences turned out to be great learning opportunities while others were the result of lack of buy in. In each case, we tried to understand the root cause and resolve the issue before it spread like a fungus.
7. Short, iterative deliverables - Many companies get themselves into trouble by trying to tackle too much out of the gates. We took a look at all of the projects that we identified and used a combination of portfolio management and a SOA roadmap to determine the priority and size of the scope for each project. By laying out the long term vision, we were able to prioritize which services to build first to maximize reuse and reduce the overall cost of deployment.
8. Sound architecture - We are laying the foundation for a loosely coupled, service enabled architecture that will give us a platform to quickly react to change. We are leveraging both Portal and BPM technology to create new tools that empower our users with self service capabilities, visibility into the workflow, and access to KPIs through Business Activity Monitoring (BAM). We are also leveraging SOA to connect this new front end to our years of legacy systems while hiding the complexity from the users.
9. Having Fun - We are all under intense pressure to deliver the numbers we promised in aggressive time frames. The work is challenging and we had a few "coming to Jesus" meetings along the way, but overall all we are extremely excited and focused on future successes. At the same time we are enjoying being part of an initiative that will transform the company.
   

I know this sounds like a bed of roses but this success has not come easy. In my next post I will describe some of the things that occurred that we will may sure never happen again. The list is as long as the one above.

One of the most popular discussions in the blogosphere is the topic of how Linux is posed to start taking market share from Microsoft in the battle of the desktops. What I don't see being discussed too much anymore is how dominating Linux is becoming in the middle tier and backend server space. Not only has Linux been killing Windows in this area but it is also killing mainframes, Unix, and is a favorite choice for grid computing.

Grid computing is an area where Linux makes the most sense to me. Companies like Google and Paypal are clustering thousands of cheap nodes or blades without having to pay a few hundred bucks per node or processor in operating system licensing fees. These companies are also taking advantage of the available source code and making tweaks to customize performance and security to meet their needs. Check out this article about how Paypal leveraged 4000 Linux nodes running RedHat and eliminated the need for an expensive mainframe. Here is a key quote from this article...

In a mainframe environment, the cost to increase capacity a planned 15% or 20% "is enormous. It could be in the tens of millions to do a step increase. In [PayPal's] world, we add hundreds of servers in the course of a couple of nights and the cost is in the thousands, not millions.

I can personally speak to a real life business case for Linux. About eight years ago I worked on a project that had incredible data processing requirements. At that time, the only database technology that existed in the market place that even had the potential to meet our performance requirements was Teradata. They gave us a quote of $34M for the solution which was comprised of proprietary hardware and software. Back then, our entire IT budget was less then $34M. So we built our own solution which ran on a cluster of servers running Red Hat Linux for $100K. Throw in our labor and other fees and we spent close to $1M. What is more amazing is that we did not add a single employee to the staff to run the system since the system is self monitoring and self healing. With the Taradata solution we would have had to add DBA resources. This system is still running today and provides services for a product that generates over $100M a year.

I also stumbled across another article where IT shops are moving off of Unix to Linux for cost savings. A key take away from this article is this quote...

Linux is the best-engineered, most interoperable platform for enterprise computing and is becoming the clear choice for organisations.

So we can debate all day whether Linux is the real deal on the desktop, but in the server world, Linux is king. The irony to me is eight years ago when I was proposing Linux servers (before Linux was cool!), I was getting the same push back and resentment that Linux on the desktop is receiving today. I am sure that three or four years from now I can dig out this post and joke about how people used to fight Linux on the desktop.

Over the last 18-24 months I have researched and taken on a number of Enterprise Initiatives such as Enterprise Architecture, BPM, SOA, and agile development to name a few. As I researched each topic I found tons of articles recommending to steer far away from each initiative. The common theme is that it is expensive, too hard to do, and most initiatives fall. Today I was researching Enterprise Metadata and many of the search results pointed towards doom and failure.

Why is there so much failure with these all important initiatives? I did some research and found that a large amount of normal projects fail at equally high rates. The enterprise initiatives are just more visible and usually require a significant upfront investment. So what are the common reasons for failed projects? An article at Gantthead.com provides the following list:

• Inadequately trained and/or inexperienced project managers
• Failure to set and manage expectations
• Poor leadership at any and all levels
• Failure to adequately identify, document and track requirements
• Poor plans and planning processes
• Poor effort estimation
• Cultural and ethical misalignment
• Misalignment between the project team and the business or other organization it serves
• Inadequate or misused methods
• Inadequate communication, including progress tracking and reporting

For enterprise initiatives I would add these:

• Lack of strong executive sponsorship
  
• Unrealistic scope ("boiling the ocean")
  
• Lack of governance
  

So the next time you start researching a large IT initiative and you see all the negative publicity about your chances of success, ask yourself these questions:

1. Do we have the leadership required to take on this project?
2. Do we have enough change agents to change our culture?
3. Will we be able to get enough funding to adequately meet our objectives?
4. Will we get the support from the executives and/or the business?

If the answer to any of these questions is "no", then you might want to listen to the warnings from the articles. If the answers to all of these are "yes", then it all comes down to how good of a plan you put together and how well you execute the plan. Don't be risk adverse and let fear get in the way.

Many people are still in denial that Linux is a viable alternative to Windows on the desktop. I have written numerous posts of my experiments with several Linux distributions and my dumping of Vista. In yet another post, I talked about my plans to switch my parents over to Linux.

The next experiment will be my parents. I still have to reset the clock on their VCR every time I go to their house. All they do is read email, surf a few web sites, and play Spades and Mahjong.

Well, that day has come. YiaYia is Greek for grandmother, and YiaYia loves Linux. My parents have an old Dell 4300 with 256MB of RAM. They boot this box and basically leave the room for 15-20 minutes as it struggles to come to life. Even when it does come up it is sluggish and choppy when viewing rich media content. Every time I go to their house I run various tuning and spyware applications with limited impact. My folks where getting ready to buy a brand new PC which would have been a total waste of money for the limited resources that their usage requires. So I convinced them to give Linux a try before they spent their retirement money on a box with enough horsepower to run Vista.

Enter PCLinuxOS. I installed PCLOS in between commercials of the Giants-Lions game on Sunday. My parents are long time AOL users and were still living on the nasty AOL thick client software. I showed them that they can have all of the same functionality on aol.com using Firefox which includes their email. They were able to boot their old clunker PC with PCLOS and get to their AOL mail account in about 3 minutes. The box is humming now and they are extremely happy.

I brought my external hard drive and loaded their PC up with Greek Music and a Live Yanni concert (hey, we're Greek!). Without installing a single additional package, they were able to simply double click on the Yanni video and the video started playing on MPlayer. Then I brought up the music player (I can't remember exactly which tool this was) and it built a music catalog from the files I copied to the disk drive. I set it up to run in random and started the player. PCLOS did a great job of recognizing all of the drivers on this machine out of the box! At that point I think my parents mentioned something about all of those college tuition bills paying off.

I had to leave after the football game and didn't get a chance to finish. Over Thanksgiving I will get my Dad's Hoyle Games and my Mom's Mahjong running under Wine and they will be good to go. My folks are extremely challenged with computers. They don't understand most computer concepts and can only do simple things that require clicking a mouse. They are able to do everything on Linux that they could do on Windows. Without spending a dime, their old PC is now as good as new. The only complaint I heard was my Dad's concern for his Microsoft stock. And to make a good day better, my Giants won.

Last weekend I posted an article called Comparing Linux Distributions where I reviewed eight different Linux distributions on five different machines. I had used the freshly released Beta version of Linux Mint and kept getting read errors on the disk. This weekend I downloaded the real version of Mint 4.0 and was able to install it on my Dell Dimension 4300S. The install was a piece of cake. Mint uses the same 6 step install process that Kubuntu uses. See slideshow for screen shots.




The interface is as refreshing as its name and adding additional software packages is as easy to do as installing software on Windows. In addition to the various package managers that are available, Mint offers the Software Portal. This is a web site for Mint users that allows you to select and install packages just like Windows. Here are some screen shots of the easiest Wine install that I have ever done.

From Linux Mint

From Linux Mint

I was going to include various other screen shots but I stumbled across this post which beat me to it. You can see from this post that updating software and configuring the desktop are about as easy as it gets.

I also installed gOS on an old laptop to give it a spin. It installed easy and has a unique interface that brings all of the Google apps and various social networking tools to the task bar. It was nice, but I quickly got tired of it. This OS is for Linux noobs like Freespire is. If you are comfortable with Linux you probably want to pass on gOS. This is the OS that is shipping on the $200 PCs at Walmart.

And finally, some of my readers asked that I try Suse on one of my 32 bit machines since I couldn't get it to work on the 64 bit laptop. So I downloaded the 32 bit version and tried it on a couple of machines. Unfortunately, I got the same result. It fails when it tries to repartition the disk. I guess I could have used a tool like gParted first and then run Suse, but that defeats the purpose of my experiment. I am looking to see which distro installs the easiest.

One last note, Mepis is still the only distro I tested that was able to connect via wireless on my Dell Inspiron 1721 (AMD Athlon 64x2 Dual-Core TK-53, 1 GB RAM, 64 bit). Only Mepis, Kubuntu, and PCLinuxOS was able to install on it. The others, including Mint all failed on this laptop. On the 32 bit machines, every distro except Suse worked for me. So now my network now consists of 1 Vista, 1 XP, 2 Mepis, 1 Kubuntu, and 1 Mint. I am keeping Vista around to see what Service Pack 1 will do. Besides, struggling with Vista gives me a lot to blog about!

Zapthink posted an interesting description of a role they call VP of SOA. Todd Biske argued that many of the tasks in this role belong to the Chief Architect and a dedicated role of VP of SOA is unjustified. My view is somewhere in between. As someone trying to fulfill both the role of the Chief Architect and the role Zapthink describes as the VP of SOA, I can honestly say that this can be a lot to juggle. I have fallen victim to becoming so engaged in the VP of SOA role that at times I am not totally fulfilling my duties as the Chief Architect. After all, the Chief Architect is responsible for the architecture of the entire enterprise, which SOA is a subset of. My solution is not to create another high paying role like the VP of SOA but instead give my enterprise architects more responsibility and decision making power to free me up enough to take on SOA and EA. This creates a cascading effect where the tech leads then need to step up to the plate and take on some of the enterprise architects' tasks. This creates opportunities for many people as opposed to one highly paid guru and allows you to build a stronger team over time.

I work in a 200 person IT shop so creating VP positions is harder to come by then if I worked in a 1200 person IT shop. In a larger company, especially one with a distributed IT staff, I can definitely see the justification for a VP of SOA. In a centralized IT shop like the one I work in, I think the VP of SOA and the Chief Architect should be the same person. Your thoughts?

I have been experimenting with many different Linux distributions over the last month as I posted here and here. In my review of the various distributions, I was looking for ease of install and ease of use as the most important factors in my personal ranking system. I believe for Linux to win the desktop war over the next few years they have to appeal to more then just the technical folks who can install distros in their sleep and are wizards at the command line. With that said, here are the distributions I tested:


Distros - 32 Bit

• Mepis 6.5.02
• Ubuntu Fiesty Fawn
• Kubuntu Gutsy Gibbon
• Freespire 2.0.6
• Fedora 8

Distros - 64 bit

• Mepis 6.5.02
• Kubuntu Gutsy Gibbon
• PCLinuxOS 2007
• Open Suse 10.3
• Linux Mint 4.0 Beta

Disclaimer: I am not an expert at administering desktop software (Windows or Linux). I am very familiar with Unix and Linux operating systems from a software development point of view, but not from an admin point of view. I know enough to be dangerous!

PCs & Laptops used:

• Laptops
• IBM Thinkpad, Intel 1.86 GHz, 1.5 GB RAM, 32 Bit
• Dell Inspiron ME051, Intel Celeron 1.4 GHz, 500 MB RAM, 32 Bit
  
• Dell Inspiron 1721, AMD Athlon 64x2 Dual-Core TK-53, 1 GB RAM, 64 Bit
  
• PCs
  
• Dell Dimension 4300S, Intel 1.70 GHz, 256 MB RAM, 32 Bit
• Dell Dimension 4700, Intel Pentium4 3.00 GHz, 1 GB RAM, 32 Bit

Overall Observation

• In general, Linux is very easy to install these days. All distributions have come a long way over the years and no longer requires an experienced administrator to install it.

• 32-Bit - All distros except Fedora 8 installed easily and worked flawlessly. They also all found my wireless network. Kubuntu Gutsy Gibbon was my favorite by far on a 32-bit archtiecture.
  

• 64-Bit - Mepis had the best driver detection for the newer hardware. Only Mepis could connect to my wireless network without manual intervention. Mepis 6.5.02 was my favorite on a 64-bit architecture due to it's excellent ability to detect newer hardware.
  

• Best out of the box packages - Kubuntu came installed with Wine (let's you run Windows software on Linux), Adept, and the KDE interface. Kubuntu also comes preinstalled with a nice UI for Wine which made it simple to install Windows programs. I had some issues manually installing Wine on Mepis which are still unresolved to date.

• Flat out didn't work - OpenSuse 10.3 would not install on the 64-bit laptop. Linux Mint kept giving me disk errors. I downloaded it twice and burned the CD at different speeds. I will try again later because I hear so many good things about Mint. Fedora only worked on one machine. It was getting different error messages on different machines.

• Honorable Mention - PCLinuxOS has a great user friendly install process and a nice interface. If it would have connected to my wireless network on the 64-bit laptop I would have ranked it above Mepis due to ease of use.
  

• Not for Geeks - Freespire was definitely targeting Linux newbies. It is made for people who have never ventured away from Windows. I used it at work for about 2 weeks and I got so annoyed with the interface that I quickly moved to Mepis.

• Linux at work - As I wrote in the past, I have used Ubuntu at work since April of this year. It has been flawless. I tried Freespire for two weeks and then moved to Mepis. Mepis had some issues with my monitor and wasn't able to work on an overhead projector. I am now on Kubuntu for the last two weeks and it has been working great.
  

Summary

All of these distros except OpenSuse (couldn't load) are great options for those wanting to move to Linux (I will try Mint again later). For those who are more experienced with administering Linux desktops, you may have come to different conclusions. I did spend a lot of time with most distros performing command line magic to make some things work (especially on the 64-bit environment). Kubuntu and Ubuntu were the only distros where I just installed and went on my way. All others required some amount of tweaking.

I had the luxury of owning several different machines and some time to experiment with the different Linux distributions. Each distribution that I was able to get up and running ran well. I was able to make use out of some old machines that were running poorly on XP. Most importantly, my new laptop that was running Vista very slowly is now cruising with Mepis.

By no means was this a highly scientific experiment. This is the view from a technical guy with limited systems administration skills. Take it for what it's worth. My recommendation is Kubuntu and Mepis.

As an employee of a small-to-medium sized business (SMB), I find myself constantly questioning how proprietary software vendors are going to be able to compete with Open Source Software in the SMB space over the next few years. I am in the middle of a full blown SOA and BPM initiative. We have spent a few bucks on the SOA stack from a major vendor betting on the fact that there was a lot of value in an integrated stack. The reality is that the big vendors are buying pure play vendors to complete their suite of SOA tools and these products are still 12-18 months away from being fully integrated. In other words, the integration is not there yet.

We are now looking at tools in the areas of SOA Governance, SOA Testing, and registries and repositories. The cost of procuring commercial software products for these tools exceeds the cost of the entire SOA stack (BPM, ESB, and Data Services)! It was hard enough to get the funding to purchase the stack. It will be even harder to get the funds for tools such as these that are transparent to the users. IT must fund these tools. Of course, most SMB IT shops are working on limited budgets that are flat or modestly increased year after year. Salaries and rising health insurance costs eat up the budget and IT must find creative ways to make up the difference. Spending a ton of money on governance tools is not my idea of creative cost reduction.

We have been evaluating several vendor solutions recently. These tools are built with features to satisfy every customer possible. SMB's do not have the resources that can be dedicated to these tools to take advantage of even 50% of the features. In my case, the team that would administer these tools are already responsible for many other tools. What this equates to is paying big bucks for rich features that I can't use. It's like buying an RV for a 5 mile commute to work.

Then there are the open source solutions. There are several viable options like Centrasite for the registry/repository which provides most of the necessary features that we need. For those few features that are lacking we can pay a small fee for the enterprise addition or just add the features to the code ourselves. SOA is just one area where I see SMB's favoring Open Source Software over the big proprietary vendors. Portal, Content Management (ECM), ERP, and CRM are other examples. Like SOA, ERP, CRM, and ECM software is typically way too expensive for SMB's. Open Source allows companies with smaller budgets to take advantage of these technologies. Many people who are anti open source or who just haven't been keeping up with how far Open Source Software has come over the past few years will question the robustness of the feature set, the integration, the support, and the quality of the software. Let me addres each issue one at a time:

1. Feature set - As I stated above, SMB's typically don't need or don't have the resources to even use many of the features in the big vendor enterprise packages. Out of necessity, most SMB's need to keep things simple and manageable and use only what makes sense.
   
2. Integration - I laugh when big vendors raise flags about Open Source and integration. The big vendors' products have so many integration issues amongst their own products because half of their products are the result of pure play purchases. They usually have to bring in sales people from four or five different divisions (former pure play companies) just to answer your basic questions.
   
3. Support - Nothing is more frustrating then paying 20% of the purchase price for maintenance annually to have some college kid from India search a knowledge base article on the web in an attempt to solve your support problems. Even when you get your case escalated to people who actually know the product, SMB's rarely get the necessary priority because the vendors cater to their billion dollar customers. SMB's typically can't afford platinum level support which gets you immediate attention when you have issues. My experience with Open Source support has been extremely responsive. There are also Open Source Service Providers whose core competency is support.
   
4. Quality - This is the myth of myths. How can you beat the global peer review process in the world of Open Source? You literally have hundreds of sets of eyes reviewing and testing code. My colleague Eric Roch will say that commercial software is in the state of "Perpetual Beta". The vendors are in such a rush to get a leg up on the competition that they are sacrificing quality for release dates. I see this with SOA where vendors are pushing product out the door too fast to the extent where I feel like a beta tester instead of a paying customer.

In addition to all of this, you have mass consolidation going on in the industry. Oracle, HP, IBM, and Microsoft continue to gobble up their competition. They then try to sell you a suite of very disjointed and overlapping products. At the same time they are rapidly trying to integrate their new products into a common platform. At the end of the day you have a lot of very expensive technologies that are fragile, complicated, and redundant.

Another advantage of Open Source software is you can try before you buy. I can start using a light weight registry/repository and learn what features are really important to me. This could be a better plan then buying the full blown feature rich six-figure proprietary solution only to find out that I only need 25% of the features.

For those of you with billion dollar budgets, all of this may seem like nonsense. For those of us who have to find creative ways to move IT forward within the constraints of modest budgets, investing in Open Source Software is a great way to stay competitive and deliver modern technology to support your business's goals and objectives.

I was reading various blog posts with my Google Reader today and came across a few articles that are riding the excitement of Web 2.0 and appending the "2.0" nomenclature to their subject matter to attract attention. Don't get me wrong, I am a big fan of Web 2.0 and the direction the web is going, but the 2.0 thing has got to go. Here are a few examples of what littered my feed reader today:

• Governance 2.0 - I think governance is on about 84.0 by now.
• Enterprise 2.0 - Fancy name for Web 2.0 at work, call it what it is!
• Sales 2.0 - Sales people using Web 2.0 tools, I feel the nausea kicking in now.
• CRM 2.0 - Mercy!

How many 2.0's can there be? So off to Google I went and searched 2.0. Here are some of the ones I stumbled across:

• Where 2.0 - Location awareness technology; O'Reilly trying to coin another 2.0.
• Business 2.0 - About as creative as Rocky V.
• Television 2.0 - Another reason why I only watch Sports Center.
• Product Development 2.0 - Stop the madness already.
  

But all is not lost. I did find one 2.0 link that I think has merit. Check out this technology to see what I mean!

We are in the process of defining and implementing our SOA governance processes. We are a medium size company so having armies of process cops is not an option, not to mention totally undesirable. At the same time, we need some level of process to ensure that we architect business services in a consistent manner and that we design for the enterprise as opposed to the old application silo approach. To make governance even more challenging, we want to deploy in cycles of 12 weeks or less. So how can we be agile and enforce SOA governance at the same time?

One way is to shift from text heavy documentation to visual documentation. In other words, stop generating hundred page Word documents and start creating UML models, business process models using BPMN, use case diagrams, and architecture diagrams. These artifacts are like blue prints for a building architect. If you were building your dream house would you type up the specs for your house in a Word document and hand it to your builder or would you give him blue prints?

Another way to stay agile and still enforce governance is to tightly control scope and requirements. Users are used to asking for the sun and the moon because they typically have to wait several months to get the next release. It is similar to the way politicians load up a bill with pet projects because they know it might be their only chance to get their stuff done. We must train the user community that in an agile approach, we will deploy more frequently and in shorter time spans. This means that you don't need to get every last requirement jammed into the project because another release is coming on the heals of the current release.

But the most critical way to stay agile while having a solid governance model in place is to use processes where it makes sense. Focus on artifacts that mean something to those who have to develop software. Don't focus on documents that are never used once they get signed off. One of my favorites is the team structure document. I have seen teams waste days creating a document that nobody other then the PM uses that describes all the roles, who the team members are, what their contact info is, how meetings will be held, when they will be held, and so on. Who cares? The PM needs to know this but why waste the rest of the teams time with reviewing this stuff. I can look up people's information on the portal faster then I can even find this document. Over the years I have seen teams create documents for the sake of satisfying a check list. This is a total waste of time. SOA Governance is all about managing services and the service life cycle. SOA governance can plug into your existing methodology (if you so desire). Focus on the processes that add value and discard everything else.

For small and medium sized businesses, we must be careful not to get bogged down in process. Unlike large enterprises, we don't have the luxury of dedicating several full time employees to enforcing processes and procedures. Instead, we must put a solid framework in place and rely on our people to enforce the necessary processes. Setting up a SOA Center of Excellence and an IT Steering committee under the watchful eye of a strong executive sponsor (CIO, Chief Architect, etc.) is one way to approach it.

There is no silver bullet here. Each company must decide for themselves how much process to put in place. If they put too much process in place, they can get bogged down and never meet expectations. If they don't implement enough process, then they will eventually spiral into mass chaos and won't realize the benefits of SOA like reuse, reduced maintenance costs, and increased flexibility.

I was in a strategy meeting last week when our HR representative asked me what the value of Architecture was. Being non technical, he was struggling to understand why we needed an architecture team. My first response was, "Did you just get out of a budget cut meeting?" I was joking but in the back of my mind I couldn't help wonder how many non technical executives were thinking the same. So I set out to write a post about the value of architecture. David Linthicum just posted a timely article called Why Enterprise Architecture is a Corporate Responsibility. In the article he talks about compliance, the need to adapt to business change rapidly, and the need to keep up with competitors who are becoming more agile. At the end of the article there was a great paragraph that I'll call out here...

Thus, without good architectural governance and ongoing corporate management pressure to redirect resources to tactical IT projects, the enterprise architectures continue to become more unnecessarily complex, static, and fragile. What was a mere annoyance only a few years ago, is today a clearly limiting factor in the businesses' ability to create shareholder value. The company can't easily shift into new and emerging markets, acquire companies, and adjust major business processes without a great deal of latency. In some cases, they are completely unable to change. In other words, things are bad and getting worse.

I agree with David on this point. For years, many IT shops ignored the need for EA because it was hard to do, required consistent processes, and cost a good chunk of change to implement. So we built stovepipe application after stovepipe application with no consistency and no integration between systems. We got away with this approach for a number of years but eventually reached the point of diminishing returns. Now with years of developing software with no standards, no consistency, and with no vision, many IT shops have become serious bottlenecks that prevent their companies from quickly jumping on new opportunities and have become a very expensive cost center. Time spent on maintenance and production support keeps increasing and new projects take too long to build. Instead of putting a focus on architecture, many companies look to outsourcing as the answer. If you can't do it right here, good luck doing it right there!

So here is my answer to my HR colleague's question about the value of architecture. Today's business environment is all about speed to market, cost reduction, business optimization and reengineering, and alignment. A good enterprise architecture can help a company meet these objectives. Throw in SOA, and you can meet these objectives while leveraging your years worth of investments in your legacy applications. So what are the advantages of EA?

• Business Alignment - Aligning technology with business opportunities and corporate vision allows IT to create value for the business as opposed to being just a cost center. Knowing where the business is going allows IT to be proactive and implement the right technologies to enable the business to meet its goals.
  
• Reduced maintenance costs - Consistent approach to software development makes it easier to build, test, and maintain. Resource allocation and utilization becomes more cost effective when you can move people across applications. Building consistent software and interfaces makes it easier to leverage your talent pool.
  
• Better control of assets - Planning and roadmaps allow IT to focus on the right resources on the right projects while using the right technologies. Put together plans to retire older technologies that are expensive to maintain and procure new technologies that map up to business objectives.
  
• Speed to market - Once established, EA allows IT to improve delivery cycles through reuse. Of course, this requires IT folks to not get too hung up on frameworks and rely more on people and agile best practices.
  
• Extending the enterprise - Today's demands require IT to connect to customers, partners, and suppliers. Architecting a secure platform for integrating with external entities can be a huge competitive advantage. Doing it wrong can be a disaster.

As David states in his article, as more companies invest in EA and SOA, those companies who choose to continue to build software the old way will struggle to compete. These companies will continue to prove Nick Carr correct when he says "IT does not matter". So for those still sitting on the sidelines because they don't want to invest the time and money that is required to establish an EA, you can pay now or pay big later.