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

1.6 Architecture: 09. TIES Application Service:
1. Every TIES project must be conducted as a compound documentation content management task.   The legacy source code can be treated as a kind of raw documentation to be transformed into an abstract application model and Specification of Requirement (SoR).   Target source code can be treated as a kind of raw documentation that is derived from the Specification of Requirement (SoR).
2. Secure communications must be established between Owner and ASP.   Private, confidential and sensitive business information must be encrypted at all times.   Telephone and email are no longer fit-for-purpose to communicate private, confidential and sensitive business information.
2. The Specification of Requirement (SoR) is available or interogation, validation and correction.   Errors of details and errors of omission are likely and care is needed to minimise the impact of this kind of error.   Errors of syntax or logic are unlikely where proven technical architecture policies are deployed.
3. Application services are provided to approve new people and revised existing people in how they access the project documentation.

2. Specification of Requirement: (SoR)
1. The objective is to document the application in sufficient detail that the whole application can be delivered to demonstration quality with reference to a technical architecture.   The SoR is an application model stored in an Information Resource Dictionary System (IRDS) that includes:-
  Entity is any logical group of attributes - many types of entity exist.
  Attribute is any elementary unit or instance of data. Attributes may be further defined by permitted values and derived functions.
  Relationship is any natual navigation between entities.
  Function is an event with a process that may transform a pattern of data. Each event is a change in the pattern of data.
  Logic is is the derivation of an attribute or set of attributes imposed by a business rule.
2. The Specification of Requirement is stored in an ISO/IEC Information Resource Dictionary System (IRDS).   The IRDS stores the application model in a set of SQL tables and NOSQL files.

3. Technical Architecture:
1. The import technical architecture defines the policies that enable the legacy source code to be decomposed into its component parts that caused the source code to be written from its Requirements.
2. The export technical architecture defines the policies that enable the target source code to be assembled from the Specification of Requirement.
3. A technical architecture may include the following policies:-
  Language policy.
  Delete policy.
  Business Continuity (backup-recovery-restart) policy.
  Encryption policy.
  Privacy policy.
  History policy.
  Evidence policy.
  Maintainability policy.
  Reuse and Reusability policy.
  Access Control policy.
  Abuse policy.
  Authentication policy.
  Availability policy.
  Cyber Attack policy.
  Training and Education policy.
  Communication policy.
  Support policy.
  Security Control policy.
  Life Cycle policy.

4. Attribute Dictionary:
1. Every elementary field is a data attribute - the foundation building block used be every application.   By law, every attribute must have a purpose where that purpose that describes a person must have a purpose of that the person expected it be.   Harvesting and collating data for no documented purpose could be illegal.
2. An attribute has a fixed minimum and maximum length. A minimum length of zero signifies an optional value.
3. An attribute has a set of permitted values that may be fixed or variable.
4. An attribute that has a type as date or time has a fixed length and a fixed set of permitted values.
5. An attribute may have alternative names and titles that will change from time-to-time, but its unique identifier cannot be changed.
6. An attribute must conform with third normal form (TNF); in that it must be dependent on its key and nothing but its key.
7. An attribute has a primary edit type such as text or list, however this may be overridden in the context of an entity.

5. Entity Dictionary:
1. Every set of attributes can be specified as an entity.   Many different types of entity can exist such as layout, report or record.
2. A entity has a relationship with its attributes and that relationship can include position, size, theme, title and other properties.
3. Management information can be specified as a list of attributes that are shown as a spreadsheet with sort, filter, move, hide and show dynamic options.
4. Entity models help to specify the whole scope of the application - if the data is not specified, then it is not part of the application.

6. Relationship Dictionary:
1. Entities exist in a data model that shows the natural data hierarchy and relationship navigation between entities.   Many different types of entity can exist such as layout, report or record.
2. A entity has a relationship with its attributes and that relationship can include position, size, theme, title and other properties.
3. Menu navigation is expressed as relationships between entities as set of data.

7. Function Dictionary:
1. Functions are an event that triggers a process.   A process may display an entity or/and may change a pattern of data.   An event is a pattern of data that exists or is created by a process.
2. Every transaction creates an event that triggers a process.
3. Process-Entity matrix maps show how function access control and data access control may be deployed.
4. A process can only access and/or transform a specified attribute - if the attribute is not specified, it is not part of the application.

8. Logic Dictionary:
1. Logic is used to derive an attribute value from other attributes.   Complex logic is where more than one attribute value is derived by the same logic process.
2. Logic is expressed as UML (pseudo english) using assignments, loops and conditions.
3. Every logic is a process or related to a process.

9. Business-Rules Dictionary:
1. Where artificial intelligence like Eliza is deployed, then business rules that are derived from policies are specified.   A business-rule has two parts as (1) Cause (pattern of data) and (2) Consequence (process or function).
2. Eliza looks for patterns of data and does documented processes to change data according to business rules.   An Executive can define corporate policies and know that Eliza shall carry out those business rules with ruthless efficiency.   A business expert can define business policies and know that Eliza working 24*7 shall carry out those business rules on time every time.
3. Accountancy and back-office policies and procedures that are specified in detail are perfect candidates for total automation using Eliza.   Where a business person is good at defining the policies that they wish to be deployed, the Eliza is good at making those business rules happen with negligible cost at any time of the day or night.
4. Most companies have business rules, just that most people are not sure what they are and not sure if they are always implemented.   To gain a competitive advantage, a company may choose to use artificial intelligence before their competitors choose to use artificial intelligence to cut the cost of doing business.

Document Control:
2016 Sep 23 : Latest edition as (public) page 161708.     Part of common ITIL Architect responsibilities.


IRDS Dashboard:
2301. Links to specification fragments.
231. Attribute.
2315. Attribute by Entity List.
2317. Attribute Sheet.
2316. Attribute Form. 2365 Permitted List
2318. Attribute History.
2319. Attribute Archive.
232. Entity.
2325. Entity by Function List.
2327. Entity Sheet.
2326. Entity Form. 2315 Attribute List
2328. Entity History.
2329. Entity Archive.
233. Relationship.
2337. Relationship Sheet.
2336. Relationship Form.
2338. Relationship History.
2339. Relationship Archive.
234. Function (page).
2347. Function Sheet.
2346. Function Form. 2325 Entity List
2348. Function History.
2349. Function Archive.
235. Logic.
2357. Logic Sheet.
2356. Logic Form.
2358. Logic History.
2359. Logic Archive.
236. Permitted (option).
2365. Permitted by Attribute List.
2367. Permitted Sheet.
2366. Permitted Form.
2368. Permitted History.
2369. Permitted Archive.

Entity Dictionary: (231)
1. Reusable 1-22.
4. Entity Identifier.
23. Entity Type: TWIN, LOG (insert policy + delete policy).
23. Entity Secondary Key Number.
23. Entity Long Name.
24. Entity Short Name.
29. Entity Title: tooltip.
30. Entity Purpose.

Entity-Attribute: (231)
Spreadsheet to view all entity-attributes, filter by entity to view attributes (fields) by entity (record).
1. Reusable 1-22.
4. Entity Identifier.
5. Attribute Identifier.
6. Sequence: attribute in entity.
23. Attribute Type: see permitted values like LIST, TEXT, DATE...
25. Attribute Long Name.
26. Attribute Short Name.
27. Attribute Title as tooltip.
24. Minimum Stored Size: optional/required.
25. Maximum Stored Size.
26. Display Size.
31. Derived: counter, lookup, logic.
30. Purpose and Description.

Function (page) Cluster: (234)
Spreadsheet to view all page fields, filter by name to view permitted value by page.
1. Reusable 1-22.
4. Entity Identifier.
5. Function (page) Identifier.
23. Type: see permitted values like REPORT, PAGE, FORM...
24. Position: as NORMAL, PORT, LAND, SHEET.
25. Library code: as SUPPLIER, CUSTOMER, MADE, SALES.
26. Image name.
27. Long (subject) Name.
28. Short Name.
29. Title as tooltip.
30. Purpose.

Permitted Cluster: (236)
Spreadsheet to view all permited values, filter by name to view permitted value by attribute.
1. Reusable 1-22.
4. Entity Identifier.
5. Attribute Identifier.
6. Permitted Identifier.
23. Type: see permitted values like REPORT, PAGE, FORM...
24. Name of Attribute.
25. Code as token.
26. Sequence Number.
27. Long (Descriptive) Name.
28. Short Name.
29. Colour Theme.
30. Purpose.

Reusability Policy:
1. Primary Identifier.
2. Active Identifier.
3. Site Identifier.
4. Entity Identifier.
5. Attribute Identifier.
6. Permitted Identifier.
7. Function Identifier.
8. Relationship Identifier.
14. Usage counter.
15. Last Used Date.
16. Created Year-Month.
17. Last Change User.
18. Last Change Date.
19. Last Change Time.
20. Created User.
21. Created Date.
22. Created Time.

HRM Evidence.

Support Dashboard:
2201. Links to HRM.
221. Support.
2213. Support Request Upload.
2214. Support Reply Upload.
2215. Support List.
2217. Support Sheet.
2216. Support Form. 2213+4 Upload
2218. Support History.
2219. Support Archive.
222. Improvement.
2223. Improvement Request Upload.
2224. Improvement Reply Upload.
2225. Improvement List.
2227. Improvement Sheet.
2226. Improvement Form. 2223+4 Upload
2228. Improvement History.
2229. Improvement Archive.
223. Office.
2237. Office Sheet.
2236. Office Form.
2238. Office History.
2239. Office Archive.
224. Person.
2247. Person Sheet.
2246. Person Form.
2248. Person History.
2249. Person Archive.
225. Access.
2257. Access Sheet.
2256. Access Form.
2258. Access History.
2259. Access Archive.
226. Skill.
2267. Skill Sheet.
2266. Skill Form.
2268. Skill History.
2269. Skill Archive.

Support Dashboard:
223. New Person.
2235. New Person Request.
2237. New Person Sheet.
2236. New Person Form.
2238. New Person History.
2239. New Person Archive.
224. Forgotten (expired) PP.
2245. Forgotten PP Request.
2247. Forgotten PP Sheet.
2246. Forgotten PP Form.
2248. Forgotten PP History.
2249. Forgotten PP Archive.
225. Change (days or hours) Working.
2255. Change Working Request.
2257. Change Working Sheet.
2256. Change Working Form.
2258. Change Working History.
2259. Change Working Archive.
226. Change (dept or office) Place.
2265. Change Place Request.
2267. Change Place Sheet.
2266. Change Place Form.
2268. Change Place History.
2269. Change Place Archive.

Architecture Evolution:
1. A decade ago, every software vendor was selling client-server products, but today, every software vendor is selling cloud-based products.   Not a single exception can be identified who has not taken this evolutionary architectural shift.   Oracle sell every kind of CRM, ERP, HRM product and in turn, each have evolved from client-server to cloud-based.   Saleforce, SAP, IBM, BMC, HP, SAGE and even Dell are now selling cloud-based products rather than client-server products.
2. Evidence is clear that it is has not been possible to design a client-server product that will pass a PCI-DSS security audit and penetration test.   The reason is that encrypted communications is mandatory and when the encryption key is stored in the client software, it can be reverse engineered by a criminal who gains full access to the server.   Many tricks may be designed to try to fool the criminal, but these are delaying tactics, rather than an auditable security solution.   Any software vendor selling a client-server product that is not safe, not secure and cannot pass a security audit would be liable for significant damages.
3. Amazon web services exceed the capacity of its next ten competitors - it has proven that dramatic operational cost reduction is practical and can apply to the majority of corporations.   Simple economics have shown that the total cost of client-server infrastructure, maintenance and software may be many times greater that the functionally equivalent cloud-based applications.   One hundred years ago, every factory had its own expensive steam engine to power the factory, then cheap electricity became available to replace steam power.   Client-server is like the very expensive static steam engine to be replaced with cheaper cloud-based applications that flow everywhere like electricity.

Case Study:
1. An energy broker in Stevenage with 65 staff decided in 2010 to build their own in-house application systems to integrate earlier MS Office spreadsheets and macros.   Hardware and system software bids from Dell and HP showed that a rack of five servers with a UPS where needed to run email and the planned applications with a capital cost of £18500.   Replacement to more energy efficient machines takes place every four years. however many licenses are annual.   Microsoft Office, CAL and email licenses with Citrix for remote administration are managed for all desktop and laptop clients.
2. The client-server infrastructure was outsourced for professional patching and maintenance begining at £18500 per year.   Three internal people were assigned to develop their own CRM with interfaces to Sage and other energy management packages.   Ignoring management amd internal meeting costs, within a year that application was delivered for about £62000.   In practice, and because of changes in the company, maintenance costs exceed £40000 per year.
3. The company has changed dramatically in the last few years from an office full of desktops with a few laptops to most people using smart phones, tablets and laptops with just a few desktops.   Many people now do more business out of the office than in the office, working hours are more flexible and working location is flexible.   Citrix licenses and VPN routers for staff working from home is simply much more expensive, complex and error prone than web-based applications.   A new disruptive digital age has started that will cause all historical investments to be writen off and a new generation of cloud based services made available to people in any place at any time.
4. The client-server era was defined by periodic capital expendature, expensive license management and three dedicated IT experts to keep the business going.   Just the direct costs that can be identified in the accounts were £340,000 over five financial years - say 68K per year or £87 per person per month.
5. A cloud-based era has been strategically agreed with a target to half the IT cost to £44 per person per month.   This strategy means that staff can use any kind of desktop, laptop, tablet or smart phone, or any combination of devices from any location at any time.   The business will be able to support customers 24*7 and grant certain customers online access to their own energy accounts.   The company has already provided cloud-based access for certain energy suppliers to electronically bid for business - something that failed when Citrix clients were tried.
6. It will take a few more years to prove that total IT costs can be halved because the evolution is still progressing.   The cloud strategy has meant that capital expendature has been reduced towards zero and a consistent operational monthly budget has been fixed for the financial year.   It has already been said that the cost savings are not as important as the more effective and productive methods of working with many types of computing devices in so many new places.   New large power customers have been won because online access to critical energy usage information can now be provided with rapid bidding wars for the best rates from the energy market - such things were not possible before.