TIES Project Plan

Print this Page	The Import-Export Service...	1.6 Architecture 08. TIES Project Plan	TIES Application Service...	Close this Page

1.6 Architecture: 08. TIES Project Plan:

1. The project is fragmented into an initial proof-of-concept step on a small application to be followed by the major step to migrate many associated applications. Clearly, the major migration step is dependent on the initial proof-of-concept step.

2. The initial proof-of-concept step is a two phase project plan with an interim executive review and decision point.

3. The first phase is to do detailed Function Point Analysis (FPA) on the legacy source codes with an objective to present an Executive Financial Plan.

4. The second phase is the migration project to generate the scheduled deliverable according to imposed policies of a technical architecture.

2. Glossary:

TIES means "The Import-Export System" as an internal supplier tool to decompose legacy software into a specification of Requirements and generate applications in a target language.

UAT means "User Acceptance Trial" where the customer tests the demonstrable application to identify and report problems.

FPA means "Function Point Analysis" as the methodology used to measure the size and complexity of an application so a commercial project plan can be formulated.

SoR means "Specification of Requirement" as an interim review and revision point in the import-export migration plan.

IRDS means "Information Resource Dictionary System" as the way the Specification of Requirement (SoR) is documented and available for maintenance.

Eliza is the name of the artificial intelligent assistant that is at the heart of TIES to do the import and export migrations.

3. Parties:

1. Every TIES project has two parties as the customer and the supplier. Both parties know who they are and so for security purposes, the names of the parties is not disclosed. Both parties agree that they shall not disclose the name of the other party without prior written agreement.

2. Owner shall mean the customer who owns copyright and intellectual property rights in all the legacy and migrated bespoke applications.

3. Application Service Provider (ASP) means the supplier who delivers the bespoke applications in return for a modest and fair fee.

4. Owner holds all copyright and intellectual property rights to the legacy and migrated application data, source and documentation. Owners copyright and IP rights extend to all derived, transformed, summarised, extracted and projected data. Owners copyright and IP rights include all test data, test scripts, test procedures and all associated documentation.

5. ASP owns many racks of servers in many secure data centers that are used to provide the TIES application service. ASP own an artificial intelligent assistant (expert system) known as ELIZA that is used at the heart of import and export transformations.

6. TEN50.CO.UK or XSOR.CO.UK is an arbitrary project name used for secure communications between the parties for the duration of the project. Everything the owner can see on this private web site is owned by and may be copied the owner. All documentation, application models and test data that is shown are the property of the owner. ASP shall defend the right of the owner and shall use its best endeavours to help the owner to access its application data at any time.

4. Function Point Analysis:

1. Legacy source codes are reverse engineered using import rules to build the Information Resource Dictionary System (IRDS) - the business requirement as an application model.

2. The mission is to extract the core business requirements from source code files with sufficient detail as the whole specification of requirements and application model.

3. The prototype application model is used to measure cost, time and quality of optional deliverables.

4. Verification is provided as a demonstrable application that can be User Acceptance Tested (UAT). Errors and omissions can be reported using the online forms so corrections can be applied as examples of a potential maintenance cycle.

5. The specification of requirement is provided as a working application that can be interrogated, inspected and changed. Requirement changes are applied as an example of the potential improvement cycle.

5. Executive Review Presentation:

1. The objective of the initial FPA phase is to present a detailed and justified cost, time and quality planned options.

2. Online access to the demonstrable application enables UAT to take place to prove that the entire scope of the specification of requirements is complete and correct. Changes to the specification demonstrates the kind of maintenance cycle that can be delivered.

3. Online access to the specification of requirement documentation enables quality and technical architecture factors to be varied to demonstrate the kind of improvement cycle that is involved. Documentation exists for demonstration purposes only and is expected to evolve in phase 2.

4. Typically three options are planned as:-

Plan A: Do Nothing; the baseline cost of doing nothing will have continued costs, continued risks and potentially higher migration costs in the future.

Plan B: Short-Term Deliverable; the export of a specific deliverable language according to a specific technical architecture has a capital cost, a deployment cost, a maintenance cost, an infrastructure cost and an operational cost; until the next expensive migration event when the deliverable language becomes obsolete.

Plan A: Long-Term Service; the provision of a fully working bespoke application service with continual improvements has a monthly subscription fee, but no capital investments, no maintenance costs, no hardware infrastructure costs, no backup-recover-restart operational costs, no technical risk and the software will never expire with the need to be migrated again.

6. Migration Project:

1. TIES import and export rules are used to generate the scheduled deliverable using any number of languages.

2. The deliverable is tested according to whatever test data and test scripts have been created.

3. Where the bespoke application service has been scheduled, access is granted for User Acceptance Testing with online problem reporting and problem correction.

4. Where a deliverable language has been scheduled, the source code files are provided for configuration, deployment and testing. Errors and omissions can be reported using the online forms so corrections can be applied replacement source code files provided.

7. Intellectual Property Rights:

1. All legacy source code is the property of the customer and all information derived as documentation or source code is the property of the customer.

2. The first payment made by the customer and acceptance by the supplier is the contract to deliver the scheduled deliverables and a formal transfer of ownership of all intellectual property in the source code and documentation provided.

3. The supplier shall defend the customers Intellectual Property rights to supplied documentation and source code.

4. The supplier owns their own import and export expert system rules that will never been seen by the customer - TIES is a service to be used not a product to be sold.

7. Motivations:

1. In an honest, open and transparent way, the motivations of each party may be documented as part of the projects risk assessment.

2. The customers motivation is a simple cost-benefit - the cost must be well below the benefit. Where the cost exceeds the benefit, then plan A to do nothing is viable and any planning work is written off.

3. The customers motivation to select plan B or plan C may be driven by capital investments, risk analysis or short-term comfort factors. Plan C reduces all risks to a modest monthly operational fee with a simple option to revert to plan B at any time in the future. Plan B matches short-term expectations, but is heavy on capital investment and new software will eventually become legacy and needs to be migrated again.

4. The supplier must devise a viable cost-benefit plan or plan A will cause any function point analysis work to have to be written off. The supplier has no preference for plan B or C - either are viable and the customer is free to choose what provides the best cost-benefit. The supplier gains short-term revenue from plan B with the deliverable of source code that others operate. The supplier gains long-term revenue from plan C with a bespoke application service based on a modest monthly subscription.

5. Experience indicates that the majority of customers evaluate the monthly operational cost to have a better cost-benefit than the external capital investment together with in-house operational costs. Risk analysis indicates that a monthly service carries small risk that is reversible, while the delivered software carries a larger risk and is expensive to reverse.

8. Comparison:

1. Plan B involves the extra cost of in-house maintenance staff using in-house infrastructure, licenses. It is hard to deduce the extra costs to the customer, but annual maintenance is typically 25% of the new development cost. New development cost is £195 net per day and one day will deliver between 15 and 30 function points (depending on language ranking). A modest application of 1000 function points will be developed in 52 man-days for £10,000 net as a capital investment. A developer worth £195 per day earns revenue of £39,000 per year as 200 working days - salary is £24,000. In-house maintenance will have a direct cost of at least £20,000 per year.

2. Plan C is a fully inclusive bespoke application service that includes continual improvements without any capital costs, without any infrastructure costs, without backup-recovery-restart costs, without business continuity costs, without data protection security costs. A modest application service of 1000 function points will be provided with continual improvements for £295 per month - £3540 per year as an operational cost. The reason is that all infrastructure costs are shared by a large number of commercial customers - a £10,000 pentest audit split between 200 customers is only £4 per month per customer.

9. Background:

1. More than a decade ago, a large number of customers were in a very similar proprietary architectural dilemma to what you have discovered. The solution taken by most of the worlds corporations was not to migrate from one proprietary architecture into another proprietary future dilemma, but to eliminate such traps with International standard open-source cloud-based applications.

2. The kinds of benefits discovered included a ten-fold reduction in maintenance costs and a ten-fold reduction in operational costs. An application costing £2500 per month to maintain, could be reduced to £300 per month - with corresponding rapid delivery. An application costing £400 per month to operate, could be reduced to £50 per month with less patching, less license management and less downtime.

3. International standards have now evolved with languages like HTML to replace all previous proprietary languages - even proprietary product vendors. It is expected that in the next decade, all existing proprietary architectures will be replaced with HTML based architectures. The cost-benefits are overwhelming so simple economics will reward those companies that can cut their cost of doing business and will penalise those companies that retain proprietary solutions. The evidence of this HTML trend is beyond question.

Document Control:

2016 Sep 23 : Latest edition as page 161708. Part of common ITIL Architect responsibilities.

Documentation as Specification of Requirement: