Software and Enterprise Architecture

TOGAF's Architecture Development Method (ADM) organizes work into phases. Phase A is Architecture Vision, B is Business Architecture, C is Application Architecture, and D is Technology Architecture. Phase D explicitly focuses on defining the technology components needed to support the application components defined in Phase C.

Technology architecture models should address technical concerns: security mechanisms, network/hardware topology, communications protocols, and standards compliance. The executive management view (strategic/business-focused, high-level KPIs) adds minimal value to detailed technology architecture modeling - executives don't need nor use low-level technical diagrams.

Technology Architecture deliverables include the gap analysis report (A), requirements traceability (B), technology architecture models/diagrams (C), and technical specifications for building blocks (D). Architecture contracts (E) are formal governance agreements that come AFTER architecture is defined - they're not part OF the Technology Architecture content itself, but rather the mechanism to implement it.

Interoperability is the ability of different applications or systems to exchange information and work together, even when running on different platforms or built by different vendors. Serviceability (A) is ease of maintenance. Portability (B) is running on different platforms. Extensibility (C) is adding features. Scalability (D) is handling growth.

Portability is the characteristic describing how easily an application can be moved from one platform to another (e.g., Windows to Linux, one cloud provider to another). Extensibility is adding functionality. Interoperability is communication between systems. Availability is uptime. Serviceability is ease of maintenance.

Serviceability refers to how easily a system can be diagnosed, repaired, or upgraded while operational. It focuses on maintenance capabilities like identifying faults and applying fixes without downtime. Availability (A) is about uptime, manageability (B) is about administration ease, extensibility (C) is about adding features, and usability (E) is about user experience.

Nonfunctional criteria (also called quality attributes) describe how a system behaves rather than what it does. Availability is a classic nonfunctional requirement specifying the percentage of time a system must be operational. Requirements (A), specifications (E), and failure modes (C) are functional or process-related, while defect density (B) is a quality metric rather than a requirement type.

Nonfunctional criteria define system qualities like performance, security, reliability, and usability. Scope refers to what features the system must deliver, making it a functional requirement. Reliability (A), availability (B), serviceability (D), and security (E) are all quality attributes describing how well the system performs.

In technology lifecycle management, Emerging technologies are those that are proven and available but not yet mainstream. They can be used selectively in new implementations but are not yet recommended for broad adoption. Installed/support (A) describes Legacy, sunset path (B) describes Declining, and strong recommendation (C) describes Core Architecture.

Core Architecture represents technologies that are mature, stable, and proven in production environments. These are strongly recommended for new implementations because they offer reliability and industry acceptance. Installed/support (A) is Legacy, sunset path (B) is Declining, and limited use (D) is Emerging.

Identity and Access Management (IAM) services focus specifically on identity operations: Authentication (verifying identity), Authorization (controlling access), Directory services (storing identity data), and User management (provisioning accounts). Infrastructure services (A) refer to compute, network, and storage resources which are foundational IT components rather than identity-specific functions.

SOAP (Simple Object Access Protocol) is the complete web service framework that defines the XML message format, HTTP binding conventions, and RPC representation standards. XML (B) is just the data encoding format, UDDI (C) is for service discovery registry, and WSDL (D) describes the service interface but not the message protocol itself.

Password synchronization automatically propagates password changes across multiple systems to ensure consistency. When a user changes their password on one system, synchronization updates it on all connected systems. Single sign-on (A) is about logging in once, password management (B) is about overall policy, and self-help (C) is about user-driven reset workflows.

Web service consumption follows the pattern: discover the service in UDDI (registry), retrieve its WSDL description (interface definition), then bind using SOAP (message protocol). Option D correctly sequences these steps. Options A-C incorrectly pair the protocols with their purposes or reverse the registry relationship.

Identity and Access Management (I&AM or IAM) is indeed a comprehensive discipline combining processes, technologies, and policies to manage digital identities throughout their lifecycle. It encompasses creation, maintenance, and termination of identities plus governing how those identities access resources. This definition accurately captures IAM's holistic nature.

The statement reverses the standard definitions. Authentication is the process of validating user credentials (proving who they are), while Authorization is the process of granting or denying access rights and permissions (determining what they can do). Since the statement claims the opposite, it is false.

Directory services act as the central repository storing user IDs, credentials, and profile information. They play a critical role in authentication by providing the data against which login credentials are verified. Authentication services (A) perform the verification, authorization services (B) control permissions, and personalization services (D) customize user experiences.

Inversion of Control flips the traditional flow: instead of your code calling a library, the framework calls your code. This enables workflow processing as the framework controls execution sequence. Options B, C, and D misrepresent IoC - B is the opposite pattern, while C and D introduce unrelated concerns.

Frameworks provide reusable components, APIs, and tools that developers can leverage rather than building everything from scratch. This is the core value proposition - a toolbox of pre-built functionality. Options A, C, and D are incorrect: frameworks are not application servers, not development environments, and not finished applications.

The key difference is control flow: in a library, your code controls execution (you call library functions). In a framework, the framework controls execution and calls your code at specific points (hooks, callbacks). Option D captures this. Options A, B, and C are false - libraries don't necessarily have default behavior, extensibility varies by design, and library code can often be modified if source-available.