Agile requirements handling in a service-oriented taxonomy of capabilities

Hannay, Jo Erskine; Brathen, Karsten; Mevassvik, Ole Martin

doi:10.1007/s00766-016-0244-8

Cited by 16 publications

(25 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…10 The C3 Taxonomy incorporates operational and technical capabilities in the same framework, and it can be used to organize and discipline the development of operational and technical functionality into loosely coupled capabilities and services. 9 NAF, on the other hand, has a notion of capability, but the focus is on operational capabilities, whereafter the technology that gives support to the capability is seen as implementation; not as a capability in itself. This difference in how technical functionality is treated entails a mismatch between NAF and the C3 Taxonomy.…”

Section: Initiative (Cfi)mentioning

confidence: 99%

“…The structure of the taxonomy allows for smaller well-delineated development projects within the scope of a large portfolio, 9 and for our purposes we select a modest number of capabilities and activities.…”

Section: Step (1): Capabilitiesmentioning

confidence: 99%

“…This spurs capability development not only on the operational level, but also on user-facing and backend levels. 9 Moving on, abstract descriptions can now be provided for user applications (or lightweight apps; see below) and services. In the C3 Taxonomy, user applications and services are declared at the capability level of abstraction.…”

Section: From Overarching Architecture To Target Architecture: a Guidementioning

confidence: 99%

“…In contrast, the C3 Taxonomy's structure supports the definition and development of loosely coupled and persistent capabilities at both operational and technical levels. 9 To induce that structure in NAF, we suggest a simple extension to NAF and a mapping from the C3 Taxonomy to NAF. The mapping effectively allows the use of the C3 Taxonomy's C3 capability ABBs to be used directly in NAF architecture work.…”

Section: Mapping the C3 Taxonomy Into Nafmentioning

confidence: 99%

“…The informationmanagement and technological aspect of CFI is embodied in Federated Mission Networking (FMN), which focuses on command, control, and decision-making in operations through improved information-sharing. 6 The complex landscape of the defense domain generates a need to organize the development of functionality into manageable parts, [7][8][9] with a focus on capabilities in order to align with FMN and so-called Capability-Based Planning (CBP). 10 The C3 Taxonomy incorporates operational and technical capabilities in the same framework, and it can be used to organize and discipline the development of operational and technical functionality into loosely coupled capabilities and services.…”

Section: Initiative (Cfi)mentioning

confidence: 99%

See 4 more Smart Citations

Architectural work for modeling and simulation combining the NATO Architecture Framework and C3 Taxonomy

Hannay

2016

Journal of Defense Modeling & Simulation

Self Cite

View full text Add to dashboard Cite

To provide modeling and simulation functionality as services is strategically leveraged in the defense domain and elsewhere. To describe and understand the context, the ecosystem, wherein such services are used and interoperate with other services and capabilities, one needs tools that capture the simulation services themselves as well as the capability landscape they operate in. By using the NATO Consultation, Command, and Control (C3) Taxonomy to structure architecture design in the NATO Architecture Framework (NAF), cohesive descriptions of modeling and simulation capabilities within larger contexts can be given. We show how a basic seven-step approach may benefit architecture work for modeling and simulation at the overarching, reference, and target architectural levels; in particular for (1) hybrid architectures that embed simulation architectures within a larger service-oriented architecture and (2) for architectural design of simulation scenarios. Central to the approach is the use of the C3 Taxonomy as a repository for overarching architecture building blocks and patterns. We conclude that the promotion of technical functionality as capabilities in their own right helps delineate simulation environment boundaries, helps delineate services within and outside the boundary, and is an enabler for defining the service concepts in cloud-based approaches to modeling and simulation as a service (MSaaS).

show abstract

Section: Initiative (Cfi)mentioning

confidence: 99%

Section: Step (1): Capabilitiesmentioning

confidence: 99%

Section: From Overarching Architecture To Target Architecture: a Guidementioning

confidence: 99%

Section: Mapping the C3 Taxonomy Into Nafmentioning

confidence: 99%

Section: Initiative (Cfi)mentioning

confidence: 99%

See 3 more Smart Citations

Architectural work for modeling and simulation combining the NATO Architecture Framework and C3 Taxonomy

Hannay

2016

Journal of Defense Modeling & Simulation

Self Cite

View full text Add to dashboard Cite

show abstract

A Hybrid Architecture Framework for Simulations in a Service-Oriented Environment

2017

Self Cite

View full text Add to dashboard Cite

Service orientation, and more recently, the notions of cloud technology that service orientation enable, are designed to accommodate the need for flexible enterprise business processes. Through standardized interfaces, a service‐oriented architecture (SOA) should enable one to build and rebuild software systems readily and rapidly in a methodological manner. However, certain domains have specialized architectural standards; an example in point is modeling and simulation (M&S), for which there exist mature architectural standards, that may even have many of the characteristics strived for in SOA. An important issue is, therefore, how to integrate specialized architectures into a wider SOA. Using defense information systems and M&S as a case, we outline a hybrid architecture framework for specialized architectures in an encompassing SOA. Although it may be possible to dissolve a specialized architecture into the encompassing SOA at implementation time, we argue that it is important to be able to model the specialized architecture as an integral intact part. We further advocate a pragmatic notion of reference architecture in terms of appropriate level of abstraction and domain specificity to avoid pitfalls that may render architecture work unusable.

show abstract