Portfolio Director

1. A role of the Portfolio Director is to direct application service provision (ASP) with reusable application meta data. Each customer enjoys a bespoke package of reusable application meta data that are configured with business rules to mirror the customers evolving business requirement. Each reusable application meta data is defined by Information Engineering Methodology (IEM) data in the portfolio catalogue. Each application service provided (ASP) is a mass of business rules supporting policies and procedures applicable to the business, but inside is the reusable application meta data.

2. Each Application Service Provided (ASP) is a package of many reusable application meta data portfolios using a folio manager. Bespoke business rules customise and configure the package to mirror the exact business requirements of the customer.

3. The role of our Portfolio Director is to strategically manage hundreds of reusable application components that have been built over many decades. For each data object, many business-rule driven functions can be enabled to deliver the correct level of functionality to the business.

2. Catalogue of Application Meta Data:

0. Common policies and business-rules.

1. HRM people centric functions.

2. QMS quality standards functions.

3. CRM customer and supplier centric.

4. FAM fiscal money and legal contracts.

5. Mail messages.

3. Trade Secret:

1. The inner reusable application meta data portfolio is a trade secret that most competitors have failed to invest in. While others write expensive bug-ridden software, the Portfolio Director invests in ever more productive application meta data. The result is that application services provided to hundreds of customers continually improve, never have software vulnerabilities and create valuable intelectual property. Intelectual property expressed as business rules that can be understood by Eliza the Artificial Intelligent Assistant have a life cycle of many decades.

2. Eliza is a trade secret in that every request for data that is made by a person is verified by Eliza and Eliza makes the decision on what to show the person. Eliza has access to all kinds of behaviour data to correctly judge what a person is permitted to see and do at time. While competitors suffer the problems of thousands of cheaply written software programs, Eliza is only concerned with data as all programs have been eliminated.

4. Portfolio Knowledge:

1. Name

2. Current status (e.g. Pipeline, Active (Service Catalogue), Retired)

3. Service Type

. 1. Business Service (visible to the customer) or Infrastructure Service (invisible to the customer, used as a building block for Business Services)

. 2. Internal/ external: Internally provided service or a service sourced from an external service supplier

4. Service Owner (responsibility for service provisioning)

5. Customers currently using this service

6. Contacts and procedures for signing up to the service

. 1. e.g. contact details of the responsible Service Level Manager

. 2. Procedure for signing up

7. Description/ desired customer outcome

. 1. Business justification (value added from a business point of view)

. 2. Business processes/ activities on the customer side supported by the service

. 3. Desired outcome in terms of utility (example: Field staff can access enterprise applications xxx and yyy without being constrained by location or time)

. 4. Desired outcome in terms of warranty (example: Access is facilitated worldwide in a secure and reliable manner)

8. Offerings and packages, variations

. 1. e.g. different Service Level packages on offer

. 2. e.g. different coverage of time zones

. 3. e.g. different coverage of geographical regions

9. Costs and pricing

. 1. Available pricing schemes for the service provision

. 2. Rules for penalties/ charge backs

10. Dependencies

. 1. Required Infrastructure Services (Infrastructure Services on which this service depends)

. 2. Supported services (other services which depend on this service)

. 3. Components/ Configuration Items (major CIs like on which this service depends)

11. Planned changes to the service (if any)

. 1. References to relevant plans (e.g. Service Strategy Plan, Service Improvement Plan)

. 2. Business case/ cost-benefit analysis

. 3. Priority of the envisaged change

. 4. Risks associated with the envisaged change

. 5. Time schedule and status information

12. References to further documents

13. Glossary

Document Control:

1. Document Title: Portfolio Director.

2. Reference: 161100.

3. Keywords: Portfolio Director.

4. Description: Portfolio Director.

5. Privacy: Public education service as a benefit to humanity.

6. Issued: 11 Jun 2018.

7. Edition: 1.5.