Choosing a SOA Consultant

The first question to ask is do you really need a SOA Consultant?
In most cases the answer is yes.
The consultant has vast knowledge and experience and deeper understanding.
An Aberdeen Group survey finding supports the conclusion above.
Consultants participate in Best in Class (BIC) enterprises SOA initiatives more than in average enterprises. Laggards SOA initiatives include consultants even less often than average enterprises initiatives.

The next question to ask is: What kind of SOA Consultant should you hire? 
I read a relatively old but interesting ZapFlash   written by ZapThink's Jason Bloomberg in 2008. The ZapFlash titled: The Great SOA Consultant Squeeze discusses this issue.
The ZapFlash describes a scenario of Request for Proposal (RFP) send to three consulting firms: a large, internationally known firm, a midsize firm with a well-regarded technical focus, and a boutique SOA firm that focuses solely on SOA engagements. Surprisingly, the large firm, whom you expected to be the highest, proposes only 20% of the boutique’s price.

Be aware of cheap proposals
You can be sure that there are no free meals. The difference in price reflects the difference in consultancy quality as explained in the ZapFlash.
SOA or not SOA, you better ask yourself, why one proposal's price is a lot cheaper than its competitors.
Assume you are the bidder of the cheapest proposal, which is 20% or 30% or 50% cheaper than other proposals. In most cases, you can estimate the price of the other proposals, and you should have a good reason for bidding so low.
 In most cases, your proposal is inferior in functionality and quality and also costs you less to provide the product, project or consultancy.
Now return to your role as the valuator and be aware of your real overall costs (including indirect costs) by choosing the inferior and cheapest proposal. In most cases the cheapest proposal will be the most expansive.
For example, an inadequate SOA implementation due to inappropriate consultancy could cost millions of dollars, with no Return On Investment (ROI).
Adequate and more costly consultancy could have a real Business Value Proposition.

Not all cheap proposals are risky
There are exceptions to the rule cited above.
My experience as consultant reveals some real world cases of cheap but good for the customer bidding. Following description of three examples: 

1.    The customer does not need the functionality
One of two competing products price was about 10 times higher than the other product. It is true that the second product was a better product including a lot of functionality missing in the other product. However, after I analyzed the customer requirements and wish list for the next three years, I concluded that the customer will use only the basic functionality included in both products.
My recommendation was: Buy the cheap product and use it.  The product could be replaced by the second product after three or five years, in case of a need to use extended functionality. It should be noted that it is not a development tool but a product which is used by only three or four employees, so training costs are not significant.
 
2.    First installation in a country
On product is a well established product with large installed base in a country.
The other is a newer and better product, but has no installed base in the country (There are already success stories in other countries).
The price could be cheap because the vendor must show reference sites in the country in order to sell it and its local team need a real world hand on experience. 

3.    Change of Distributors
A global vendor is an acquisition process of another vendor (common phenomena. See for example previous post: vendors Survival: Guide Supermarket Grocery and Kiosk).
The distributor learned that the result of previous acquisitions was a different distribution and support model: The local branch replaced the local distributor. The distributor may try to sale quickly as many instances of the product, before losing the business. He is ready to sell a good product in a low price, provided that the sale process time is short. 

Consulting Large firm vs.  Boutique firm  
As an Independent Consultant I competed with large firms. In many cases they won because the customer thought that they provide the same quality service for higher price but for reduced risk (and because their teams included professional sales man and I am an expert and not a sales man).

ZapThink's Zapflash shows that in many cases a Boutique firm consultancy could be better than a Large firm consultancy. In the end of the day the client relies on the skills and experience of the actual consultant providing the service. The additional resources and the large company's knowledge base not always compensate for the skills gap between that consultant and a Boutique firm Consultant or Independent Consultant.

Another issue is conflict of interests. A Middleware solution selection consulting assignment I won competing with a large vendor is a good example. 
I could not care less, which product will be selected as long as it is the best fit for the customer's needs.
Unlike me, the large vendor was one of the distributors of one of the products. In addition to choosing a product, the vendor aimed at executing the installation and assimilation of the product, to running projects based on the selected product and saling related software products.

The third question to ask: Which SOA Consultant to hire?
In most cases you should hire a SOA consultant with a deep understanding and a lot of experience. Avoid of choosing consultants having conflict of interests.
Do not hire the cheapest available SOA consultant.
The reality is that in many cases enterprises are choosing inadequate consultants. A survey finding showing that 4 out of 5 SOA implementations failed supports my case (and it does not matter if the survey is inaccurate and the real figures are one of two instead of 4 of 5).

The most difficult case is the half baked cake case, i.e. an enterprise, which is already executing a SOA initiative and looks in this stage for a SOA consultant.
In this situation the consultant needs profound understanding of SOA and creativity not only for doing it right but also for correcting mistakes that were done.

The End of Load Balancing?

IT implementations Complexity is growing consistently. The reasons for the growing complexity includes: additional types of functionality (e.g. BPM, Internal Social Networks as part of Enterprise 2.0 implementations etc.), Infrastructure heterogeneity, enhanced collaboration (Social Networks, Instant Messaging, Contact Centers etc.), Usage of Web and Multi-Channel e.g. enhanced Cell Phones applications usage) and implementations beyond enterprise boundaries (e.g. Cloud Computing, Supply Chain Management).
The issue of complexity is described schematically in the illustration above. The idea is to reduce complexity and in the same time support growing heterogeneity and functionality.
Abstractions are used frequently for hiding the complexity. For example SOA hides from Business users the technical details of service implementation; Virtualization hides the physical hardware configuration used by the Operating System instances.
Load Balancing complexity is growing the same as complexity of other aspects of IT systems is growing and it is reasonable to think that Load Balancing complexity could be handled by Abstraction like other IT Complexities.
Although Abstraction is a common practice in modern IT systems, one of its major disadvantages could be poor performance. It is not only due to the overhead required for supporting the abstraction level. It could also indicate a less than optimal Deployment. Hidden Complexities do not vanish, they are just hidden and the mechanisms behind the scene should handle properly all aspects, including performance.
We often experience poor performance of SOA services because this aspect is not addressed properly.
Load Balancing is an old a common way for performance optimization, by dividing workload between multiple instances. Workload division between instances mechanisms can be augmented by changing the number of instances in accord with workload changes. However, Gartner Inc. analysts view is that Load Balancers are Dead, which is their way to say that most enterprises Load Balancing is not done properly. This message is shared by few Research Notes I recently read.

Mile stones in the history of Load Balancing

•    Balancing different workload types in a single Mainframe

•     Balancing workload of different Mainframe hardware and peripheral equipment instances: Mainframe computers, IO channels and IO Control Units and network equipment

•     Load Balancing of Hardware Servers

•     Load Balancing of Networks

•    Load Balancing of Application Servers instances

•    Load Balancing of Web traffic
  

The Main issues in Current Load Balancing Practices

•     Traditional Load Balancers can no longer address properly the complexities and heterogeneity of Enterprise systems. That why Gartner's analysts declared that the Load Balancers are death.

•     The load is increased by new developed applications or increased usage of current applications. The Network team may not be aware of these changes created by IT Developers or Business Customers. It should also be noted that Web Applications and SOA Services usage is less controlled than traditional silo applications usage; therefore the workload level is less predicted and more dynamic.

•     Security issues requiring separation of communications workloads within the Demilitarized Zone (DMZ) and outside the DMZ.

Alternative Approach
Gartner's analysts recommend usage of Application Delivery Controllers (ADCs) supplied by vendors like F5 and Citrix. These ADCs take care of the Deployment as a whole including Load Balancing.
They also mention that many enterprises already installed ADC products, but still use Load Balancers instead of the equivalent and superior functionality included in the ADCs.  

My take

•  Service implementations are encapsulated. Part of the Service implementation or the whole implementation could be replaced by code and data in another environment (for example, replacement of Legacy application by JEE or .Net application). The change is transparent for the service users. The people responsible for Load Balancing could miss this change and the load balancing procedure will be inefficient. A more holistic view of Deployment by using ADC probably will take this change into account.
  

• ADCs are Abstractions of Load Balancing for modern IT architectures. Actually they are more than just Load Balancers abstractions; they are addressing and hiding many other deployment complexities, such as Security issues and Services deployment processes.

• If Gartner's analysts' analysis is correct we are approaching to the death of Load Balancers. However, it is not the end of Load Balancing. Automatic, dynamic and more sophisticated Load Balancing will be performed by more strategic tools (ADCs) together with other Deployment tasks.

•