The Open Group Architecture Framework (TOGAF)
TOGAF Architecture Skills Framework has benefits and relevance in reducing time, risks associated with training, hiring and managing IT system in professional manners. TOGAF makes communication system simple between employment agencies and organizations.
It also reduces time wastages during interviews. TOGAF is also relevant in reducing time and costs of setting up an internal IT architecture. The process is complex and requires expertise. Organizations save costs in overall IT implementation. It eliminates chances of unsuitable persons getting the job (The Open Group 7).
However, TOGAF increases costs of personnel due to constant needs for reassigning, and resignation of staff. In cases of poor staff assignment, TOGAF may have adverse effects on quality of operational IT challenges.
How does it contrast and compare with the Zachman Framework
TOGAF has four divisions of enterprise architecture. These include business architecture for fulfilling business goals. Application architecture shows specific design and interaction between various designs. Data architecture shows how organizations store and access their data, and technical architecture talks of a system hardware and software application (Brach 86).
TOGAF most essential area is the Architecture Development Method (ADM). ADM has a robust means of creating architecture. This may include process in creating architectural design. We can see TOGAF as an architectural framework, process or methodology under as classified under ADM.
When we take TOGAF as an architectural process, then it functions as a complement of Zachman. In this case, Zachman is an architectural taxonomy. The difference is that Zachman enables us to classify artifacts, whereas TOGAF gives us the opportunity of creating artifacts (O’Rourke, Fishman, and Warren 30).
TOGAF looks at enterprise architecture (EA) in terms of “highly generic to highly specific” (The Open Group 16). In other words, TOGAF treats EA as a continuum of architecture. In this case, ADM of TOGAF offers the process of creating artifacts from generic to specific.
TOGAF has Foundation Architectures as the most generic level for any IT application in organizations. Common Systems Architectures is another level of specificity, which we expect in most EA applications but not all. Industry Architectures are common and specific across same domain in the same industry. The Organizational of TOGAF is the most specific. These artifacts are specific to only given EA (Perks and Tony 56).
How does this approach to architecting deal with systems integration in an SOS environment?
We can look at SOS (System-of-Systems) as “a set or an arrangement of systems that result when independent and useful systems are integrated into a larger system that delivers unique capabilities” (Gansler 2). SOS offers cross links for changes in doctrines and modern transformation of systems.
SOS is an integrated system. It provides the basis for complete realization of other features. SOS depends on endurance and any expiring artifacts must be replaced for continuity. SOS consists of features that enable various components to work independently (operational independence).
SOS integration also has geographical distribution where systems can work in a coordinated fashion despite the distribution. We must also look at emerging behavior is SOS that occurs as a result of integration. SOS integration also offers opportunities for evolution through modification or change of existing parts with new ones.
However, SOS application may experience challenges such as complexity, lack of a specific approach, issues of interface standards, testing issues, quality of information, and costs. There are also few engineers available in this field.
What is the role for the lead systems integrator in all of this?
SOS is a complicated system. This means that we need a single entity to run it. Thus, lead system integrator attempts develop a single system needs, manage development, integration, and associated risks. It also ensures coordination of schedules, efforts and contracting of procurement and development.
In short, lead system integrator provides flexibility and acquisition of adaptable partners in SOS. The role of lead system integrator depends on the program under implementation. However, people view lead system integrator as a means of losing control, creating conflict of interest, and source of competition (Gansler 3).
Modification needed for Service Oriented Architectures (SOAs)
We can modify Architecture Capability to provide the necessary support for SOA. The first move in TOGAF is to take SOA as an architecture principle either in the beginning of the process or during modification. The enterprise must also be ready to adopt SOA through conducting maturity assessment in the early stages.
This provides the rationale for the adoption of SOA. Thus, modification must take place in the areas of “principles, organizational structure, governance, and initial content of the Architecture Repository” (The Open Group 5).
SOA is not suitable for addressing the entire architectural problem in the enterprise. Instead, we should identify specific areas to use SOA. Any system that depends on SOA must ensure compatibility. Any deviation must result into appropriate changes as corrective measures.
TOGAF has standardized framework for SOA. This implies that the system can have “a high-level reference model of how SOA governance extends and supports both enterprise architecture and IT governance” (The Open Group 18).
Works Cited
Brach, Marion. Real Options in Practice. Hoboken, NJ: John Wiley & Sons, 2003. Print.
Gansler, Jacques S. “The Role of Lead System Integrator (LSI).” NPS Acquisition Research Symposium, 4 (2007): 1-20. 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-Verlag, 2003. Print.
The Open Group. “TOGAF.” Part III: ADM Guidelines & Techniques, 1 (2011): 1-50. Print.
Fig. 1: TOGAF’s enterprise architecture
Fig. 2: The TOGAF Enterprise Continuum
Fig. 3: The TOGAF Architecture Development Method (ADM)
Fig. 4: Criteria and ratings for each methodology (Source: Roger Sessions, 2007 for Enterprise Architecture)