Skip to main content

Is it reasonable to use Obsolete Platforms as part of SOA?


-->
One of SOA's Value Propositions is platform independence. Some people's view is that SOA is a collection of Lego like services connected together as Black Boxes so it does not matter, which platforms and technologies are used for service implementations. Although the Lego analogy could be useful, it is sometimes too simplistic.Usgae of Obsolete Platforms as part of your SOA can demonstrate the limitations of platform independence in SOA implementation.

Obsolete Platforms are platforms near the end of their Life Cycle. They are characterized by lack of new installations, gradual migration to other platforms and slower development and updating of the platform's software.
In previous post titled Mainframe and the Dinosaurous Myth, I discussed Mainframes as a full participant in the SOA implementation. Make no mistakes, Obsolete Platforms are not z/OS, CICS or DB2 and therefore probably will be at best partial participants.

Technical Considerations
The main technological considerations are:
  • The applications are Monolithic Legacy applications.Identifying services within these large monolithic entities is a very difficult task. Extracting services is usually even more difficult, requiring complex reengineering or wrapping entities. The wrapped entities may be too large including more than one service.
  • The architecture is Tightly Coupled so implementation of Loose Coupled SOA is costly and difficult. Loose Coupling is not a must, however the majority of modern SOA implementations (especially Web Services Framework SOA implementations) are Loosely Coupled.
  • Lack of SOA products and tools
Most vendors' products support only frequently used platforms. Supporting Obsolete platforms
requires technical efforts and building marketing and sales channels. Potential revenues may be too small
for justify these extra expanses.
  • Limited support of Web Services
There are three elements of "Limited support" in this context:
1. Fewer Web Services standards are supported
2. Current Web Services standards version may not be available
3. Implementation is not based on code generation and may require complex and potentially error prone
coding by infrastructure programmers or application programmers.
Key Considerations
These considerations are usually more important than the technical considerations.I will demonstrate it by example.
Many years ago my responsibilities included Capacity Planning and Hardware upgrades decision of an MVS (the origin of z/OS operating system in the eightieth and ninetieth of the previous century) Mainframe installation servicing more than 3,000 users, therefore I knew quiet well Mainframe computers capabilities and prices.

As a consultant to a Data General (DG) installation using its proprietary operating system, I was surprised that the price of a new computer was a lot higher than the price my installation paid for IBM Mainframe. The number of users in the Data General installation was a lot smaller than the number in the MVS installation same as the number of online transactions so the required computing power (Processor, IO, and Memory) in the Data general installation was a lot less than the power required in the MVS installation.

Why was the DG computer so expensive? It was an Obsolete Technology.
The price tag was based on two factors: It was a n Obsolete technology so the company did not plan to sale other computers in two or three years after that deal and the customer was locked in, so he has no other choice.
Unsurprisingly, the price of more powerful DG UNIX server was about 20% of the price of the proprietary DG server. The customer had a choice (IBM, HP, Sun etc.) and the vendor expected to sell additional computers.

As illustrated above, the first consideration is high Software and Hardware costs. The second is high maintenance costs (including maintenance fees and electricity). You also should expect monotonic growth of maintenance fees.
The third consideration is diminished skills.
The bottom line is that a SOA implementation based on Obsolete Tchnology will be a costly and a slagish implementation
What is the real Value Proposition, if any?
The real issue of Obsolete Technology based systems is a choice between bad and worse alternatives. You should choose the least harmful alternative.
In some cases in spite of the cited above technical limitations, it could be SOA implementation based partially on Obsolete Technologies.

The advantage of it in comparison to Big Bang migrations or continuous deployment of Monolithic Obsolete systems is the ability to migrate gradually and smoothly by taking advantage of the relatively independence on platforms and Service and Consumer loose coupling.
Labels:

Comments

Post a Comment

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  ...
16 comments
Read more

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 ...
11 comments
Read more

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...
8 comments
Read more