Joint Technical Architecture (JTA) simplifies and improves the system’s ability to maintain combined and joint operations in an investment strategy taken as a whole. The JTA is responsible for ensuring the interoperability of all strategic, tactical, and maintenance of systems. It also authorizes guidelines and standards for acquisition and system development that largely trims down development time and cost, as well as fielding time for enhanced systems (Gartner 2011). All this is achieved while ensuring that the effect on the program performance is minimized as much as possible. JAT was developed in 1997 by DoD with the aim of providing the least set of standards that ensured streaming of information, which could guide the warfighter when carried out (Perks and Beveridge 56).
To ensure that the upcoming technologies are readily controlled by the future’s military systems, JTA is designed to impact the standards-based product development that is produced by the industry. This architecture makes it possible for DoD to use commercial products since communication within the industry is enhanced, and the use of open systems products and implementation is also improved. Consequently, the acquisition of the best products and low-cost strategy is achievable (Zachman 52).
The components of JTA are upcoming and consist of interfaces, service areas, and standards that are compatible with the requirement of the DoD’s architecture. The DoD’s JTA version 3.0 encompasses information technology and its associated standards that enhance transmission of services or information across a functional, joint or organizational border. Information technology here may be taken to mean any system or equipment that can be applied for storage, mechanical acquisition, manipulation, management, movement, interchange, transmission, switching, or reception of information. This includes communication systems, computers, software, and services, among other related resources (Zachman(b) 25).
Although JTA is not responsible for the selection of a particular standard, it offers a variety of standards to select from. A selection methodology is notably used to accompany the progress of the standards profiles for addition into a standard-based environment, which allows reusability and interoperability. The complementary methodology, which can be found in the DoD TRM, makes the selection of appropriate standards very easy, hence enhancing support of the system and operational architectural needs.
The DoD TRM user guide is transmitted to offer insight regarding the application of the DoD TRM to resolve and remedy an assortment of portability, interoperability, and open system issues. Its significance is to offer a comprehension of the way the framework provides a basis for building up of operational and technical architectures, for pointing out interfaces and services, and the best time to bring into play the interface or service or both. The DoD TRM aims at providing interoperability within the DoD system, a role that has not been addressed in a consistent and uniform way in the past (Schekkerman 146)
The DoD JTA helps in the development and acquisition of emerging and new systems in the choice of IT functionality. Only the new sets of authorized and emerging standards that have some interoperability significance are identified by the JTA. The commercial open systems technology determines the kind of standards to be contained in the JTA. Some of the considerations that guide mandating of particular standards include, promotion of interoperability by improving combined or joint agency/service information transmission and joint activities support, technical implementation ability of the standard, and public availability, which is evidenced by wide adoption and distribution of the standard, and consistency of the standard with the commanding sources such as policy, regulations and guidance documents (O’Rourke, Fishman, and Selkow 25).
The fact that architecture is a key decision-making tool across the enterprise’s Departments calls for crucial observance of the numerous needs of stakeholder’s architecture through various ways of combining, managing, using, and governing the architecture. These processes are very important to observe the needs of various architecture stakeholders. The technical architecture (TA) is a minimum set of standards, which guides the interaction, arrangement, and interdependence of components that ensure conformant systems meet a specified set of requirements. The Systems Architecture (SA) is an explanation of interconnections and systems that offer supporting system functionality.
Besides JTA, TOGAF is another architecture framework that is used today. JTA has close relationships with TOGAF. As the DoD attempted to solve the issues of interoperability in the 1990s, the “Technical Architecture Framework For Information Management (TAFIM)” (Gregg 23) was began in 1992 with the aim of providing direction for the development of the DoD technical infrastructure.
Although this framework did not offer particular system architecture, it offered services, design, standards, concepts, configurations, and components that could help develop the technical architecture that possesses a specific requirement’s objective. Currently, the TAFIM is considered outdated due to the emergence of other documents such as JTA. TRM version of the TAFIM is seemingly now part of the C4ISR framework, which is meanwhile called the department of the defense architecture framework.
The open group architectural framework (TOGAF), which supports applications, building business, technology architecture, and data, has a technical reference model that offers classification of broad standard information base and platform services, which is concerned with open industry database standards. Transaction management framework makes an abstract technique on a java platform. This abstraction, which is capable of functioning in all setups of the java platform, is different from JTA, which only supports global transactions and nested transactions, besides requiring an application server. Setting up of transactions system can be done through configuration without the need of applying JTA (Greta 26).
Joint Vision is a concept template that shows how America’s armed forces will direct the innovation and vigor of their citizens and exploit technological opportunities to attain fresh heights of joint war effectiveness. This template shows how America can adopt a common channel towards its services through a joint framework that ensures the development of unique capabilities in preparation for a more challenging and uncertain future. The joint vision 2010 was described by its chairperson as, “The nature of modern warfare demands that we fight as joint a team. This was important yesterday; it is essential today, and it will be even more important tomorrow” (Schekkerman 146).
Joint Vision 2010 (JV 2010) forms an extensive framework for comprehending joint combat in the upcoming days and for improving the direction of service programs and capability to fulfill its provisions. JV 2010 identifies four operational conceptions, including dominant maneuver, precision engagement, full dimensional protection, and focused logistics. The four conceptions are combined to guarantee the dominance of the American forces. The perception is that this dominance requires information superiority, such as “the capability to collect, process, analyze, and disseminate information while denying an adversary the ability to do the same” (Schekkerman 146).
In recognition of the joint operation’s combat, the assistant secretary of defense proposed a directive in 1995 to a group of combat officials. The directive aimed at unifying DoD technical architecture such that the future systems can bear interoperable and joint. Following these developments, a Joint Technical Architecture Working Group (JTAWG) was formed and proposed to use Army Technical Architecture (ATA) as a roadmap towards JTA.
The DoD instantiated the C4ISR Architectural framework in 1996, with the aim of finding a direction for documenting system architecture, which permits the promotion of interoperability and comparability across services, projects, and systems, for the agencies and contractors. To enhance this framework, it has been reviewed severally, hence reaching what is called DOD Architecture Framework (DODAF). The objectives of JTA and C4ISR integration’s task force suggestions were aimed at providing a strong basis to carry on with the improvement of DoD’s technical structure strategy (Zachman(a) 25).
The C4ISR architecture framework identifies the DoD products that relate to a set of technical standards and the technical architecture view. The C4ISR Architecture Framework defines the supporting technical architecture products in the JTA source document. The technical architecture view incorporates the operational requirements chosen from the JTA and other sources. The JTA could as well form the on which the DoD-wide virtual internet could be designed.
The JTA is primarily built to smooth the progress of C4ISR system interoperability. Originally, JTA was perceived to be a minimal set of rules and standards, principally borrowed from the private division, that would enhance interoperability and integration of developed or acquired DoD C4ISR contained in an internet-type structure. In fact, JTA does away with most of the crucial standards that lie behind the private-sector internet, such as IP and associated standards. However, the number of JTA standards has increased over time because the services want the inclusion of legacy systems within JTA and due to the development of new internet standards.
The limitation of such an overlapping approach to managing JTA, which involves multiple support of the same information system using the same architecture, is that it might compromise the original interoperability objectives. The current DoD C4ISR systems stand for a very intricate environment involving numerous objects, communication systems, and functions, all build on achieving definite prerequisites (Schekkerman 146).
DoDAF delineates a set of views that help in visualizing, assimilating, and understanding the complexities and wide range of architecture characteristics through behavioral, structural, ontological, temporal, graphical, or pictorial means. This architecture is most effective with outsized systems that experience intricate interoperability and integration challenges. This framework applies unique operations views because of the way it offers an extensive description of the externals operating field in regard to the customer. This is the developing system on which the system operates. This architecture makes it possible for DoD to use commercial products since communication within the industry is enhanced.
DoDAF was initially set up to direct the development of architectures. It offers an environment that represents a comprehensible architecture relative to a general determinant that originates from international borders, joint, and department of defense. The critical aim of DoD is to investigate whether the descriptions of the architecture are comparable and related across mission areas, programs, and the enterprise, therefore, forming the basis for analysis that puts up decision-making process across the DoD (Schekkerman 146).
Works Cited
Gartner. Enterprise Architecture. 2011. Web.
Gregg, Kreizman. Gartner Enterprise Architecture Process: Evolution 2005. New York, NY: Springer, 2005. Print.
Greta, James. Handler, Anne Lapkin, and Nicholas Gall. Gartner Enterprise Architecture Framework. New York: sage, 2008. Print.
O’Rourke, Carol, Neal Fishman, and Warren Selkow. Enterprise Architecture Using the Zachman Framework. Boston, MA: Course Technology, 2003. Print.
Perks, Col, and Tony Beveridge. Guide to Enterprise IT Architecture. New York, NY: Springer, 2003. Print.
Schekkerman, Jaap. How to survive in the jungle of enterprise architecture frameworks: creating or choosing an enterprise architecture framework. New York: Trafford Publishing, 2006. Print.
Zachman(a), John. “A Framework for Information Systems Architecture.” IBM Systems Journal 26. 3 (1987): 23-29. Print.
Zachman(b), John.The Framework for Enterprise Architecture: Background, Description and Utility. New York: Zachman Institute for Framework Advancement, 1996. Print.