Volume 6


Services in DoDAF V2.0: A Methodology for Making Services Modelable and Relevant in DoDAF V2.0

This article advocates for a complete restructuring of the Services Viewpoint and Views within the DoD Architecture Framework (DoDAF) V2.0. It introduces the concept of overloading of the term “Service” within DoDAF V2.0, and provides a means of clarifying what is meant in the DoDAF regarding Services via the introduction of the term “Commoditized Service” into the DoDAF vernacular. The Commoditized Service is a manifestation of Service Oriented Architectures (SOA) at a higher level of abstraction than Web Services; it is not in-and-of-itself a Performer – the definition of Service in DoDAF V2.0 states a Service requires a Performer [as a Mechanism] to execute. The Commoditized Service (as well as the Web Service), requires a Service Level Agreement (SLA) to declare available functionality for the Service. This article introduces the concept of the SLA as a means of „information hiding‟ for the Commoditized Service, which allows for the manifestation of three concepts: (1) Capabilities as Systems that are bought or developed outright that are internal or functionally-specific applications, with no intention of offering underlying capabilities as a Service. (2) Outsourcing Capability (or parts of a Capability) to Commoditized Services. (3) Building the Service „in house‟ with the intention of offering it as a Commoditized Service. Each has different requirements regarding development of DoDAF artifacts; each case is discussed in detail as to the artifacts required for their manifestation. Finally, the article proposes a means of management of the underlying data associated with Commoditized Services. As such, what is presented is a logical construct for accommodating and modeling Commoditized Services, Web Services, Systems, Organizations, and People, providing value added to the architect and the organizations they support.

Enterprise Architecture and Information Technology Acquisition Management

This case study presents an example of how one federal agency was able to utilize its enterprise architecture (EA) throughout an information technology (IT) investment‟s acquisition lifecycle; and describes how EA and IT acquisition management (ITAM) were integrated to positively influence and enhance the IT program‟s acquisition strategy. Once the agency determined the relationship between EA and ITAM, it was able to improve mission performance by utilizing relevant and mature data and relationships captured in the EA items. Because these EA items were provided to agency executives and stakeholders at specific times throughout the acquisition lifecycle, they made more informed decisions regarding resources and investments, thus resulting in more streamlined processes and more efficient buying power. EA delivered choices on actions and laid out the impacts so that actions could be weighed and measured. Success translated into dollars through eliminated purchases, redeployment, compliance to standards, tactical optimization for the strategic direction, and much more.

A Decade of Running Lean Impacts Business’ Ability to Recover – Implications for Enterprise Architects

While statistical indicators point to increased productivity and excess capacity from our current workforce, other sources caution against assuming any of that dynamic is sustainable over the next few years. Managing our way through an investment-averse business climate since 2001, significant labor reductions since 2007, and expected baby boomer retirement after 2010, we need to prepare our enterprise for significant cultural and environmental change. Though “running lean” is the new expectation for managing our businesses, we may be transposing expectations for current productivity levels with future state capabilities as the economy improves. Enterprise Architects will serve a unique role in helping our organizations navigate their way out of recession and into a sustainable growth model during the next economic recovery.