1. CTMS Coordination Team CTMS Coordination Team: Model and Documentation Management John Koisch Paul Boyes 2008 03 07

2. CTMS Coordination Team Outline Overview: Architecture Lifecycle Management Modeling Documentation Publication Outstanding Questions: Where do requirements come from? What does it mean to be a project? How should the repositories support the process? How does the CAT Team communicate to the community at large? What gets published? Where? Repository “flavor” (SVN, CVS)?

3. CTMS Coordination Team Enterprise Architecture A Definition Enterprise Architecture can be defined as The people, processes, and artifacts that link enterprise vision, usage requirements, and project methodology with technological implementations. Vision Requirements Methodology Technology ArtifactsPeople Process

4. CTMS Coordination Team The Components of Architecture The Architecture should enable software development by offering traceability for stakeholders and project teams alike Transparency Accessibility Artifacts Communication links Common view of relationships and entities People Teams (Governance, Workspace, Architecture, Project, Testing) Processes Support Communication Pathways within and among Teams

5. CTMS Coordination Team The Pathways for Communication Communication Pathways that need to be supported by the Architecture … PathAreasCommunication Pathway Between and Among Architecture Team(s)  Information  Computation  Engineering  Enterprise  Technical Repository Between Architecture Team and the Community  Stakeholders  NCI Governance Bodies  Project Teams  Other Organizations  Testing Publishing

6. CTMS Coordination Team The Publishing Process ProcessArtifacts Architecture Team (Architect(s), Analyst(s), SME’s) Project Teams

7. CTMS Coordination Team Publishing Marks the End of Phases / Iterations The publishing events at the end of Elaboration mark the end of the need to share common models between architecture execution lanes. All subsequent work proceeds within a project team. Project work proceeds by referencing (where necessary) the published architecture (either documents or model documentation) Top Level Linking page that points to the hierarchy of models and Documents Documents Conceptual CFM / CFS Logical PIM Platform PSM Models HTML Models and Images with links to other models (dependencies) Like javadocs Documents and Web Pages should satisfy the majority of external needs For Example, Documents can help discussions with SME’s and Workspaces For Example, published HTML Models can help Project Teams

8. CTMS Coordination Team What gets Published - Inception Conceptual Model (CFM)

9. CTMS Coordination Team What gets Published – Elaboration Logical Models (PIM)

10. CTMS Coordination Team What gets Published – Elaboration Platform Models (PSM)

11. CTMS Coordination Team What gets Published – Construction Deployment Model Deployment Guide, Installation Guide User Manual (if necessary) Implementation Guide (if necessary) Operations Manual (if necessary)

12. CTMS Coordination Team Organizing the Published Material A Concept Model for a series of Linked Web Pages

13. CTMS Coordination Team Fully Specified Service or Application +Service Model + Requirements + SRS + Enterprise > > + Business Process + Information > > + Domain Analysis + Information Analysis + Messaging Model + ITS + Computation > > + Functional + Behavioral + Choreography + Engineering > > + Deployment + Development + Operational + Technical > > + CFM > > > + > + > Constrained + > + PIM > > > + > + PSM > > > + > Constrained +Application Model + Requirements + SRS + Enterprise > > + Business Process + Information > > + Domain Analysis + Information Analysis + Messaging Model + Computation > > + Functional Dependencies + Choreography + Engineering > > + Deployment + Development + Operational + Technical > > + CFM > > > + > + > Constrained + > + Platform Model > > > + > Constrained

14. CTMS Coordination Team Enterprise Risk and Requirements Project-Level Risk should inform and be informed by Enterprise-Level Risks Enterprise-Level Requirements should be traceable through to Project Implementations Enterprise RiskEnterprise Requirements Project RiskProject Requirements

15. CTMS Coordination Team Organizing the Enterprise and its Projects

16. CTMS Coordination Team Questions?

17. CTMS Coordination Team Repository Structure Enterprise Business Process Information Computational Dynamic Functional Engineering Development Operational Deployment Should also think about Testing, Requirements, and Dependencies

18. CTMS Coordination Team Repository Foundations Repositories Communication between and among the Architecture Team Support Distributed, Diverse teams working on separate execution streams Not force “one way” to build models Modeling Requirements Allow small teams to work fast Allow teams to manage their own work products Allow teams to discover and trace dependencies with other models Should Address Publishing Documentation, Documents Consistency across models Note that since Repositories are the source of a _lot_ of cross team work, make sure that they are backed up and that there is a recovery plan

19. CTMS Coordination Team Repository Structure  Model Repository  Service Model Repository  Stub Model  Contained Package  Application Model Repository  Stub Model  Contained Package Example:  NCI.Service  NCI.Service.ProtocolAbstraction  NCI.Service.ProtocolAbstractio n.Computational  NCI.Services.ProtocolA bstraction.Dynamic  NCI.Services.ProtocolA bstraction.Static  NCI.Service.Person  NCI.Service.Person.Computatio nal  NCI.Services.Person.D ynamic  NCI.Services.Person.St atic  NCI.Application

20. CTMS Coordination Team A look at the Project Inception Note the Interdependency between the three activities that generate a conceptual model (both the model elements and the actual CFM document)

21. CTMS Coordination Team Takeaway from Inception Model Repositories have to be “flat” and “central” for a project team Interdependencies between the Information and Computational components Recommend: One repository per “project” One “View” per Model “Top Level” nodes as needed or desired

22. CTMS Coordination Team A Look at Project Elaboration Specifying the Common Logical Model Again, note the Interdependency between the three activities that generate a model (and its corresponding document)

23. CTMS Coordination Team A Look at Project Elaboration Specifying the Platform The Logical Models get constrained and extended to support an Implementation

24. CTMS Coordination Team Takeaways from Elaboration 4 Published Artifacts Logical PIM Logical Model Design PSM Design Model Constant Interplay between Three Execution Streams

25. CTMS Coordination Team Repository Layout Top - Level Node User / Team defined Sub – Level Nodes Viewpoint defined Communicates one / more concepts Can be mixed / matched under various top-level nodes Documentation Convenience Managed in the repository individually (separate XML documents) Can contain references (‘links’) to other sub-level nodes Can be checked out individually

26. CTMS Coordination Team Publishing Foundations Publishing Governance from above and below is facilitated by an open publishing process Makes the architecture mostly transparent Allows Information to flow bottom-up and top-down In terms of scope and impact, publishing is the single most important activity that architects undertake Should address Releases The Architecture Teams “finished” product Communication HTML Models Governance CFM and CFS

27. CTMS Coordination Team Notes on Sparx Enterprise Architect Supports full SDLC Easy to use Full UML support Single users to large teams Shared or individual owned models Version control with SVN, CVS, TFS, and SCC compliant providers