Quantitative metrics for assessing status of a platform architecture for cloud computing

• US 10,387,821 B2
• Filed: 07/09/2018
• Issued: 08/20/2019
• Est. Priority Date: 08/31/2015
• Status: Active Grant

• Current Assignee: Salesforce.com, Inc.
• Original Assignee: Salesforce.com, Inc.
• Inventors: Mack, Gerhard Friedrich, Puhl, Stefan
• Primary Examiner(s): Jeon, Jae U
• Application Number:
  US16/029,883
• Publication Number:
  US 20180330290A1
• Time in Patent Office: 407 Days
• Field of Search: 717101-108
• CPC Class Codes: G06Q 10/0637 Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
• CPC Class Codes: G06Q 10/067 Enterprise or organisation modelling
• CPC Class Codes: H04L 41/0893 Assignment of logical groups to network elements

Abstract

One or more implementations relate generally to a platform architecture planning process utilizing architecture type unit definitions. For example, an architecture for realizing a customer system on a cloud computing platform may be defined in terms of a plurality of architecture types, each type (AT) defined by plural architecture type units (ATUs), and each ATU comprising a set of ATU Details.

Claims

1. A computer-implemented method for measuring the architecting of a customer system during continuous delivery on a cloud-computing platform, the method comprising:

defining and developing, by a computer system, a platform architecture of a customer system in terms of a plurality of architecture types, the architecture types including a first architecture type that is a Go-To-Market Architecture (GTMA) that documents how the customer system will address a customer'"'"'s business model;

for the first architecture type, defining, by the computer system, a plurality of first architecture type units (ATUs) to further define and detail the first architecture type, wherein each of the first architecture type units comprises a corresponding set of architecture type unit detail (ATUD) deliverables;

for each of the first architecture type units, ordering, by the computer system, the deliverables into a series of discrete stages (levels of detail) so that each deliverable belongs to exactly one of the discrete stages of the first architecture type;

defining, by the computer system, a set of quality requirements for the deliverables;

determining, by the computer system, a current status of the first architecture type as a first architecture pulse (AP) value, wherein the first pulse value combines a current status for each stage of the first architectural type, based on the defined quality requirements, together with a current level of detail of the of the first architectural type, based on the existing deliverables; and

wherein the first pulse also reflects a preference that the deliverables of the first architectural type be created in an order according to the series of discrete stages; and

generating structured information to evaluate a staggered resource deployment associated with planning resources to be allocated before a development cycle of the customer system.

2. The method of claim 1, further comprising:

for the first architecture type, receiving an architecture marker (AM) as input data, the input data comprising a binary indication, for each of the discrete stages, of whether or not all of the deliverables associated with the stage are considered confirmed, based on meeting the defined quality requirements, wherein the AM is a juxtaposition of progress and quality tracking, and wherein determining the current status of the first architecture type is responsive to the architecture marker (AM) input data.

3. The method of claim 2, wherein determining the current status of the first architecture type includes:

weighting the architecture marker input data by a set of selected atomic quality level weights;

weighting the architecture marker input data by a set of selected progressive weights; and

combining the atomic quality weighted input data and the progressive weighted input data to arrive at the first pulse value for combined progress and quality tracking.

4. The method of claim 3, further comprising normalizing the first pulse value to a range of 0 to 1.

5. The method of claim 2, further comprising:

for each remaining architecture type from the plurality of architecture types that is not the first architecture type, repeating the step of defining of a plurality of architecture type units (ATUs), wherein each of the architecture type units comprises a corresponding set of architecture type unit detail (ATUD) deliverables; and

for each of the remaining architecture types, repeating the determining step to form corresponding architecture pulse (AP) values.

6. The method of claim 5, further comprising:

combining the respective architecture pulse values of all of the plurality of architecture types to form a single success platform pulse (SPP) numeric value that reflects a current status of the customer system platform.

7. The method of claim 5, further comprising:

forming a success platform pulse (SPP) of the customer system as a weighted average of the plural architecture pulse (AP) values; and

displaying the SPP to enable tracking an overall condition of platform architecture of the customer system with a single numerical value.

8. The method of claim 2, wherein the plurality of architecture types further include one or more of:

a platform environment architecture (PEA) type that reflects input from at least an API model artifact and documents how the customer system will address a model of the customer'"'"'s services;

a platform component architecture (PCA) type that reflects input from a journey map artifact and documents or reflects how the platform is structured to execute the customer'"'"'s processes; and

a platform information architecture (PIA) type that receives input from at least an object model artifact and is arranged to address customer data and document how platform persistency is organized.

9. The method of claim 2, wherein determining the current status of the first architecture type includes:

weighting the architecture marker input data by progressive level weights (PLW) that are selected to increase the pulse value responsive to creation of deliverables in an order corresponding to the series of discrete stages, and conversely to reduce the pulse value responsive to creation of the deliverables in an order inconsistent with series of discrete levels of detail stages; and

weighting the architecture marker by a quality level weight matrix (QLW) that recognizes a current stage of the architecture type unit details documenting a quality of the architecture.

10. The method of claim 2, further comprising:

receiving individual binary pulse values for all atomic stages, the atomic stages comprising, for each of the discrete stages, an binary indication of compliance relative to each quality type of the set of quality requirements, wherein determining the current status of the first architecture type is based on the individual binary pulse values.

11. The method of claim 10, wherein determining the current status of the first architecture type includes:

for each of the architecture types, forming an architecture pulse (AP) metric as a sum product of all of the individual pulse values and a selected pulse weight factor (PW) matrix to form a single numerical value representing a current condition of the corresponding architecture type;

forming a success platform pulse (SPP) of the customer system as a weighted average of the four architecture pulse (AP) values; and

displaying the SPP to enable tracking the overall condition of platform architecture of the customer system with a single numerical value.

12. The method of claim 11, further comprising:

comparing the SPP to an expected value;

in the case that the SPP is below the selected value, identifying one of the architecture types having a lowest architecture pulse value;

for the identified one architecture type, examining the architecture marker (AM) and the architecture type units (ATUs) associated with the identified architecture type; and

based on the examination of the AM and ATUs, applying resources to the identified ATU to increase the SPP by improving the architecture type unity details (ATUD) thereby increasing quality of the identified level of detail (stage) as an input for a revised exit of a success gate.

13. The method of claim 11, further comprising:

comparing the SPP to an expected value;

in the case that the SPP is below the selected value, identifying one of the architecture types having a lowest architecture pulse value;

for the identified one architecture type, examining the underlying individual pulse values;

based on the underlying individual pulse values, identifying at least one set of the corresponding architecture type unit detail (ATUD) deliverables; and

applying a potential architecture accelerator to create or improve the quality of the identified deliverables to increase the SPP.

14. A computer system for measuring the architecting of a customer system during continuous delivery on a cloud-computing platform, the computer system comprising:

a processor; and

memory coupled to the processor and storing instructions that, when executed by the processor, cause the computer system to perform operations comprising;

defining and developing a platform architecture of a customer system in terms of a plurality of architecture types, the architecture types including a first architecture type that is a Go-To-Market Architecture (GTMA) that documents how the customer system will address a customer'"'"'s business model;

for the first architecture type, defining a plurality of first architecture type units (ATUs) to further define and detail the first architecture type, wherein each of the first architecture type units comprises a corresponding set of architecture type unit detail (ATUD) deliverables;

for each of the first architecture type units, ordering the deliverables into a series of discrete stages (levels of detail) so that each deliverable belongs to exactly one of the discrete stages of the first architecture type;

defining a set of quality requirements for the deliverables;

determining a current status of the first architecture type as a first architecture pulse (AP) value, wherein the first pulse value combines a current status for each stage of the first architectural type, based on the defined quality requirements, together with a current level of detail of the of the first architectural type, based on the existing deliverables; and

wherein the first pulse also reflects a preference that the deliverables of the first architectural type be created in an order according to the series of discrete stages; and

generating structured information to evaluate a staggered resource deployment associated with planning resources to be allocated before a development cycle of the customer system.

15. The system of claim 14, wherein the memory further stores instructions for causing the computer system to perform operations comprising:

for the first architecture type, receiving an architecture marker (AM) as input data, the input data comprising a binary indication, for each of the discrete stages, of whether or not all of the deliverables associated with the stage are considered confirmed, based on meeting the defined quality requirements, wherein the AM is a juxtaposition of progress and quality tracking, and wherein determining the current status of the first architecture type is responsive to the architecture marker (AM) input data.

16. The system of claim 15, wherein determining the current status of the first architecture type includes:

weighting the architecture marker input data by a set of selected atomic quality level weights;

weighting the architecture marker input data by a set of selected progressive weights; and

combining the atomic quality weighted input data and the progressive weighted input data to arrive at the first pulse value for combined progress and quality tracking.

17. The system of claim 15, wherein the memory further stores instructions for causing the computer system to perform operations comprising:

for each remaining architecture type from the plurality of architecture types that is not the first architecture type, repeating the step of defining of a plurality of architecture type units (ATUs), wherein each of the architecture type units comprises a corresponding set of architecture type unit detail (ATUD) deliverables; and

for each of the remaining architecture types, repeating the determining step to form corresponding architecture pulse (AP) values.

18. The system of claim 17, wherein the memory further stores instructions for causing the computer system to perform operations comprising:

combining the respective architecture pulse values of all of the plurality of architecture types to form a single success platform pulse (SPP) numeric value that reflects a current status of the customer system platform.

19. The system of claim 17, wherein the memory further stores instructions for causing the computer system to perform operations comprising:

forming a success platform pulse (SPP) of the customer system as a weighted average of the plural architecture pulse (AP) values; and

displaying the SPP to enable tracking an overall condition of platform architecture of the customer system with a single numerical value.

20. A non-transitory computer-readable medium storing instructions that, when executed by a computer system, cause the computer system to perform operations comprising:

defining and developing a platform architecture of a customer system in terms of a plurality of architecture types, the architecture types including a first architecture type that is a Go-To-Market Architecture (GTMA) that documents how the customer system will address a customer'"'"'s business model;

for the first architecture type, defining a plurality of first architecture type units (ATUs) to further define and detail the first architecture type, wherein each of the first architecture type units comprises a corresponding set of architecture type unit detail (ATUD) deliverables;

for each of the first architecture type units, ordering the deliverables into a series of discrete stages (levels of detail) so that each deliverable belongs to exactly one of the discrete stages of the first architecture type;

defining a set of quality requirements for the deliverables;

determining a current status of the first architecture type as a first architecture pulse (AP) value, wherein the first pulse value combines a current status for each stage of the first architectural type, based on the defined quality requirements, together with a current level of detail of the of the first architectural type, based on the existing deliverables; and

wherein the first pulse also reflects a preference that the deliverables of the first architectural type be created in an order according to the series of discrete stages; and

generating structured information to evaluate a staggered resource deployment associated with planning resources to be allocated before a development cycle of the customer system.