Enterprise Initiatives

I just read Dave Linthicum's post on SOA World titled Should you Fire your CIO? This is a continuation of a discussion that has been brewing in the blogsphere for the past few months that started after the Burton Group commented that a new CIO was often a key ingredient for some successful SOA implementations.

To successfully implement enterprise wide SOA initiatives, strong leadership is required at the top of IT. The person must have integrity, creditability, technical and business know how, and must be able to lead the organization through the resulting shifts in cultural values. The problem is, as Dave points out in his article....

....in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change.

I call this the old "Keeping the Lights on Mentality". When IT stops being an enabler and simply acts as a cost center or a "necessary evil", then entertaining new projects that leverage one of Gartner Top 10 strategic technologies is unrealistic and doomed for failure or hardship at a minimum. Why? Because this mentality is reactive and sometimes even defensive. This mentality also does not encourage investing in the future whether that is in training employees, establishing and investing in architecture, or addressing problems with long term solutions. Instead, people are rewarded for quick fix fire fighting heroics and at the end of the day it is the user community that suffers. The users get band-aids on top of already outdated systems and are often forced to work in ways in which the technology and systems dictate, instead of the other way around.

It gets worse for the employees in an IT department in charge of "keeping the lights on". Their resumes become stale as their skills are not updated to reflect the newer technologies that innovative companies seek. The reactive nature of the culture can squash innovation and people who have valid solutions may not bring them forward because it would require more than a quick fix. In the end these types of shops become like an assembly line in nature where people clock in, work their shift, and clock out. This is not what must of us envisioned when we enthusiastically enrolled in IT related curriculums in college back in the day.

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So to answer Dave's question, if the business wants IT to help the business achieve its mission by being proactive and innovative and IT is simply keeping the lights on, the answer to his question might be yes. If the business simply needs a low cost IT cost center, the answer may be to evaluate the outsourcing model. Keeping the lights on as a core IT function and doing it at a high cost is just not good business. That's my 2 cents.

Disclaimer: In no way is this article referring to or targeting any organization or individual that I have been associated with in my career. This is a generalized view that combines my own experiences with the experiences of thousands of other IT professionals that I have talked to, read about, or researched throughout my 20+ years in IT.

Packt Publishing recently asked me to review a copy of Michael Havey's new book, SOA Cookbook. I finished the book yesterday and really enjoyed reading it. This book is made for technical folks, so non-technical managers and drag-n-drop programmers should not waste their time. Michael Havey takes a really neat approach in this book to assist architects and developers to understand the concepts of SOA and process modeling. In each of the nine chapters, Michael discusses pertinent patterns, use cases, or disputes and then offers very clear and easy to understand examples of what the resulting models would look like. He also goes one step further and shows specific examples within each of the following vendor stacks (IBM, BEA, Oracle, and Tibco). I find this extremely helpful for technicians who are modeling processes in an SOA for the very first time. He even provides a URL
to download the sample code.

One of the most important points in this book and one that I totally agree with is that the typical three layer SOA stack that most vendors offer is "unmistakenly process oriented. There are processes at each layer". This is obvious in the BPM layer. Michael goes on to discuss how ESB processes are single-burst stateless processes and how orchestration processes are both stateless and stateful. So why is this important? Michael states that "it is easier for developers to model a service as a process than to code it explicitly in a third-generation language". Another important point is that since SOA is a business driven architecture and business analysts and business people are more comfortable looking at use cases and process models, technicians need to start thinking in these same terms. After all, "Bad processes mean bad SOA" as Michael concludes.

The remainder of the book dives into topics such as design decisions on whether a process belongs in the BPM layer or within the lower SOA layers, modeling using BPMN & BPEL, design decisions for both short & long-running processes, using the "Flat-Form" method of modeling processes, dealing with dynamic processes, Simulating SOA, and concluding with measuring SOA complexity.

Some key points worthy of mentioning:

• A very worthy discussion of simulating SOA performance takes place in chapter 8. Michael recommends that simulation occurs before a line of code is written. When this does not take place it raises the risk of performance surprises in the production environment which may or may not occur right away. When these issues occur in production, resolving it becomes extremely expensive and can have catastrophic impacts.
  

• The Flat-Form method of modeling processes is a must read. I won't spill the beans here but the methods intent is to flatten the process models to improve maintainability and simplicity. Great stuff!

Overall, I really enjoyed the book. I have read a ton of books on SOA and most of them are high level discussions on what SOA is and how to get started. This book picks up after those discussions and is a great tool for architects and developers who have to actually build and deliver SOA. I highly recommend it! I also recommend that your testing lead reads the book as well. If you don't have a tester who understands the content of the book, you better get one!

Next up is my colleague Todd Biske's SOA Governance book which I will finish reading this weekend!

I have discussed the SOA Evangelist, the Architects, and the Developers. Today I will discuss the role of the Testers and the characteristics required to contribute to a successful SOA implementation.

One of the most important roles and one that I probably should have included in the Architects post is the Testing Architect. As I have written on CIO.com in my article called Six Questions to Consider Before Building a SOA Testing Team, SOA testing requires a much deeper knowledge of technical skills, including development skills. It might be unrealistic to expect your entire testing team to possess the desired technical skills required to successfully test SOA, but your test architect and your leads should be able to understand concepts like statefullness, distributed computing, and data services, to be able to properly validate the underlying architecture. They also need to be able to take developer test harnesses and update them with their own test scripts.

A successful SOA testing strategy starts with the test architect. This person must have a very in depth knowledge of SOA and should work closely with the EA team. I actually recommend that this person is a member of the EA team, but every business and culture is different. The goal of the test architect should be to set up a framework and a core group of policies and procedures (part of IT Governance) so that the rest of the test team has the tools and the guidance to successfully test SOA. Without an established testing architecture, the company will have to rely heavily on expert knowledge from the entire testing team. I have seen three scenarios through my personal experiences and through my research.


Scenario 1: Underestimating SOA
The first scenario is out right failure caused by not having the tools and knowledge required. This is caused by a company not realizing that their current methodology and internal personnel are not well equipped for testing SOA. These companies do not invest enough in tools, training, and governance and usually can only test the presentation layer and possibly the interfaces. By not understanding the concepts of SOA, they are unable to validate the architecture which leads to poor performing and fragile services.

Scenario 2: Paying through the nose
The second scenario I have seen is relying too heavily on "expert" consulting firms for testing. In this scenario the company bets the farm on an experienced SOA consulting firm and pay rates that far exceed $100/hr. This model cannot be sustained for any length of time unless the company is willing to burn huge amounts of capital (which is not a popular thing to do these days).

Scenario 3: Good balance of internal/external expertise
A more desirable scenario is to train or hire a SOA testing architect, build a solid testing platform tailored for the needs of the organization, and govern the testing process while training the other members of the team. Companies should hire one or more experienced SOA tester, find an experienced consultant or two, or train an experienced and credible internal candidate to take the lead for creating the testing architecture. At the same time the testing experts are charged with transferring knowledge over to the rest of the internal team members. This is critical because a highly experienced SOA tester is in great demand and is a flight risk since they are a rare breed. It is critical to grow the knowledge base internally.

Testing needs
The needs can be broken down into these categories: People, Tools, Governance. So what are the characteristics of a successful SOA tester. The answer is dependent on the architecture that is implemented, which is related to the tools and policies that are put in place. Below is a diagram I often use to discuss the typical layers of an architecture.

From SOA Slides

As I mentioned in the previous discussion about the developers, I see the need and desire to specialize within the layers. The same holds true for testers. Work within the layers happens simultaneously in development. I recommend an iterative development and testing approach which means there should be testers working within the layers simultaneously as well.

Here is what I would strive to put in place, keeping in mind that these are roles and some people may fill multiple roles:

SOA Test Architect
Courageous leader with extensive working knowledge of SOA, distributed computing, integration testing experience, coding/scripting experience, and understands the business. It is likely that you may have to go outside to hire this person or bring in a consultant to assist your top level tester.

SOA testing leads
This person or persons must understand all layers of the architecture (let's not forget security either) and should be able to design test plans that validate both the architecture and the governance model. They should understand how to perform black, white, and gray box tests. Testing abstracted services requires extensive testing in the areas of security, performance, and regression. Throw in the versioning capabilities of services and the fact that service consumers can use services in ways that were not anticipated and the permutations of test cases start skyrocketing. The test leads need to practice risk based testing and balance risks, timelines, and costs. There is just so much more at stake here than in the traditional n-tier architectures.

Business process testers
The business processes should be modeled within some tool and will likely call one or many services. The process flow requires a series of decision points based on variables and constants and can trigger events such as notifications, alerts, other processes, error handling routines, services, and a variety of other possibilities. The testers need to validate the business process as a stand alone entity. For example, if the business process is "validate credit card", the tester needs to ensure that this process handles the inputs correctly, properly runs the validation process, and generates the appropriate output. At this point, the tester need not be concerned with any other processes or services. These testers must work closely with the business and/or business analysts and do not need the breadth of technical knowledge that the leads and architects must have (although it would help). They should be approaching the testing from a business standpoint.

Integration testers
These testers must be much more technical and understand how to work with XML, SOAP, WSDLs, networking & telecommunication concepts, statefullness, and various platforms and technologies (Java vs .Net, Windows vs Unix/Linux vs. mainframe, etc.).

User Interface testers
The company most likely already has an abundance of people who can test the UI. If your company is leveraging mashups, wireless devices, or consumer facing UIs, the complexity of the testing will be greatly increased. These testers may be need to become familiar with AJAX, RIA, portal technology, RSS, and a variety of social software.

Data services testers
These testers must understand concepts of data modeling, database CRUD operations, transformations, security and roles, authentication, and much more. Everything starts with the data and if errors are introduced in this layer, everything else is doomed to fail. You must have a very strong testing lead working in the data services layer since data is the foundation of any successful implementation.

Other areas of focus
The name of the game is speed to market and test automation is a critical component for making that a reality. Performance testing is extremely critical and organizations should practice simulations to try to anticipate future performance of all services. Validating the security model and the governance model should also be part of the overall test strategy. Whoever is responsible for designing the security test plan should read (and fully understand) this book.

Closing comments
I am by no means a testing expert (but I did stay at a Holiday Inn Express last night). I do read a number of testing blogs listed below:

• Randy Rice's Software Testing & Quality Blog
• Frank Cohen's blog
• The ITKO Lisa Soapbox: SOA testing, validation & virtualization
• SOA Testing
• Mike Kelly's testing blog

Make sure your organization funds the necessary training and tools for testing. From my own personal lessons learned, make sure you invest as much effort in testing and security up front as you do in architecture and development. On my project a few years ago, I wore my developer hat too much in the research phase and did not properly budget for what was necessary for testing. Do not make this same mistake. As hard as it is to sell the business on SOA, it is much harder to go back for more money, especially before any business value is realized!

For those of you who have been reading my blog for the last two years, you might know that after 13 years at my previous job I left the company this summer to pursue multiple opportunities that were available to me. I have been doing some consulting and freelance writing in the mean time but have finally found my new gig. I will be the CTO/Chief Architect for a startup (more details forthcoming in the future) and will have the opportunity to work on some of the newer technology initiatives. So here are some of the future blog topics that I will start covering in 2009 once I get rolling:

1. SOA - can't seem to let it go! As I wrote in a post at CIO.com, I believe SOA is not just for legacy systems and can be the foundation that startups can leverage as a competitive advantage (see the reasons why)
2. Cloud Computing - Startups typically have low budgets and leveraging platform (PaaS) and/or Infrastructure as a Service (IaaS) can be a great way to both minimize costs and reduce time to market. As I go through the requirements analysis, risk analysis, vendor analysis, proof of concepts, prototypes, and deal with issues such as stability and privacy, I will share my lessons learned here.
3. Open Source - We will likely leverage many open source solutions and I will discuss those experiences and decision points here.
4. Social Software - The company is based in the North East and I live in Florida. It is highly possible that the team I build will be dispersed all over the country and possibly even the world. There will be great lessons learned discussions as well as evaluations of tools to help enable working remotely (virtual whiteboards, live meetings, SaaS solutions for defect tracking, etc.).
5. Agile - One of our goals is to deliver quickly and at low cost. This involves a lot of the above mentioned topics and will also lead us into the world of Agile Development. I will discuss our challenges and lessons learned in this area as well.
6. C-Level IT topics - In my new role I will be working side by side with other C-Level people within the company as well as with C-Level people of partner and customer companies. I will have to hit the road and sell and/or promote our products/services and will try to shed some light on some of the interesting topics I come across.
7. Misc - Other topics that might be worthy of discussing (examples: impacts of financial crisis, VC funding, selling technology to business people and customers, etc.)

In addition, I still do some freelance writing and blogging from time to time. I have a series of discussions coming up on enterprise mashups and will blog about it in the next week or two. I am attending and speaking at the EDM Summit in Orlando next week and will definitely be sharing my presentation on Business Intelligence as a Service as well as covering topics like business rules management, data warehousing, IT governance, and others. I also have two books from Packt Publishing to review:

• SOA Governance by Todd Biske
• SOA Cookbook by Michael Havey

Once I finish reading these I will post a review on my blog. I am half way through Todd's book so far and really like it.

And finally, I am open to covering any topic that any of my readers would like me to discuss whether it is on this blog, over the phone, or in person. Whenever I travel I send a Tweet on Twitter to let people know where I can be found. I will be in Pittsburgh from Saturday 10/25 through Monday 10/27 if anybody lives there and would like to meet. Don't bug me from 4:15-7:15pm on Sunday because I'll be at Heinz Field pulling for my Giants against a tough Steeler team. The rest of next week I am at the EDM Summit in Orlando.

I look forward to sharing these topics with you all. Over the next two months my focus will be on the business plan and creating a team. We officially launch the company in the December-January time frame. At that point expect to see more discussions on the topics I mentioned above.

I have discussed the role of the SOA Evangelist and the importance of the architects. Today I will discuss the different developer roles and the characteristics that make a successful SOA developer.

In a traditional 3-tier architecture it was common that there was a presentation layer, a middle tier or application layer, and a data layer. In some cases, a single developer role was responsible for all three layers. In larger companies, there may have been specialized roles such as a UI developer, an application developer, and a database developer. In an SOA, the concept of an application is no longer relevant except from the standpoint of integrating to existing applications. With SOA, we should be building business services that are application independent. The following chart is one I have used in previous posts which shows a typical breakdown of some of the development roles required for SOA.

From SOA Slides

So let's talk about business services. A business service is the compilation of all of the work done by the collection of developers within each layer. For example, let's discuss a "Shopping Cart" business service like the one we use on Amazon.com. It is most likely made up of services and/or components that live within each of the various layers of the architecture. The presentation layer obviously contains the physical implementation which the user sees and interacts within the browser. The business process layer contains the logical flow of steps that walk the user through the checkout process from start to finish. The business rule layer contains rules about tax codes, discounts, memberships, etc. and the underlying data elements and structures are handled in the data layer. In many instances, companies have multiple data structures that serve similar functions due to mergers, acquisitions, years of legacy systems, 3rd party application purchases, and many other reasons. To abstract these different data structures and present a common data interface that hides the complexity of the physical implementation of the data, the data services layer exists (think master data management).

So to develop this shopping cart business service, all of the people working within the different layers of the architecture must collaborate to deliver the service in a way that it both meets the business requirements and the technical requirements as defined by the SOA Governance model that the company has adopted. Examples of the technical requirements might be...

• Adheres to WS-* security standards
• Data encryption policies
• Platform neutral implementation
• Meets specific performance requirements

Why do I bring all of this up? Because developers that will succeed developing in a service-oriented architecture need to have the following characteristics:

• Flexible, open to change
• Collaborative
• Able to work in a setting with peers reviewing their work
• Able to see the big picture
  
• Not married to a certain technology
• Able to withstand constructive criticism
• Innovative

Developers who are protective of their own work or of their technology of choice will likely struggle working on SOA. One of the goals of SOA is to build platform neutral software that is highly flexible, maintainable, and loosely coupled. To build software like this we must shift away from software developing and move to software engineering. In simple terms, we must move from drag and dropping to planning and modeling. We must embrace collaboration, peer reviews, and governance. If your developers don't like these requirements, they either need to change or leave. Otherwise they will be a cancer and will continously feed the forces of resistance.

Ok, off my soap box now. So let's discuss the roles. But before we do let me note that we are talking about roles and not individuals. In smaller companies, a developer may perform multiple roles. In larger companies we may actually see very specialized developers living within a single layer of the architecture. One last disclaimer: I am assuming that an architecture team exists and some form of standards and governance is in place within each layer.

UI developers
If your company can afford to specialize, this is the perfect layer for it. Developers in this layer do not necessarily have to be extremely technical. It is more important that they understand usability, UI standards, and web interface best practices. These people should be comfortable working in prototype mode where they can start with mockups and work closely with the business or business analyst to reiterate through the various visuals until an agreed upon format is approved. These developers must be able to talk to the business in business terms and understand how typical business users interact with web technology.

Business Process developers
There are two distinct roles in this business process layer. One role deals with modeling business processes, the other role deals with integrating business processes with the underlying services and systems. In some companies this role may be served by one person but more likely it will be two because of the difference in the skills required. The business process modeler may not even be an IT person. Some companies have a department that exists within the business that focuses on business process improvement and business process automation. This is the norm for companies that practice Six Sigma or Total Quality Management (TQM).

The business process integrator is a technical role which requires expert experience working with Web services, REST, JMS queues or several other technical areas of expertise. The integrator is the person who connects business processes to the backend technologies which controls the overall flow of the business services and overall composite business application, often coined orchestration.

Business Rules developer
This one is a little fuzzier. Not all architectures have a distinct business rule layer. In some instances, the business rules are controlled in the data layer. For companies who have very dynamic business rules, especially rules that are customer centric and could be updated by end users and even customers, it makes a great deal of sense to abstract the business rules. If a company has a business rule layer and implemented a tool to manage business rules, it is highly likely that you will need technicians who govern this layer much like DBAs govern the database layer. In some case this might be an additional role for a DBA but it does not have to be. Whoever it is they must understand the concepts of abstraction and be looking for ways to empower the end user to react quicker to changes in the business. For example, let's say that a loan approval process requires state specific business rules about what percentage of capital is required from a loan applicant up front before the loan application can be expected. The frequency which this value changes varies by state and must be updated as soon as possible. The best scenario is to take IT out of the process and enable certain users (or systems) with the appropriate authority to update the values as necessary. Whoever is responsible for the business rules must be able to work with the business and/or business analysts to understand the frequency of change, the rights and permissions, and the impacts of the various business rules. There is an amount of overhead associated with creating and managing rules and the person in charge must understand the trade offs.

Data Services developer
Maybe a better name for this person is an information architect. The person in charge of this function is responsible for abstracting the underlying data layer and exposing it the other layers of the architecture and even externally to other systems. For example, let's say that our shopping cart business service allows multiple forms of payment (American Express, Visa, and Pay Pal). In addition, the different products purchased (books, DVDs, clothing, etc.) are managed from different inventory systems. To hide that complexity and to allow us to add additional payment services and inventories with ease, we leverage data services to present the shopping cart service with a logical view of the data. In other words, we create a standard payment and inventory message that the shopping cart communicates with. As long as the shopping cart communicates with these standard messages, the underlying physical implementation of the different payment and inventory services are irrelevant. The shopping cart service simply communicates these messages in the standard format it knows and the translation from the standard message to the physical layout of the receiving systems or services is performed in the data services layer.

From SOA Slides

(This slide is from BEA)

Developers or architects within this layer must have exceptional technical knowledge in the area of data modeling and database design. If the company has a tool to manage this layer (which is highly recommended) then an administrator is also needed.

Database developers
This data layer is typically an area that already exists today within each enterprise. This is where the DBAs live. With SOA, the DBAs must work extremely close with the developers within the other layers of the architecture. They must understand the performance and security requirements of each layer and ensure that the underlying data model meets the needs. Since legacy integration is common in many SOA implementations, DBAs are often called upon to create views or structures or even establish new ETL processes to provide a common view of data to expose to the other layers of the architecture.

Security developers
The security experts may not actually do the development but there must be a person or group of people who understand the new security challenges that SOA introduces. SOA can introduce the following new threats:

• Expose components of legacy systems that were never designed to live outside the firewall
• Require trusts between multiple internal/external systems without additional sign-ons
• Send a single message to multiple partners each with their own distinct security requirements
• Expose credit card and other privacy related data out on the web

From SOA Slides

(This slide is borrowed from the following presentation from Mamoon Yunus of Forum Systems)

Todays n-tier security models are not enough when dealing with B2B type SOA implementations. The developers in this area must have a deep understanding of communication protocols, security best practices, web architecture, regulation (ie. HIPAA, SOX, PCI) and WS-* or other standards.

Summary
As you can see there are many distinct developer skill sets required to implement SOA properly. Trying to find a person that can master each layer is not realistic. If you have this person, it is likely that he or she is on your architecture team. The beauty of this architecture is the ability to divide and conquer the problem within each layer. A single business service can be worked on by numerous people within each layer. It requires solid governance, strong collaboration skills, and teamwork to work this way which is why it is critical that the right team of people is assembled to tackle SOA. My next post will discuss the testers and their relationship with the development team.

In part 1, I discussed the importance of the SOA Evangelist. I also talked about the shift from software development to software engineering. This shift has made the role of the architect critical for the success of any SOA initiative. First, let us talk about the various architect roles required to successfully design an SOA.

Chief Architect - This person, possibly your SOA Evangelist, should have strong technical skills, sound business knowledge, and great leadership skills. Not only should this person understand the ins and outs of SOA, but he/she should be able to explain the value of SOA to the business in business terms, to the CIO in high level technology and business terms, and to the technicians in detailed terms. Depending on the size of the company and the SOA initiative, this person may or may not actively participate in the design. Regardless, this person should be knowledgeable enough to participate in design sessions when called upon. From a leadership perspective, this person is likely the change agent who is the driving force behind establishing and implementing governance, shifting the IT mindset from programming to engineering, establishing the SOA roadmap, and other culture changing elements.

Enterprise Architect - In smaller or midsize companies, the chief architect and the enterprise architect may be one in the same. In bigger companies, there may be more then one EA. The EA has broad domain and business knowledge and works across organizational boundaries to ensure that the architecture meets both the business and IT requirements. Wikipedia says it best when it mentions....

The role of the Enterprise Architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner.

Domain Architect - The domain architects specialize in specific areas of technology. They are the experts of their domain. Here are a few examples of domains that require specialization:

• Application
• Information
• Security
• Infrastructure
• Business Processes
• Network
• Integration

Once again, the size of the company often dictates how many of these roles exist as a stand alone job function or if they are rolled up into a broader architect role. For example, smaller companies may combine application, information, and integration into one role and infrastructure and network into another role. The key for me is that these roles need to be accounted for regardless if its by one or many people. Each role is critical in successfully architecting a true SOA.

Solution Architect - The solutions architect has hands on experience with specific technologies and even business applications. You may have an architect who specializes in Java, .Net, backend systems, web applications, financial systems, ecommerce systems, distributed processing, etc. Once again, I am advocating that the role is addressed and whether or not a company has one or many people with this title depends on its size and budget.

The Architecture Team
As I described above, the team should consist of the following roles (not necessarily individuals):

• Chief Architect
• Enterprise Architect
• Domain Architects
• Solutions Architects

The number of people filling these roles vary from company to company. In my previous job, a shop of roughly 200 people, our architecture team consisted of myself as a Chief Architect, an EA, a domain architect, and a solutions architect (even though they all had the simple title of "Architect"). There was an Architect over the infrastructure and network that reported into a different structure and a one person security team. My architect team worked closely with the others but it would have been more effective had we all been on the same team with the same goals and objectives.

I have seen a case study at an enterprise architecture conference a few years back where a global SOA initiative for a fortune 100 company had over 100 architects on the team including numerous EAs and even multiple Chief Architects from different business divisions. There is no one way to slice this pie.

Architect Mindset
You can organize the teams anyway you like but one thing you must have is the proper mindset. The architecture team must be focused first on the business drivers that the SOA initiative has set out to solve. If the team loses sight of these drivers then SOA will become an IT project instead of an important initiative for the entire corporation. You must have the business buy-in throughout the project to reap the true benefits of SOA. Please read 8 Winning Characteristics of Successful SOA Implementations which I wrote for CIO.com that summarizes the critical success factors that wer common among the winners of the SOA Consortium/CIO.com SOA Case Study contest earlier this month.

Second, the team needs to ensure that they are not an Ivory Tower architecture team. SOA is too important for architects to be preaching philosophy from the top of their perches. The architect team must be the change agents required to move the organization away from the traditional silo driven application development approach and into a more collaborative engineering approach that focuses on the long term vision not the short term and short sighted approach that many companies practice today.

Third, this team must have an open mind. They need to evaluate current business processes, current IT practices, and current systems, and provide the necessary change and direction required to move the organization forward towards the vision established by the business and IT and reflected in the SOA roadmap. Without changing the way IT approaches development, it is likely that the team won't be able to differentiate between SOA and web services. Education and evangelism is key to understanding the proper way to architect and govern your SOA.

In part three I will discuss the developer role. In part four I will discuss the testers.

There is no shortage of advice on the web of the do's and don'ts for tackling SOA. One topic that I don't see discussed much is the assessment of a company's IT skills as it pertains to the ability of a company to comprehend and actually deliver on the promise of SOA. This is part one of a series that addresses the many skillsets required to deliver a Service-Oriented Architecture.

I have mentioned in the past that companies that have not invested in enterprise architecture may struggle as they shift from software development to software engineering.

Here are the wikipedia definitions of these two terms:

Software development is the translation of a user need or marketing goal into a software product

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

There is a major difference between the two. Software development is the creation of software regardless of the means used to accomplish the task. Software engineering involves using a defined set of processes, procedures, and standards with the goal of improving the reliability and maintainability of the systems being built. So for companies that don't take a software engineering approach to software development, they may have huge challenges doing SOA with their existing staff. Throughout this series I will make reference to the shift from development to engineering as a key aspect of each skills assessment as I discuss SOA evangelists, architects, developers, testers, and many others.

When kicking off an SOA initiative, companies should perform a readiness assessment to identify areas of concern and create action plans to address them. For this series of posts, I will focus on internal skills in the IT organization.

First and foremost, a SOA Evangelist is critical to the success of any SOA initiative. This person must understand SOA inside and out from the perspective of both IT and the business. From the business standpoint the evangelist must understand the business drivers, the financial impacts and ROI, and can speak to the business in their language. From the technology standpoint, the envangelist must understand all aspects of the archtiecture in order to communicate effectively to developers, testers, security professionals, architects, network and infrastructure personnel, project managers, business and process analysts, and management. The evangelist should promote SOA and importance of governance and should help establish the Center of Excellence (CoE) needed to provide oversight and enforce the principles of software engineering. I have seen and read about several instances where SOA initiatives that were successful quickly turned to chaos upon the departure of the company's evangelist. In one case, the company quickly lost sight of the business drivers and began to debate on technical issues like whether the services should be done in .Net or Java. These are the unfortunate consequences that happen when SOA is left to those who don't have a full understanding of the technical and business benefits of SOA and focus on software development as opposed to software engineering.

Characteristics of an SOA Evangelist
An SOA Evangelist should have strong leadership skills, strong technical or even architecture level skills, should be business savvy, have a grasp on core financial concepts, and be comfortable presenting to people at all levels. On the same day, the evangelist can be expected to discuss key issues with C-level executives and then roll up the sleeves and explain the advantages of the distributed nature of SOA to the technicians. This person can expect to be confronted with various pockets of resistance which is natural for initiatives that introduce new concepts to an organization. Organization change management skills are a necessity for a person in this position. One of the key challenges for a person in this position is to get the staff engaged and give them a sense of ownership. Without this, the staff may look at the the initiative as a pet project of the evangelist instead of what it is, a key initiative for the business. The evangelist will have to lean on the exectuive sponsor and top level management to help with this.

Life without a SOA Evangelist
I feel that without an SOA Evangelist, companies will struggle for a number of reasons. First, having an expert on SOA who spreads the knowledge throughout the organization is much more efficient than having various individuals coming up with their own definitions and perceptions of SOA. An evangelist can brand and market the vision of SOA for the entire company so everyone is talking the same language. Second, the evangelist also bridges the gap between the business and IT and ensures that the technologies being implemented are focused on the business needs and not the needs of IT first. In addition, the evangelist can translate IT speak to business speak and spare the business of technical details that tend to dominate conversations when technicians discuss SOA. But most importantly, there is usually many different silos within both the business and IT that must be brought together to work as one. The evangelist is likely the person who knows enough about each silo (at a high level) to help bring all of these parties together. Without cohesion between the silos the SOA initiative can spiral into chaos.

In my next post I will discuss SOA and the architects.

Below is the presentation that I am giving tomorrow at the SOA Consortium. Today we discussed numerous case studies. In each case, there were major changes within the organization that had to be overcome. In some cases, the business had to standardize their business processes which required them to change the way they think and work. In other cases, developers had to shift their mindset from the way they have always built things to a more service-oriented approach. In several of the government case studies, large organizations with completely different cultures and processes had to work with other government agencies that they have never worked with before. I could go on and on but the common theme in all of these case studies was that change was one of the most challenging parts of the SOA implementations, not the technology. In fact, one initiative took a year and a half just to get 18 different government agencies to agree on a standards, requirements, and data definitions. Talk about change!

Anyways, here is my presentation about change and how to plan and manage it.

I frequently discuss SOA with potential clients, fellow architects, and business partners. Each audience requires a discussion that is tailored to the appropriate level of technical and business expertise. Today I had to present to a CEO and a few of his top staffers about what it takes to launch into a SOA initiative. So I put together a presentation similar to the one below and felt like sharing it with all of you.

Before you look at it let me put the discussion into context. The target audience is hi level management, business and IT, who are already bought into SOA and are trying to understand what is involved before they launch into a full blown SOA initiative. This is not a presentation for architects, rather it is to inform C-Level stakeholders what is required from a business, technology, and culture standpoint.

I also had to sell to them that I know what I am talking about, hence the first few slides about my background. One last note: Some of the slides are mostly visual and only get the point across when backed up with talking points.

I hope this adds value to some of you. Enjoy!

I just had a very frustrating experience with the support folks at Dell. Last year I bought three Dell Inspiron 1721 laptops for my wife and two kids. The performance of these laptops were so poor that I switched two of them to Linux. Today I received a notification that my warranty was expiring in five days. It reminded me how badly I was ripped off having to spend about $250 of the $1000 laptop price on Vista which is not capable of performing at acceptable levels on the hardware that Dell sold me. So I decided to call Dell support to see if I could downgrade to XP or get some discounted pricing on memory (a long shot). After over two hours of being passed around like a hot potato from support person to support person, getting disconnected twice, and in the end getting told that they could not help me, I felt obligated to write Michael Dell a letter. I do not expect him to ever read it or anybody at Dell to act on it, but I do feel obligated to rant about it publicly. This is how loyal customers get treated! So here is my email I sent to Michael Dell titled "An angry customer":

Michael,

I have been a loyal Dell customer for over 10 years and have purchased at least 10 PCs and laptops in that time. I have also recommended Dell to my friends and family for years. Today, that loyalty is gone. Last September, I purchased 3 Inspiron 1721 laptops for my wife and two kids. They all had older model Dell's that were hand me downs each time I treated myself to the newest model. I ordered them online and purchased the low end priced model which fit my budget (about $1K each). I wanted to get Ubuntu but the only OS available for these models was Vista. I didn't think that Vista would run well without a ton of memory, but I figured that if Dell only offers Vista on these laptops, then Vista must have acceptable performance on them.

Within a month, due to delays in parts and shipping, I finally received all three laptops. The performance of these laptops are totally unacceptable. My wife and daughter refused to use these machines and went back to their old Dell's running XP. I became so frustrated with these machines that I wiped them out and put Ubuntu on two of them. They run fine now but I can't run some of the software that my kids use. I eventually bought my wife a Mac and she is a happy camper. My son still has Vista because he plays a game that requires a Microsoft OS. Using his computer is such a painful and time consuming experience.

Yesterday I received a letter from Dell asking me to renew my warranty which is set to expire in 5 days. I thought to myself, "Since I am still under warranty, Dell should still be held accountable for selling me laptops that do not have acceptable performance for the base configuration that I selected online". In other words, Dell is selling laptops to consumers that have unacceptable performance and provide no alternatives for better performing operating systems. I did not have a choice to choose anything other then Vista. So I called support hoping that the company would assist a long time loyal customer by allowing me to exchange my Vista license for XP licenses (downgrade to XP) or give me some discount pricing on memory. Had I known that Dell did not have a $1K laptop that had acceptable performance, I would not have bought any, not to mention three of them.

To make a long story short. I spent over 2 hours on the phone getting transferred from one person to the next. Each time I had to reiterate all of the order information, personal information, and my issue. Each time I asked for a manager and was not granted my wish. At two different times I had a support person agree to send me XP licenses at no cost. Both times they transferred me to technical support (don't ask me why) were I was put on hold and eventually received a busy signal. Then I had to call in again and start the entire process over again. Eventually I was able to talk to manager. Once again I had to go through the entire information gathering exercise and the explain my case. Don't you guys use computers? If I have purchased computers from Dell on your web site for 10 years, don't you already have all of my info including my hardware specs? I am able to see all of this info from my side. Oh, you don't do software!

Anyways, this guy (employee # 110337 with a fake US name called "Dave") basically told me that he can't help me and I have to buy the XP licenses or buy more memory. He says that I should have dealt with this issue when I first bought the laptops, not now. My point is that it is still under warranty so it shouldn't matter. Regardless, it is beyond belief to me that your company would sell computers that do not have enough memory to run Vista at an acceptable performance level and then turn your back on a loyal customer who is stuck with three laptops that nobody wants to use. Nobody who buys a brand new laptop should have to wait over 10 minutes to boot it up. And nobody should have to spend over two hours going through your inefficient customer service processes. I would really appreciate it if your company would allow me to downgrade to XP at no cost. But I have such low expectations from Dell now that I am moving on. I am now a new avid Mac fan!

Cheers,

Mike Kavis

P.S. This sounds like a great topic to blog about!

To successfully lead an IT organization, one must excel in three key areas: Technology, Business, and People.

When attempting to implement enterprise initiatives, those leaders who do not excel in people skills will have some serious challenges. For whatever reason, many IT leaders neglect the "people side of change" (listen to my podcast with ZDNet's Michael Krigsman) and do not address a critical need - Organizational Change Management.

I am a huge fan of Harvard's leadership guru, John Kotter. Kotter has a proven 8-step methodology for leading through change. Here are the steps:

1. Create a Sense of Urgency
2. Pull Together the Guiding Team
3. Develop the Change Vision and Strategy
4. Communicate for Understanding and Buy In
5. Empower Others to Act
6. Produce Short-Term Wins
7. Don’t Let Up
8. Create a New Culture

For more on this topic I recommend his books "Leading Change" , "Our Iceberg is Melting", and also "Change Management: the People Side of Change" by Jeffrey Hiatt and Timothy Creasey.

And remember, now matter how good you do with the technology and business side of the equation, if people resist change your project will more then likely fail.

Startups and Non-profits

Startups and non-profit organizations typically are constrained by limited capital budgets. Startups need to quickly launch their products and services at low costs. Cloud computing allows startups to rapidly deploy into a “leased” infrastructure supplied by a cloud computing vendor without having to procure a ton of hardware, hire system administrators, and build out a data center. In addition, the cloud computing option allows startups to pay as they grow as opposed to having to pay for maximum capacity out of the gates. Startups also have the luxury of starting with a blank sheet of paper as opposed to having to migrate their legacy applications to the cloud.

Many non-profits, like the United Way and Goodwill, are funded by donations. It is in everyone’s best interest that the majority of these donations are used to benefit the people who need help from these organizations. Building large data centers and hiring people to look over them is not a great way to achieve this goal. Instead, non-profits can now move their data centers to the clouds and spend more of its donated funds on worthy causes instead of infrastructure.

Small and Midsize Companies

Small and midsize companies have to stretch modest IT budgets to meet the demands of the business while providing 24x7x365 capable systems. Some of these companies cannot afford to support multiple data centers to protect against disasters and to provide business continuity. Others have a robust main datacenter and a scaled down backup datacenter that would allow the company to limp along for a short period of time if an unfortunate event was to occur. But the bigger challenge is to focus enough resources on revenue generation. The more resources these companies have keeping the lights on, the less demand from the business they can support. These companies often have to make some compromises in technology upgrades, architectural decisions, and infrastructure purchases to allow them to meet the needs of the business. I have worked in a few midsize companies over the years and witnessed this first hand. Every year we were asked to do more with less money and we often had to provide “good enough” solutions because we could not afford to build the level of robustness into the infrastructure and applications that we would have liked.

With cloud computing, small and midsize companies immediately get the benefits of world class infrastructure without having to procure, implement, and administer it. This frees up resources to focus on innovation and business demands. In addition, these companies can leverage multiple datacenters located in different geographical locations to meet their disaster recovery and business continuity needs. As the demand for computing resources increase, staff can add additional servers and disk on the fly by using tools provider by the cloud computing vendor without having to purchase any hardware. They simply just tap into some more computing resources into the cloud and pay for what they use.

Large Companies

Large companies with billion dollar IT budgets do not have a lot of the issues that the startups, non profits, small and midsize companies have. Many of these companies are watching from the sidelines as cloud computing matures, but still think it is too risky to jump in. The large companies that do adopt cloud computing will be gaining competitive advantages over their competition. Here are some of the reasons why.

Going green – Many billion dollar companies are under intense pressure to be more environment friendly. Replacing thousands of servers and other equipment is an extremely expensive and time consuming undertaking. Large companies can start by migrating their non-mission critical applications to the cloud. This allows them to go green quicker, cheaper, and get a chance to “kick the tires” on cloud computing at low risk.

Reduce costs – Energy costs for running hardware and cooling can be greatly reduced by moving applications to the cloud. In addition to reducing the amount of hardware to buy, this could prevent or at least prolong plans to acquire additional floor space, buy additional generators, or install more cooling systems.

Agility – Prototyping is another opportunity for using cloud computing. The business wants things faster from IT. IT can now quickly create a prototype by leveraging virtual infrastructure in the cloud and experiment with various configurations without having to go through long procurement cycles. Cloud computing can also be used to set up and tear down multiple test areas with ease and without having to free up or buy and configure hardware.

Security/Privacy - Large companies’ biggest fear is security and privacy. That is why some cloud computing vendors offer private clouds for their customers. Companies can enjoy all of the benefits of cloud computing within their own private VLAN and configurable firewalls to protect their data and privacy.

Conclusion

Regardless of the size of a company and its IT budget, cloud computing provides many benefits that just cannot be ignored any longer. For startups, non-profits, and small and midsize companies, cloud computing is a no brainer. Large corporations are being cautious right now. It will only take a few key success stories from a competitor who drastically reduces costs and improves its speed to market to get more large companies on board. In the mean time, large companies should look at piloting a non mission critical application in the cloud and continue to monitor the vendors as cloud computing continues to mature.

I just read a post on ZDNet where Lawson's CEO Harry Debes claims that SaaS is a failure and that it will die in two years. He also comments that people (meaning me and you) "are stupid" and "make the same mistakes over and over". Another great comment is that he complains how SaaS does not allow vendors to lock in its customers:

Getting signed up as a SaaS customer is fast, but getting out is just as fast. Whereas traditional software is like cocaine--you're hooked. It's too difficult and expensive to switch providers once you've invested in one.

Wow! How customer focused is this guy? I guess this explains why the previous version of Lawson required users to have a Unix login and a telnet session and why the product was still based on Cobol. I worked at a place that used Lawson and I was stunned by how far behind the product was from an architectural standpoint. Now I understand why.

The criticism that this guy makes towards the technology is that same old resistance to change that stalls innovation. We see it with SOA, Cloud Computing, and other initiatives that are innovative and require people to change their ways. There are leaders, followers, and stragglers. This guy is definitely a straggler and may severely hurt his company and his shareholders with his closed minded approach to technology, especially if he is wrong!

In closing, my favorite comment in response to the article is by CEO John Grabski of ClearMomentum....

I hope there are more CEOs out there with the same view. Taking their customers is like shooting fish in a barrel.

As a great leader said recently, "Enough!"

Introduction

Over the past two decades, most companies have embraced the World Wide Web as a standard platform for delivering applications to consumers, partners, customers, and even internal end users. The web offers companies easier deployments, a standard browser interface that requires minimal training, and access anywhere in the world at anytime and on any device. The downside of web applications is the limitations of HTML and the ability to deliver rich content that compares to desktop applications. Enter RIA (rich internet applications) which gives web applications the richness of desktop applications with all the benefits of web. Adobe has been the leader in the space for years. Flex was first released in 2004. They have dominated the market place against various competitors, both commercial and open source. In 2007, Microsoft introduced their Silverlight product. Silverlight is the first real threat to Adobe’s Flex. The rest of this document will focus on the pros and cons of these technologies, possible outcomes, and what the impact of this RIA race will mean to vendors, companies, and consumers.

History of Flex and Silverlight

To provide a fair comparison of these two products, it is important to become familiar with the history of the Adobe Flex and Microsoft Silverlight products. Without understanding the different releases and product roadmaps, it becomes extremely challenging to perform an apples to apples comparison.

Flex version 1.0 was first released in March of 2004. Flex requires Macromedia’s Flash runtime which is a virtual machine that runs on any operating system. In 2006, Adobe released three Beta versions of Flex 2.0 before delivering the final 2.0 version in June of the same year. The new version was based on Eclipse, an open source development platform that is popular among most Java development environments. Coinciding with this release was a new release of ActionScript 3. ActionScript is the core development language of the popular Flash Player. In 2007, Adobe released three Beta versions of Flex 3.0 with the final production 3.0 release delivered on February 25, 2008. The most significant change in this release was to make the Flex SDK an open source product. Now developers were free to contribute to the SDK which was well received by the developer community. In addition to major enhancements including integration with Adobe’s Creative Suites products, Adobe also released the first version of their own runtime called Adobe Air (formerly called Apollo). The next version (4.0) is scheduled for release in 2009. We can expect a Beta release late this year. The features have not yet been announced but one can assume that they will be addressing some of the areas that Silverlight has an advantage, including better integration with .Net.

Silverlight is a web browser plug-in that marks the first Microsoft product that is truly cross platform and cross browser compatible. The first release of Silverlight was delivered in April 2007. The focus in this release was more geared towards multimedia and lacked many features that Flex 2.0 and the 3.0 Beta version had at that time. Silverlight 1.0 depends on XAML as the underlying development language. XAML is an extendable XML language that was created by Microsoft and used extensively with the Windows .Net 3.0 framework. The next version of Silverlight, version 2.0 is targeted for late summer/early fall of 2008. The first Beta version was released in March of this year. The big news for 2.0 is the integration with Visual Studio. Now developers can use development languages that they are familiar with like C# and Visual Basic. Another much needed feature is the addition of robust debugging functionality and full set of controls for developers.

It is important to understand the major feature sets of each release. There is heavy debate on which product is best. Many Adobe fans compare Flex 3.0 to Silverlight 1.0. There is no comparison. Silverlight 1.0 was focused on getting a product out in the market place while the development team focused on creating a more robust version (now named 2.0). The Microsoft supporters, however, talk about the features in 2.0 that do not exist yet. This is not a fair comparison either since Flex also has a very promising feature set in their future release. For the remainder of this document, I will focus on Flex 3.0 versus Silverlight 2.0.

Strengths and weaknesses of Flex

Adobe Flex has a huge advantage over Microsoft Silverlight in product maturity, developer community following, and production deployments. The biggest advantage, however, is that the Flash runtime is installed on well over 90% of all PCs and laptops across the world (see Figure 1).

Figure 1

The Flash runtime also works on a variety of platforms (Windows, Mac, Linux, Solaris, HP-UX, Pocket PC, OS/2, and several others). Flash is viewable in over 85% of all browsers. Since Flex runs on the Flash Player, it is truly a cross platform, cross browser product with world wide acceptance. There is also a strong developer community and the Flex products are mature since they have been through three major release cycles. Another advantage that Flex has is that many major vendors are using Flex to deliver rich content. Microstrategy leverages Flex to deliver robust, drillable result sets and even Flash based emails to end users. Google (Google Maps), Yahoo (Messenger), IBM, SAP, E-Trade, and Business Objects are just a few of the major vendors and service providers who rely on Flex to deliver rich user experiences to their customers.

Another big benefit of Flex is that the SDK is now open source. This creates several benefits. First, testing of Flex now has thousands more eyes that can find bugs and submit them back into the community. Going open source also allows the Flex community to help drive the products direction and feature sets. Making Flex open source is also a good way to combat Microsoft, who is the nemesis of most open source advocates.

One of the biggest complaints I have heard about Flex is the learning curve required for developers. Flex uses ActionScript 3 which is a proprietary language that is required for running on the Flash Player. This is yet another language that developers must learn and is not as intuitive as Java and C#. This can lead to high costs for hiring companies and must be considered when calculating the total cost of ownership.

Strengths and weaknesses of Silverlight

Microsoft is putting together a great product to compete with Flex. In my opinion, they are still a couple of years away from matching Flex in features and community strength. However, Microsoft’s marketing capabilities coupled with their ability to target developers can help Microsoft make major gains in market share in the near future. Silverlight 2.0 allows developers to code in C# and VB which greatly reduces the learning curve. This can be a major selling point to companies that are planning to invest in RIA technologies in the future. Many companies already rely heavily on Microsoft technologies and may see Silverlight as a natural extension to their existing development stack. Microsoft also has an incredible amount of cash available to them to steer this product in whatever direction they see fit. They have already partnered with Major League Baseball and the Olympics which has created a tremendous amount of positive marketing and brand recognition.

The weaknesses of Silverlight are plenty, but when put into perspective of how long they have been in the RIA space (first release in April 2007) they have made tremendous strides in this area. First of all, Microsoft is the new kid on the block and does not have the track record of stability, performance, and maturity of the well established Flex product line. The biggest challenge Microsoft faces is trying to get the Silverlight plug-in installed on at least 80% of the PCs and laptops in the market place. If you look at Figure 1 above, you will see that the top Microsoft product installed on PCs is Windows Media Player which is slightly over 80%. This product has been out for several years so it would be unrealistic to expect the Silverlight plug-in to reach critical mass any time soon.

Silverlight currently only runs on Windows and the Mac, although an open source project called Moonlight is underway to allow it to run on Linux. Back in May of this year, Roger Magoulas from O’Reilly shared this chart (Figure 2).

Figure 2

This chart shows that book sales of Flash are selling 6-7 times higher then Silverlight. In March of this year, Eric Lai of Computerworld wrote an article comparing job postings for Flash versus Silverlight on the major job boards. His study showed that Flash skills were in demand about 41 times higher than Silverlight. Both the study on books and jobs are not extremely scientific by any means, but what they do show is that Silverlight has a long way to go to become mainstream.

Another problem Microsoft is facing is consumer trust. Many consumers have heard all of Microsoft’s promises of cross platform capabilities before only to see them not deliver on their promise. Microsoft’s cash cow for years has been their operating system. Many consumers simply can’t trust any message from Microsoft which goes against their core strategy of tying customers to their platform. Security is another issue. Microsoft does not have the greatest reputation for secure software. How many corporations are willing to roll out another Microsoft product to all of their desktops? Some may argue that Flash is no more secure, but it is already on almost every machine out there.

Possible Outcomes

There are four possible outcomes that I see. The first is that Flex will continue to dominate the market place due to the maturity of their existing products, the widespread use and acceptance of Flash, and the large investments made by major software vendors in Flex technology. Microsoft will steal some market share but in the end it will be another failed attempt to conquer the web. I feel that this is the most likely scenario. Microsoft is already losing market share in the browser war and the operating system war, although they still have a tremendous lead over their competitors. Google is becoming a dominant force on the web and open source technologies are dominating the Web 2.0 world. In every aspect of computing, Microsoft is dealing with stronger competition then they have ever seen before. RIA will be even more challenging because they are not the leader in this space.

The second most likely option that I see is that Silverlight matches Flex’s market share. The big advantage that Microsoft has is the development environment and the fact that Flex currently does not integrate with .Net backends (although they are working on it). Microsoft already has a huge developer community and many of these people can easily be persuaded to adopt Silverlight as their RIA of choice. For companies that produce consumer facing content or control the end user client machines, the Silverlight plug-in issue is not that big of a deal. Many consumers are willing to download Silverlight plug-in just as well as they will download Flash, QuickTime, and others. It is the companies that deliver applications to other enterprises that will have the challenge. As a chief architect for a medium size company, one of our criteria for selecting vendor tools is that the tool is zero-footprint or requires no installation of software on client PCs. Many other IT shops will have the same constraint because of the B2B nature of their applications. If you have no control over the client’s desktop, forcing clients to push software out on their network can be a huge show stopper.

A third possible outcome is Silverlight will fail to gain any significant market share. I find this highly unlikely. Microsoft has a ton of money and smart people behind this product. Their product vision appears to be very solid on the surface and their initial product offering is impressive for the short amount of time that they have been in the RIA space. They should easily capitalize on the numerous loyal Microsoft shops that are already in place today and I expect them to strike several more big partnerships similar to the MLB deal. I think that over the next 2-3 years Silverlight will capture about 20-30% of the market share but no more.

A fourth possible outcome is that more competition will flood the market and other products will also compete heavily for market share. JavaFx and open source project Open Laszlo are already competing, but I believe this will be a two horse race between Flex and Silverlight.

What is the impact?

This fierce competition means different things to different constituents. First let’s look at the impact to the vendors. Software vendors must keep a close eye on this RIA race. Those supporting Flex today need to make a decision whether or not they want to add support for Silverlight as well. Supporting both obviously increases the cost of developing and supporting their products. Since Flash is everywhere, they need to consider how strategic it will be to support Silverlight. Some vendors are already making the jump but others will wait and see how widely accepted Silverlight is before they assign resources to making their products support Silverlight.

Non-software companies also have a big decision to make. For companies already using Flex, there must be some compelling reasons to switch. For those evaluating RIA for the first time, they have a tough decision to make. Do they play it safe and go with the proven product in Flex, or do they buy into the marketing hype and go with the promises of Silverlight. Silverlight does have a compelling TCO by enabling developers to leverage Visual Studio as opposed to having to learn ActionScript 3.

The consumer is the least impacted. For consumers it is simply a matter of downloading the plug-in or not. The people that won’t download the plug-in are typically anti Microsoft anyway. So Microsoft will continue to target popular providers of rich content for partnerships to get more installs of the Silverlight plug-in throughout the world.

Conclusion

I expect Silverlight to gain market share over the next two to three years but still see Flex prevailing as the industry leader in the long run. The best news is that the competition will force both products to be more innovative. Both products will aggressively address their weaknesses and combat any new features that their competitor offers. This is great news for vendors, companies, and consumers. We should expect to see huge advancements of features and functionality from both of these products over the next few years. We should also expect to see improvements in speed, security, ease of use as both Flex and Silverlight battle for the RIA throne.