Skip to main content

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.

Comments

Popular posts from this blog

The mainframe: still alive and kicking

Recently, I was interviewed by  Pcon   (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems.  Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts. They publish the results of the investigations including practical recommendations. This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published.    What are Legacy Systems? The term Legacy Systems refers to old application systems and/or veteran technologies still in use.  Usually, the term Legacy Systems is associated with: 1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400   Operating System. 2. Development and Production Environments, e.g. COBOL , Natural and DBMS systems such as Adabas  ...

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT , but the gap is still as wide as it was. In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed. SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value ( Agility and Reuse )  in most enterprises,  the large Business-IT Gap remained as large as it was.  The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement.  Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article  titled: Stop doing what the vendors tell you, CIOs told , published in  Tech Republic , suggests that the root of the problem is not Technological .   Stop Doing What the vendors Tell You Nick Heath's article is based ...

Vendors Survival: Will Software AG Survive until 2019?

This post is another post in the Vendors Survival series following posts on Microsoft , Google , HP , Sun and EMC . On July 14 th Software AG and IDS Scheer announced that Software AG is going to take over IDS Scheer . The intended acquisition is an opportunity to add another post in my Vendors Survival posts series. A brief history of Software AG Mainframe products Software AG is larger than any German software company except SAP . It was established in the Mainframe age (in 1969). I worked with many customers, who used and some of them are still using, its two flagship products Adabas and Natural . Although these products support many platforms, their main platform is IBM Mainframe. Adabas is a database and Natural is a development environment. Like other pairs of Database and Development Environment in the mainframe environment (e.g. Ideal and Datacom , Mantis and Supra) build by the same vendor, they are tied together. As a result, although it is possible t...