Moses, Charlie, Vaughn and I met again to revise the PHGrid Architecture models. We're now up to 0.5 and the good news is we've reached consensus on these four models.
I'll schedule some time with NCPHI leadership next week to present our models. But we're still looking for any feedback on the models.
Showing posts with label collaboration. Show all posts
Showing posts with label collaboration. Show all posts
Friday, March 27, 2009
Friday, March 6, 2009
More PHGrid Architecture
On Monday, February 9th, GB held a session to discuss review the progress of the PHIN-SRM proof of concept project and potential GAARDS-related PoC next steps. During this meeting he requested an enterprise architecture review of how PHGrid will look and what components are necessary for deploying services throughout a grid to benefit public health informatics.
Over the past three weeks, Moses (PHIN contractor), Vaughn (PHINMS contractor), Charlie (PHIN-SRM contractor) and I (PHGrid contractor) have met to draft an initial release of four diagrams that seek to address this need for an architecture. Our goal was to create an architecture that is meaningful to business stewards, project managers, architects and developers. Statistician George Box once said "All models are wrong; some models are useful". This set of diagrams is meant to be useful.
All four models are available on the wiki at: http://sites.google.com/site/phgrid/Home/phgridarchitecture.
PHGrid Architecture - This model shows the basic components of the PHGrid and where they fit with CDC's partner structure. Some components must be hosted at the CDC (such as CDC application data), some components must be hosted by our partners (such as State application data) and some component lie in between (collaboration portals, registries, etc.).
PHGrid Service Stack- This model shows the services available within a specific node. It is separated into a small list of program services that different partners may wish to install and infrastructure services that are required for minimal functionality.
PHGrid Node Functional Deployment- This model shows the software components within a specific node.
PHGrid Roadmap- This model is perhaps the most arbitrary as it requires more input from the relevant program and system stewards. It attempts to show a timeline for how the services, components and infrastructure can be built out. Each timeline is marked with what has been completed or is currently in progress and show the required dependencies. To the right of this marker are the items that require prioritization based on your decisions. For example, along the Infrastructure Timeline,
Please post your feedback on these models and how we can change and improve them. Based on the feedback gathered in response to this email I may schedule a time for us all to meet again and review potential next steps.
Here is the visio in case anyone would like to submit their comments within the models.
Over the past three weeks, Moses (PHIN contractor), Vaughn (PHINMS contractor), Charlie (PHIN-SRM contractor) and I (PHGrid contractor) have met to draft an initial release of four diagrams that seek to address this need for an architecture. Our goal was to create an architecture that is meaningful to business stewards, project managers, architects and developers. Statistician George Box once said "All models are wrong; some models are useful". This set of diagrams is meant to be useful.
All four models are available on the wiki at: http://sites.google.com/site/phgrid/Home/phgridarchitecture.
PHGrid Architecture - This model shows the basic components of the PHGrid and where they fit with CDC's partner structure. Some components must be hosted at the CDC (such as CDC application data), some components must be hosted by our partners (such as State application data) and some component lie in between (collaboration portals, registries, etc.).
PHGrid Service Stack- This model shows the services available within a specific node. It is separated into a small list of program services that different partners may wish to install and infrastructure services that are required for minimal functionality.
PHGrid Node Functional Deployment- This model shows the software components within a specific node.
PHGrid Roadmap- This model is perhaps the most arbitrary as it requires more input from the relevant program and system stewards. It attempts to show a timeline for how the services, components and infrastructure can be built out. Each timeline is marked with what has been completed or is currently in progress and show the required dependencies. To the right of this marker are the items that require prioritization based on your decisions. For example, along the Infrastructure Timeline,
Please post your feedback on these models and how we can change and improve them. Based on the feedback gathered in response to this email I may schedule a time for us all to meet again and review potential next steps.
Here is the visio in case anyone would like to submit their comments within the models.
Wednesday, February 18, 2009
A non technology, non health blog that you may find interesting
Lately, I've been following reading a book and following a blog, each called 'Wikinomics: Exploring How Mass Collaboration Changes Everything' http://www.wikinomics.com/blog/. The points of view of the contributors to the book / blog are stunningly like those that contribute to this space. In fact, in the book, the authors make some bold proclamations that commercial interests that are closed, hierarchical, and essentially 'old-school' are now the 'losers' in the market. I have yet to find any consideration of how governments and / or health entities fare in these approaches. I wonder if we should consider ourselves a case study?
Friday, December 12, 2008
OSU/Emory Meeting
We had some interesting meetings with the Emory and Ohio State grid teams this week. Specifically we were able to sit in on the Emory/OSU collaboration session and to meet with Steve Langella in person and Shannon Hastings over the phone about the activities ongoing and planned for PHGrid.
Steve was especially useful in meeting with Dan, Raja and Joseph about how cagrid's security components work and how they can help with our planning for the AMDS Pilot that is ramping up.
We're going to be updating our architecture diagrams to incorporate Steve's ideas and cagrid's infrastructure components.
Steve was especially useful in meeting with Dan, Raja and Joseph about how cagrid's security components work and how they can help with our planning for the AMDS Pilot that is ramping up.
We're going to be updating our architecture diagrams to incorporate Steve's ideas and cagrid's infrastructure components.
Subscribe to:
Posts (Atom)
Posts
