EAP ATAM and Collaboration at the Enterprise Level Evaluating - - PowerPoint PPT Presentation
EAP ATAM and Collaboration at the Enterprise Level Evaluating - - PowerPoint PPT Presentation
EAP ATAM and Collaboration at the Enterprise Level Evaluating Software Architecture ATAM The Architecture Trade-off Analysis Method n Evaluating software architecture Determines if the architecture meets the business drivers One of its
2 Knotion Consulting (Pty) Ltd
Evaluating Software Architecture ATAM – The Architecture Trade-off Analysis Method
n Evaluating software architecture Determines if the architecture meets the business drivers One of its primary functions is to look at the non-functional or quality attributes of the solution i.e. Flexibility, scalability, performance etc Measures the effective structure of the project Identifies course correction actions This process can be done early or late in the SDLC n It involves the architects, developers and stakeholders n Will produce a report artefact that addresses the following: Is this architecture suitable for the system for which it was designed ? Which of two or more competing architectures is the most suitable one for the system at hand ?
3 Knotion Consulting (Pty) Ltd
The Need for Collaboration
n Collaboration across disciplines Project Management Enterprise Architecture Software Architecture Software Development Project Costing and Accounting n Knowledge Sharing Capture, model and share information / architectures Automate some of the standard architecture processes n Multiplicity Standards – UML, RDF, OWL Methodologies – RUP, XP, Agile Frameworks – application, enterprise Semantic understandings n Blackboarding Mind mapping on steroids Everything agnostic Collaboration based Knowledge sharing Semantically driven Knowledge automation
4 Knotion Consulting (Pty) Ltd
MasterPlan
Closed Loop Collaboration
Business Driver Application Requirement Non-Functional Requirement Functional Requirement Use Case Model ATAM Scenario Analysis CBAM Application Blueprint Business Model Technical Blueprint Execution Blueprint Operations Blueprint Development Blueprint Use Case Inventory List
Boxology B
- x
- l
- g
y
5 Knotion Consulting (Pty) Ltd
ATAM in Synap-c
n Functional Collaboration
UML and the software development lifecycle Requirements analysis and traceability Link into enterprise-level architecture
n Non-functional Collaboration
Quality attributes defined and mapped in network structure Metrics cascade upwards via semantic links Semantically linked to developers and stakeholders Semantically linked to either a scenario or an architecture decision Impact assessment up and down the pipe ATAM and architecture styles and the impact on enterprise-level technical architecture
n Project Management
SDLC collaborative management Project metrics
6 Knotion Consulting (Pty) Ltd
How Is This Done? Logical View
Types Attributes Relationships Architectural Approach
- Arch. Decision
Trade-off Quality Attr
Quality attribute has and arch. decision
- Arch. Decision has a trade-off
Quality attribute has a stimulus
i ii iii Rules i ii
(Arch. Decision.Cost) = Loop Cost of (Risk-Trade-off)
Stimulus
7 Knotion Consulting (Pty) Ltd
How Is This Done? Physical View
Data Base Client Site
Planning
Define Plan Manage Capture
8 Knotion Consulting (Pty) Ltd
TANK Billing Subscription Zachman C4ISR Telco 2 3 1 TANK Frameworks Business Models Agent Adaptive Layer
How Is This Done? Physical View
9 Knotion Consulting (Pty) Ltd
Results of ATAM Collaboration
n ATAM allows for expansion; this extends ATAM further and makes it more relevant and powerful. n Non-linear nature of architecture and ATAM means that spreadsheets are difficult and cumbersome and re-use is
- difficult. Multiple layers of ATAM require significant links and multi-dimensional layers. To address this, Synap-c
allows for: A network structure to map anything to anything, allowing trawling through the entire network; Scenario and gap analysis on various options; Semantic classification of data and reporting; Reuse at team, department, client, industry and international level, should the need arise. There is also reuse of: – Assets; – Knowledge; – Styles; – Decisions; – Scenarios; – Etc Multi-dimensional support. n The blackboard nature of the tool is conducive to the nature of architecture. There is also support for the agnostic nature of architects and developers. n Because we experienced difficulty in communicating the styles to clients, we often had to fall back to traditional technical execution frameworks to capture the detail. Synap-c allowed the use of these frameworks to be related into ATAM. n The semantic nature of the quality attributes and the various sub-attributes proved confusing to clients. The re- usable, drag-and-drop nature of the tool allows for a consistent definition.
10 Knotion Consulting (Pty) Ltd
Results of ATAM Collaboration
n To ensure a consistent enterprise level solution that include ATAM, a closed loop from the enterprise level down to the code level is required. n A gap still exists between the outputs of architecture decisions and risks identified into tangible code level
- decisions. The use of patterns of decision making and the resultant feedback mechanism into these patterns will
solve this. n The feedback loop must cater for the unstructured blackboard nature of architectural thinking. Current thought is to control this with the use of ontologies. n The feedback loop must also cater for the semantic nature of architecture perception, which is partially captured in
- styles. The automation of these styles into belief systems may yield some interesting results.
n Patterns have traditionally led to hedged thinking. This is yet another reason to ensure the closure of the feedback loop. n Ability to apply rules and automation at a later stage. n The styles also clashed slightly with enterprise level thought, but this was addressed by the network structure and semantic nature of the tool. n We struggled to break free from the CIO and technical level of our clients and could only do this when integrated with a strategy session and enterprise level solutions. n We have received four levels of feedback:
- 1. Stakeholder level – they were satisfied that an objective view was provided that allowed for course correction
actions and an industry stamp of approval.
- 2. CIO level – the general feel was a cover-your-back tool to ensure that no mistakes were made.
- 3. Project manager level – hugely beneficial since ATAM helped identify risks and mechanisms to reduce these
- risks. It also helped with elements such as costing and resourcing.
- 4. Developer level – they struggled to convert the decisions into code action, especially since ATAM is most
- ften done during elaboration or construction phase. Most resistance from this phase since risks identified
reflect upon the developers designs and code. The best way to close the loop here was to link into the use case level.