Reuse – easy to say hard to use

Reuse is often cited as a major SOA benefit and justification. It is easy to explain and to understand Reuse Value Proposition in IT and Business perspectives.

Services and Processes Reuse reduces Maintenance & Development costs, enable shorter Time to Market and is a key for building applications through assembly of existing Services by non-IT employees as mentioned in my first Web 2.0 for Dummies post .

Understanding, Reuse Value Proposition is not enough for realizing the benefits.

A SOA initiative without Reuse or with a low Reuse Ratio is doomed to failure.

According to many analysts' reports, NIH is a consideration of some software products they analyze. NIH, stands for Not Invented Here. As most of the analyst firms' headquarters are in the largest market i.e. USA, it stands for software products build by companies in other parts of the globe. For example, Fujitsu's excellent BPM suite invented in Japan or many years ago Dynasty one of the best Client/Server IDEs developed in France.

Some enterprises, I know extended the NIH concept significantly: the H (Here) stands for another department in the same enterprise or even another team in the same department.

I am sure that implementing SOA Reuse in an enterprise of that kind is almost impossible mission.

Creating a Reuse Culture is the key challenge for almost any enterprise implementing SOA. For enterprises having the extended NIH culture it could be the main reason for failing SOA initiative. They should change their Maturity Level prior to initiating their SOA initiative.

On the other hand Service Reuse is probably not as difficult for enterprises which already experienced other Reuse types such as: Objects Reuse in Object Oriented or Components Reuse in Component Based Development.

Key Reuse Success Factors

1. Reuse Culture

This challenge was partially discussed in the beginning of this post.

Employees in an enterprise adopting Reuse Culture will constantly prefer usage of existing assets

(Services) over building new assets.

The assets included in the Services inventory could be assets invented here as well as NIH assets i.e.

Business Partners Services and SaaS services.

It should be noticed that Reuse requires different budgeting and accounting patterns. Departments using Services developed and/or maintained by another department should participate in these activities costs.

The rewarding schemes should also be changed: rewarding some of the less productive IT employees (in terms of writing programs) instead of the most productive (e.g. developing a large amount of programs or systems).

These "less productive" are actually more productive they Reuse instead of building new programs.

2. Management

Services functionality should be published and managed in order that any potential user could think of

reusing them. Technically, the meaning is usage of easy to use Service Repository.

It also implies a new role: An expert of Service inventory. Systems Analysts should consult him for

matching Services to their systems.

Management in this context also implies Change Management.

For example, unifying of functionality of a bank branch and bank customers via internet by building a

common service, may require a decision about change frequency. The more dynamic internet channel

may require frequent changes, while the conservative and robust branch change rate is slower.

3. Service Boundaries

Facilitating Service Reuse is dependent upon services granularity and boundaries. Business defined

boundaries are a key for high reuse ratio.

Some SOA implementations are only Service usage by Multi-Channels. In that case Legacy Services

granularity could be too coarse.

4. Extensibility

Services should be defined with future usage by other applications in mind.

In many cases Service Reuse by other applications will require some modifications or extensions and a

new Service will be built instead of reuse in case of hard to extend or change services.

5. Measurement

I participated in a presentation by a large enterprise describing its ESB based SOA implementation.

Talking to this enterprise SOA evangelist I tried to figure out the real advantages. "We did not measure it" was the answer to my question: What is the service Reuse Ratio in your SOA implementation?
Service usage should be measured systematically. The measures could identify Services which are rarely used, services that are used only by a single

-->application or single channel or single user (i.e. no Reuse or low Reuse rate).

The end of Monolithic Office suites?

-->

In previous post I compared Microsoft's Office 3.1 Word to Microsoft's Office 2003 Word.

-->

Many people would argue that the comparison is meaningless: IT is evolving and a version ten years younger is surely better. It includes enhancements based on experience and users requirements and bug fixes and evolution of the vendor's infrastructure and techniques.

Let us ask another question: Which Microsoft Windows Operating System is better XP or Vista?

I am not sure that experts will agree that the newer Vista is better. I would suspect that even the vendor's experts opinions vary: some Microsoft's experts probably will argue that XP is a better operating system. The popularity of a downgrade option to XP is another indication that Vista may not always be better than XP.

-->

The speculations about Microsoft's intention to skip Vista's evolution and release Windows 7 earlier than planned could sustain my thesis: Newer products versions are not necessarily better than their predecessor.

Limitations of new Office versions

A new version implies new income by user license upgrades; therefore Microsoft releases new versions in cycle of about 2 or 3 years between versions.

But in order to release a new version, a vendor needs a significant product change which can justify it.

A significant change is in most cases enhancements: new functionality in existing components or new product in a suit.

New functionality or new product implies additional code lines.

It is easier to add functionality than to omit unused functionality; therefore omitting functionality, included in previous version, is a rare procedure.

The result is code lines number increase and complexity and gradual increase of maintenance difficulty.

According to research the number of bugs is roughly proportional to the number of code lines.

Complexity means instability and errors.

We as application suits users paying the price of this vicious circle.

Isn't it the time for a model change?

-->

An Alternative model by example

The poor Spell Checker discussed in previous posts Microsoft's Word: 3.1 vs. Word 2003 and Zen and the Art of MS Office Problem Determination could serve as an example of an alternative model.

-->

I need only English and Hebrew support in at least 99% of the time I am using Word.

I would guess that many other users need only dual language support: usually their native language and another language.

I do not need an abending Spell Checker sending error messages about Portuguese support, a language which unfortunately I do not know and do not use.

-->

I need a Service based model instead of a product. Word should include only core functionality and definition of services and an easy standard way to plug them into the core functionality.

In that case I could use Microsoft's Spell Checker with Microsoft's Word or another Spell Checker developed by one of the vendor's partners. SOA based design will enable replacement of one Sell Checker by another almost transparently.

I would expect that a service by a partner which supports only the two languages I need will be better than Microsoft's service supporting many languages, but as long as Microsoft's service will be good enough many people will prefer to use it instead of a marginally better service by another company or Open Source.


-->

Benefits of the Alternative model

The benefits are very similar to some of SOA benefits:

1. Easier maintenance – the vendor will be able allocate less resources and produce better artifacts due to the reduced complexity.

2. Users could install or use in a SaaS model only services they need.

3. Competition is a trigger for better quality with reduced costs for users.

4. Flexibility: instead of one size fits all products, availability of more specific services for specific requirements types.

Concluding Remarks

• You can easily extrapolate this discussion to other applications such as SAP applications or Oracle Applications.

• I hope that this post provides some insights of SOA benefits for Application Suits.

• Application Vendors are building SOA Ecosystems replacing the traditional ERP and CRM systems, which were built for efficient Operation and not for Agility.

: Microsoft's Word: 3.1 vs. Microsft's Word 2003

The question which Microsoft Word product is better seems ridiculous.

We expect an evolution and improvement of a software product.

Microsoft produced Office 95, Office 97, Office 2000 and Office XP. All these versions followed Office 3.1 (which was produced in the beginning of the nineties under Windows 3.1 Operating System).

The answer is not as simple as the question. Probably Word 2003 is better unless you use a spelling checker for documents including text in more than one language.

Maybe Word 3.1 spelling checker is functionally limited and not user friendly but at least it is doing the job.

Using spelling checker in Word 2003 could lead to unpredictable results: Sometimes it will do the job and sometimes a buffer overflow will cause abnormal end of Word.

The post titled Zen and the Art of MS Office Problem Determination in my blog was relatively popular and some of the readers added comments. The reason for the relatively large number of readers is simple: many people experienced the cited above problem and no patch by Microsoft solved it.

I thought that bypassing the problem by excluding the dictionary and the spell checker is not the best solution. When using this bypass, spell checking procedure included the following steps:

1. Select the whole Word document.

2. Cut it.

3. Pace it into another application e.g. as draft post in Blogger.

4. Execute Spell Checking.

5. Correct spelling errors.

6. Copy the text back to Word.

The most common ways to solve a problem in Windows without problem determination are: apply updates, boot and install again.

Those of you who read my Zen and the Art of MS Office Problem Determination post, know that booting and installing patches did not address the problem. Ii tried reinstalling Office.

As long as the spell checker was deactivated Word was functioning perfectly. Even after activating it and checking an English document it was still functioning according to my expectations. However, when I opened a mixed English and Hebrew document it immediately abended. It was a partially predictable result; any time I opened this document Word immediately abended.

My Take

After succeeding to circumvent the problem, I can summarize my insights as follows:

• Reinstalling did not solve the problem.

• I was not able to find the common denominator for the documents causing Word ABEND. All of them include text in English and Hebrew but no ABEND occurred while opening other English and Hebrew documents. I assume that there is a positive correlation between document size and ABEND occurrence.·
  

• Does changing Options to activate or deactivate the spell checker is affecting only the open document or all Word documents in a computer?

I do not know. After activating this option in one document other documents abended. Deactivating

this option after opening a document which abended does not help. After opening the first document in

which the activation occurred and deactivating spell checker, no dual language document cause ABENDs.

• You can safely spell check an English document, but do not forget to reset this option after correcting the spelling mistakes.

Oracle's BEA acquisition SOA perspective – Revisited again

A Keynote presentation titled Oracle Fusion Middleware and BEA:
an inside Look – Product Strategy, may clarify some of Oracle's SOA directions discussed in a post immediately after the acquisition and a follow up post.

It is a presentation on SOA products strategy as well as to other related products strategy.

The approach is to define mix of BEA and Oracle products as strategic components composing Oracle's SOA platform.

The leading brand name is Oracle Fusion., however in some areas Oracle offerings include two competing products: Oracle's and BEA's. In other cases one of product is a preferred solution.

The most relevant slide is presented above. This slide presents a SOA suit.

In my opinion, although quantitatively more Oracle components are included, the most significant elements are BEA's products. The ESB is BEA's Aqua Logic and Complex Events handling is based upon BEA's product.

It should be noted that not all SOA infrastructure products are included in this slide. The missing parts include Repository and Registry, SOA Governance tools, Data Integration and Application Server and Portal.

According to my understanding of the keynote presentation slides, the directions are:

• BPM suite is based upon Aqualogic BPM suit for Design and Execution. BPEL, BAM and Business Rules are based on Oracle's product.

• BEA Web Logic Integrator is not a part of the suite. Although according to another slide it is not yes in maintenance mode, I completely agree with recent Forrester Research's BPMS market analysis (Integration-Centric Business Process Management Suites, Q4 2008 by Ken Wollmer) referring to it as a risky product.

• Application Server suite is labeled Oracle WebLogic Suite. No doubt that BEA's WebLogic Application Server is the strategic solution although oracle Application Server is included in the suite.

NESSI Israel meeting Presentation

I presented in a meeting on September 14^th about NESSI Israeli Mirror Platform establishment.

About 40 people from various Israeli companies participated in the meeting titled:

NESSI- Service Based European platform for Leveraging Research & Development

NESSI (Networked European Software & Services Initiative) is the European Technology Platform dedicated to Software and Services. The main focus of NESSI is that of service.

See the agenda of the meeting.

The post includes my presentation in that event titled:

NESSI – Is there a Vlaue Proposition for SOA in Israel

Vendors Survival: Will Google Survive until 2018?

Google is celebrating this year its 10^th anniversary. Google is the most typical Web 2.0 company (see my post Web 2.0 for Dummies part 4).

It is a very successful company, changing the IT industry as well as the Web culture.

Will Google celebrate it 20^th anniversary in ten years or will Google vanish?

Most people's opinion is that Google will continue to dominate its traditional business areas and probably expand its business to new domains.

Recently I read the book The Google Story by David A. Vise and Mark Malseed.

It seems like this interesting book is biased. It is pro Google. However, the company earned my sympathy.

Two Stanford doctorate students (Larry Page & Sergey Brin) working hard trying to build the best search engine. Their motives are more scientific than becoming rich as soon as possible. They were paving a unique lane, different from most Dot Com companies, insisting on uncommon ideas (e.g. loading the Web content into their GooglePlex).

My sympathy (as well as other people's sympathy) is not a survival guarantee.

My opinion is that the probability that Google will survive is high but it is less than 1.0 (less than 100%). In order to assess its prospects to survive, I will deploy the same approach I used many years ago to asses Microsoft's survival until 2005.

The approach is based on the following assumptions:

1. There is a small probability higher than 0 that the company will not survive.

2. A crisis will happen (e.g. Business Model change).

3. The company's ability to adapt to the crisis will decide its fate: survival like IBM or HP in the nintees or end of life same as DEC.

Based on the assumptions, I will try to analyze Google and possible future threats.

Google in a nutshell

• The leading Web Search Engine in the market deploying a unique algorithm for ranking search results (Page Rank)
• A very popular brand name turned even into a slang word googling. Googling is searching for information in the Web.
• The Web as a platform – no Google platform
• Variety of Web based services
• Web 2.0 model of participation and trust
• No fees for using services
• Unique leading advertising model: the Ads are not disruptive and look like an content extension, Ads are related to content, Payments based on clicks on Ads, Sharing revenues from Ads with partners placing Google Ads in their Web Pages.
• Googleplex – a unique and powerful blend of hardware and software
• Innovative & Quasi academic: 20% of employees' time devoted to research activities on any topic the employee chooses - The Company as multi startups.
• Attracting the best computers engineers an programmers by intellectual challenges and friendly environment
• Slogan: Don't be Evil

Bullets marked in blue describe attributes and attitudes which are reasons for my sympathy to Google.

Possible Threats

One obvious threat is a significantly better Search Engine developed by another company.

I do not think it is the major threat.

In that case, if Google could keep its Online Ads dominance it may survive.

Google can sign an agreement with the other company applying its Ads to the other search engine so both companies continue to grow.

Actually, Ask Jeeves claimed that its Teoma based search engine used a better search algorithm (more sophisticated ranking algorithm). Ask Jeevs is using Google Ads.

Do not assume that a significantly better Search Engine necessarily implies a bigger Search market segment. Many technologically superior software products failed to lead in terms of market share.

In my opinion the major threat is failure of the simple and effective Google Business model.

The model is based upon payment per click by advertisers and payment per click by Google to its affiliates. Ads are content related and therefore generating more business deals or business leads in comparison to Ads which are not content related.

Ads revenues are Google's main income source

The model may fail in the following scenarios (as well as other scenarios I am not thinking of):

1. Sophisticated Click Fraud

Click Fraud based on intentional click on Ads which does not generate business or business

potential.This intentional clicking could be programmatic with no simple clicking patterns.

Advertisers will have to pay more for more clicks without generating more business. Customers

would abandon Google Ads in that case.

2. More effective advertising model by another vendor attracting advertisers

Other significant threats could be:

Threat 1: Loosing its image as the best company to work for

The reasons could be internal (Policy changing) or external (emerging of a more attractive companies).

Threat 2: Loosing its innovative spirit

Organizational culture could be changed. More established companies are usually more conservative. Google could be transformed to more maintenance oriented company.

Threat 3: expanding its business domains wrongly

A company releasing new services and enhancing current services frequently could expand its services portfolio to wrong domains.

In these domains it may encounter strong and established competitors or fail to produce good enough products. Is Chrome an example of a wrong service of that kind?

Google flexibility may enable it to withdraw unsuccessful services before they will damage its image.

Threat 4: Legal issues

• Copyrights violation issues

My postMy post Web 2.0 fragility: Viacom vs YouTube illustrates this issue by discussing a
lawsuit against a company acquired by Google. It is an issue in other Google projects such
as Google Book Search .

• Privacy issues

Google keeps plenty of information including private information e.g information in Gmail
messages.

Threat 5: Web X.0 (X > 2)

When Web 2.0 emerged, some successful Web 1.0 companies were not able to adapt to the new Web. Will Google adapt to a more Semantic Web?

Probably yes, due to its flexibility and creativity. But nobody could be 100% sure it will.

Threat 6: The founders

The founder ability to insist on their unique approach was so far an asset. For example, it differentiated Google from the Dot Com mainstream approach caused other companies to disappear. What will happen if they will be wrong and insist upon their way?

Will Google survive in 2018?

Google's organizational culture of permanent research and change enables it to be an adaptive and Responsive organization (transforming an organization to an Adaptive and Responsive Organization is one of the most important SOA Value Propositions).

The ability to keep changing while keeping its core advantages could be the reason why Google probably will celebrate its 20^th anniversary in 2018. However, the probability of its survival will be higher if it will handle properly a crisis.

Will it keep its 20% of employees time allocated to research during that crisis? Will it allow its engineers to choose freely the topics for that research during future crisis?

No one knows if it could and if it would.

Although there were some positive signs in past mini crisis (e.g. Microsoft's attempts to acquire Yahoo! and the privacy objections to Gmail service), the ultimate test is real crisis. I am pretty sure a crisis will occur.