Lesson 2: Enterprise Architecture and Architectural Views

Enterprise architecture looks at an organization as a whole and asks how business goals, processes, applications, data, and technology should fit together. In simple terms, it prevents IT from becoming a random collection of disconnected tools.

A practical way to understand enterprise architecture is through four common domains:

Suppose a Philippine hospital wants to connect patient registration, laboratory results, and billing. The business architecture describes patient intake and discharge workflows. The application architecture lists the hospital information system, lab system, and billing platform. The data architecture defines patient IDs, records, and result formats. The technology architecture covers servers, networks, cloud services, and endpoint devices.

Systems integration becomes easier when these four views are aligned. If they are not aligned, the team may connect software that does not support the real process or moves data with unclear ownership.

Enterprise architecture is therefore not "only for large corporations." Even a medium-sized school, cooperative, clinic, or retail chain benefits from clear architectural thinking.

No single diagram can explain a whole system to everyone. Managers care about workflows and impact. Developers care about modules, APIs, and dependencies. Database staff care about structures and quality rules. This is why architects produce different views of the same solution.

Common architectural documents include:

• Context diagram – shows the system and its external actors or connected systems
• Component diagram – shows major internal building blocks
• Data flow diagram – shows how information moves
• Deployment diagram – shows where components run
• Interface specification – explains how one system calls or exchanges data with another

A good architectural document is not just "nice-looking." It should answer design questions. For example, a context diagram should reveal whether a payment gateway is external. A deployment view should reveal whether a database and an application server are separated. An interface specification should define request and response structures, errors, and timing.

For exams, remember this rule: views are stakeholder-based. You do not create a diagram just because a tool can draw it. You create it because a stakeholder needs a certain perspective.