This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Talk:EA IP"
Jump to navigation
Jump to search
(move outdated 'next steps' to discussion page from EA IP page) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Moved content to [[Talk:EA_IP_Phase1_%28alpha_project_approach%29]] | |
| − | + | *Functional models and technical models and the relationship between them | |
| − | + | *Consistency across our paradigms | |
| + | **are interoperability-paradigm specifics only partially in evidence at the PIM layer of a SAIF spec and probably not really visible at the CIM? Do we have a PIM2PIM transformation between Services and Messaging or shall we create artifact to be rendered as a PIM for any paradigm? | ||
| + | *Behaviour in dynamic model | ||
| + | *Reusable functional components | ||
| + | **one of HL7's objectives in moving to SAIF is to put design principles in place to maximize the re-usability of artifacts across design paradigms and to automate, as much as possible, refinement of artifacts to be appropriate to a particular paradigm. ÿ While it is possible to design artifacts independently for messages, services and documents, as much as possible the IG should allow the design of a single artifact that can then be rendered as a PIM for any of the three paradigms. ÿ How close we'll get to this objective remains to be seen, but for the sake of workload on the organization and ease of migration and interoperability across paradigms it's definitely worth pursuing | ||
| + | **Not only is it to have reuseability of artifacts within HL7, it is to have outsiders understanding that HL7 HAS a framework for anybody's architecture or development artifacts, that can allow reuse, and hence speed development, whether the original source is | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *Remaining to be addressed are definitions of success criteria by which progress will be measured. | |
| − | * | + | |
| − | * | + | |
| − | * | + | |
| − | ** | + | |
| − | + | *Define interrelationship between terms using SKMT glossary? Include SAIF Glossary in HL7 Glossary, and format V3 Glossary for use by SKMT? | |
| − | * | + | *Define suite of artifacts using the OHT Shared Artifact Repository give us some leverage in retrieving items from “the bag”? Tooling Solution vision to be presented 2010Oct WGM proposes leveraging OHT Static Model Designer, Terminology Manager, Behavioral Model Designer, Shared Artifact Repository, and Specification Publication Manager. HL7 to participate in the enhancements in a project with OMG and IHTSDO, not yet developed. |
| − | + | *Question: What role does the Templates Registry play? | |
| − | + | **Artifact types currently identified: Content Domains, Infrastructure Domains, CMETs, Payload Message Types, Interactions, Trigger Events, Application Roles, Story Boards, and more interdependent artifacts each year. How to define DAM, DIM, SIM, etc. by CIM/PIM/PSM terms? | |
| − | + | ||
| − | + | *from Lloyd McKenzie: we have not enough guidance or structure in place for projects to go very far. When v3 first got off the ground, there was a bit of high level thinking about what kinds of artifacts we needed, the content of those artifacts got fleshed out, we built some tools to author those artifacts, and projects started using the tools. Based on feedback from the users of the tools as well as seeing what we liked and didn't like about the artifacts, the tools and methodology evolved. I think we need to do something similar here. We need to nail down things like "what are the specific artifacts in a behavioral model? What attributes do they have? How do they inter-relate? How are they best maintained? What does an interface contract look like?" and "What elements are allowed in a DAM? What's required? What sort of mapping is required between a DAM and a committee's DIMs or SIMs and how is that maintained?" and "What changes do we make in capturing requirements? How are they validated? How do we maintain traceability of those requirements?". None of these questions are answered in the current drafts of the frameworks and they're not the sort of questions that are easily tackled by a project (or group of projects) whose primary focus is producing a given standard under a tight timeline. | |
| − | * | + | |
| − | ** | + | *Lloyd writes: what's really needed is a project to produce a first attempt at a detailed methodology and set of tools that can then be exercised by a small number of test projects so they can be refactored and evolved to something ready to meet scrutiny by the wider membership. |
| − | *** | + | |
| − | * | + | |
| + | Example: The SAIF references the MDA (OMG's Model Driven Architecture) model suite consisting of CIM, PIM (Platform Independent Model) and PSM (Platform Specific Model). Within HL7 the term CIM as ‘Constrained Information Model’ has been deprecated and replaced by SIM (Serializable Information Model). So it's DAM-DIM-SIM nowadays in the HDF. A SIM conceptually is a PIM. | ||
| + | |||
| + | Project to track: SAIF Executive Summary and Implementation Guide with SOA | ||
| + | |||
| + | |||
| + | Examples External to HL7: NCI SAIF Implementation Guide at https://wiki.nci.nih.gov/display/CBIITtech/caGrid+2.0+Roadmap+Documents | ||
| + | |||
| + | |||
| + | Assumptions from EA IP: | ||
| + | *The responsibility to develop a full HL7 EAS rests with the HL7 Architecture Board (ArB); the ArB will use the SAIF as a baseline. | ||
| + | *Interdependencies between the development of the SAIF and the work to develop / refine the EAS will need to be assessed and applicable processes devised to ensure, among other things, | ||
| + | *Conceptual alignment (e.g. Consistent use of concepts / terms, artifacts, etc.); | ||
| + | *Appropriate flow of requirements for tooling and processes and other knowledge from SAIF to EAS work. | ||
| + | *EAS development will require collaboration with real integration projects (“Alpha Projects”) that are willing and able to tackle the development of artifacts covering multiple EAS layers / facets: | ||
| + | *Alpha Projects are ready to engage in short order; | ||
| + | **The sponsoring agencies are thought to be interested in taking the full range of artifacts through a balloting process; | ||
| + | **The HL7 SAIF IP will be accountable as the primary coordination point between “Alpha Projects” and HL7 - primarily addressing issue management. | ||
| + | |||
| + | |||
| + | '''HL7-localized definition of "Program Management" ''' | ||
| + | *Draft: documenting and reporting on activities of multiple projects that, together, constitute an HL7 ‘Program’. Projects, in industry terms, tend to be of fixed scope with some tangible outputs within a well defined time frame. By comparison, a program can be viewed as a portfolio of multiple projects to be coordinated in unison in order to achieve a broader set of objectives and realize specific organization-wide outcomes and benefits (often intangible). HL7 Program Management is intended to provide oversight, and make visible to the organization the plans, interdependencies, critical path, and progress of the various projects in the Program portfolio, as well as issues when these arise. Program management would work with the in-scope projects to help surface dependencies and key milestones to populate and subsequently maintain (based on project input) the overall program dashboard | ||
| + | *: A 'Program' objective is to provide transparency to the activities of various projects that are targeted with the resolution of key intra-organizational issues | ||
Latest revision as of 14:14, 2 December 2010
Moved content to Talk:EA_IP_Phase1_(alpha_project_approach)
- Functional models and technical models and the relationship between them
- Consistency across our paradigms
- are interoperability-paradigm specifics only partially in evidence at the PIM layer of a SAIF spec and probably not really visible at the CIM? Do we have a PIM2PIM transformation between Services and Messaging or shall we create artifact to be rendered as a PIM for any paradigm?
- Behaviour in dynamic model
- Reusable functional components
- one of HL7's objectives in moving to SAIF is to put design principles in place to maximize the re-usability of artifacts across design paradigms and to automate, as much as possible, refinement of artifacts to be appropriate to a particular paradigm. ÿ While it is possible to design artifacts independently for messages, services and documents, as much as possible the IG should allow the design of a single artifact that can then be rendered as a PIM for any of the three paradigms. ÿ How close we'll get to this objective remains to be seen, but for the sake of workload on the organization and ease of migration and interoperability across paradigms it's definitely worth pursuing
- Not only is it to have reuseability of artifacts within HL7, it is to have outsiders understanding that HL7 HAS a framework for anybody's architecture or development artifacts, that can allow reuse, and hence speed development, whether the original source is
- Remaining to be addressed are definitions of success criteria by which progress will be measured.
- Define interrelationship between terms using SKMT glossary? Include SAIF Glossary in HL7 Glossary, and format V3 Glossary for use by SKMT?
- Define suite of artifacts using the OHT Shared Artifact Repository give us some leverage in retrieving items from “the bag”? Tooling Solution vision to be presented 2010Oct WGM proposes leveraging OHT Static Model Designer, Terminology Manager, Behavioral Model Designer, Shared Artifact Repository, and Specification Publication Manager. HL7 to participate in the enhancements in a project with OMG and IHTSDO, not yet developed.
- Question: What role does the Templates Registry play?
- Artifact types currently identified: Content Domains, Infrastructure Domains, CMETs, Payload Message Types, Interactions, Trigger Events, Application Roles, Story Boards, and more interdependent artifacts each year. How to define DAM, DIM, SIM, etc. by CIM/PIM/PSM terms?
- from Lloyd McKenzie: we have not enough guidance or structure in place for projects to go very far. When v3 first got off the ground, there was a bit of high level thinking about what kinds of artifacts we needed, the content of those artifacts got fleshed out, we built some tools to author those artifacts, and projects started using the tools. Based on feedback from the users of the tools as well as seeing what we liked and didn't like about the artifacts, the tools and methodology evolved. I think we need to do something similar here. We need to nail down things like "what are the specific artifacts in a behavioral model? What attributes do they have? How do they inter-relate? How are they best maintained? What does an interface contract look like?" and "What elements are allowed in a DAM? What's required? What sort of mapping is required between a DAM and a committee's DIMs or SIMs and how is that maintained?" and "What changes do we make in capturing requirements? How are they validated? How do we maintain traceability of those requirements?". None of these questions are answered in the current drafts of the frameworks and they're not the sort of questions that are easily tackled by a project (or group of projects) whose primary focus is producing a given standard under a tight timeline.
- Lloyd writes: what's really needed is a project to produce a first attempt at a detailed methodology and set of tools that can then be exercised by a small number of test projects so they can be refactored and evolved to something ready to meet scrutiny by the wider membership.
Example: The SAIF references the MDA (OMG's Model Driven Architecture) model suite consisting of CIM, PIM (Platform Independent Model) and PSM (Platform Specific Model). Within HL7 the term CIM as ‘Constrained Information Model’ has been deprecated and replaced by SIM (Serializable Information Model). So it's DAM-DIM-SIM nowadays in the HDF. A SIM conceptually is a PIM.
Project to track: SAIF Executive Summary and Implementation Guide with SOA
Examples External to HL7: NCI SAIF Implementation Guide at https://wiki.nci.nih.gov/display/CBIITtech/caGrid+2.0+Roadmap+Documents
Assumptions from EA IP:
- The responsibility to develop a full HL7 EAS rests with the HL7 Architecture Board (ArB); the ArB will use the SAIF as a baseline.
- Interdependencies between the development of the SAIF and the work to develop / refine the EAS will need to be assessed and applicable processes devised to ensure, among other things,
- Conceptual alignment (e.g. Consistent use of concepts / terms, artifacts, etc.);
- Appropriate flow of requirements for tooling and processes and other knowledge from SAIF to EAS work.
- EAS development will require collaboration with real integration projects (“Alpha Projects”) that are willing and able to tackle the development of artifacts covering multiple EAS layers / facets:
- Alpha Projects are ready to engage in short order;
- The sponsoring agencies are thought to be interested in taking the full range of artifacts through a balloting process;
- The HL7 SAIF IP will be accountable as the primary coordination point between “Alpha Projects” and HL7 - primarily addressing issue management.
HL7-localized definition of "Program Management"
- Draft: documenting and reporting on activities of multiple projects that, together, constitute an HL7 ‘Program’. Projects, in industry terms, tend to be of fixed scope with some tangible outputs within a well defined time frame. By comparison, a program can be viewed as a portfolio of multiple projects to be coordinated in unison in order to achieve a broader set of objectives and realize specific organization-wide outcomes and benefits (often intangible). HL7 Program Management is intended to provide oversight, and make visible to the organization the plans, interdependencies, critical path, and progress of the various projects in the Program portfolio, as well as issues when these arise. Program management would work with the in-scope projects to help surface dependencies and key milestones to populate and subsequently maintain (based on project input) the overall program dashboard
- A 'Program' objective is to provide transparency to the activities of various projects that are targeted with the resolution of key intra-organizational issues
