1 / 15

WICSA5 - Ontology-Based Architecture

WICSA5 - Ontology-Based Architecture. Art Akerman & Jeff Tyree November 9, 2005. Key Realizations (Based on Capital One experience with software architecture). Architecture decisions are the primary representation of architecture

laith-oneal
Download Presentation

WICSA5 - Ontology-Based Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WICSA5 - Ontology-Based Architecture Art Akerman & Jeff Tyree November 9, 2005

  2. Key Realizations (Based on Capital One experience with software architecture) • Architecture decisions are the primary representation of architecture • Architecture results from effective decision making, not from architectural view construction* • Architecting is primarily concerned with architecture assets, the business-driven decisions that transform these assets, and the roadmap that implements these decisions. *J. Tyree and A. Akerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, pp. 19-27, March. 2005

  3. Problems with our current architecture development method & descriptions • Lack of Focus on What’s Important • Lack of Precision and Clarity • Lack of Repository Support • Lack of Support for Impact Analysis (Decisions to Concerns, Decisions to Decisions, and Decisions to Architecture Assets) • Difficulty in Linking with the Views • Lack of Support for Temporal Mapping

  4. Solution • Architecture meta-model • Focus on “information about architecture that an organization cares about” instead of diagrams and views. Architecture is captured as an ontology. • Tool support to enable effective decision making and “on-demand” view creation

  5. Conceptual Architecture Meta-Model

  6. Architecture Meta-Model (Details) • Concerns • Decisions • Roadmap • Assets

  7. Ontology Tool – Protégé • Open source • Easy to use interface • Plug-ins and scripting – can use to extend functionality and to import / export data

  8. Simple Process Utilizing Ontology to Develop Architecture • Populate model with Key Concerns • Populate model with existing architecture assets • Define placeholders for architecture decisions • Create appropriate diagrams (As-Is and Target) to help visualize aspects of architecture • Define architecture decisions • Assign implications to initiatives or projects • Generate architecture documentation

  9. Step 1 – Populate model with Key Concerns • Identify key concerns to be addressed by architecture • Impacted business processes (AKA capabilities) • Key business (functional) requirements • System qualities (AKA non-functional requirements)

  10. Step 2 – Populate model with existing architecture assets • Existing systems in scope • Existing interfaces between systems • Physical nodes and systems allocated to them • Major data elements and systems which manage them

  11. Step 3 – Define placeholders for architecture decisions • Create a list of decision placeholders by making sure that each concern is addressed by at least one decision. Decision status – “Under Construction” • Determine decision impact (based on urgency to make a decision, its impact on ongoing planning activities, etc.) • Each placeholder can be assigned to a member of architecture team.

  12. Step 4 – Create appropriate diagrams (As-Is and Target) to help visualize aspects of architecture • Business process flows (ARIS) • IT System View (Visio) • Operational View (Visio)

  13. Step 5 – Define architecture decisions • Start with “High” impact placeholder decisions and populate them with data in the model (assumptions, alternatives, etc) • After you select an alternative to become your final decision write the implications. • Create new decision placeholders for implications which require additional decisions. Determine impact level of new decisions. • Define how implications impact architecture assets (create, modify, retire, use). Create new assets as required (systems, interfaces) • When done with all “High” impact decisions, move to “Medium” and then “Low”

  14. Step 6 – Assign implications to initiatives or projects • Create list of initiatives, assign projects to them • Each decision implication, which is not addressed by another decision, should be assigned to an initiative or project to be implemented* *For agile projects associate implications with project backlog items. Backlog items then get associated with sprints

  15. Step 7 – Generate architecture documentation* • Architecture Decisions document • Generate architecture decision using template format • Architecture Overview document • Generate list of systems and interfaces • Generate list of business processes (capabilities) and decisions addressing them • Data entities to systems mapping • NFRs to decisions mapping • Operational Model • Logical to physical nodes mapping *First export Protégé data into SQL database and the use VBA / SQL Queries to generate documentation

More Related