4.2Enterprise architecture (EA)

The representative technique that systematizes the previous section's enterprise-optimization policy into an actual blueprint is EA (enterprise architecture). EA visualizes an enterprise's operations and systems by dividing them into four domains (layers)—business, data, application, and technology—clarifies the gap between the current state (As-Is) and the target (To-Be), and bridges them with a migration plan. For an IT strategist, the practical crux of EA is correctly pinpointing "which of the four layers a currently faced issue belongs to" and designing "how to reach the To-Be step by step as a migration plan rather than realizing it all at once." This section covers the division of roles among the four domains and the As-Is/To-Be/migration relationship, framed as the judgment of a strategist leading enterprise optimization.

4.2.1EA's four domains (BA/DA/AA/TA)

• The business architecture (BA) is the domain of operations, organization, functions, and business processes—expressing "what operations are performed and in what flow." Inefficiency or duplication of the business process itself is an issue of this layer.
• The data architecture (DA) is the structure, taxonomy, and interrelationships of the data operations handle. Problems such as data duplication or inconsistency, or masters split per department, are issues of this layer.
• The application architecture (AA) is the individual applications (system functions) that support operations and their integration. Problems such as a proliferation of systems with the same function, or difficulty integrating systems, are of this layer.
• The technology architecture (TA) is the technical infrastructure that runs the applications (hardware, network, OS, middleware, cloud platform, and so on). Aging infrastructure and foundational constraints on performance or availability are issues of this layer.

4.2.2As-Is, To-Be, the migration plan, and reference models

• Draw the As-Is (current state) and To-Be (the ideal target) for each domain and analyze the gap between them. The migration plan shows in what order to close the gap—designing a stepwise path to the To-Be that accounts for risk, investment, and operational impact rather than realizing it in one leap.
• A reference model is a template for standardizing and reusing each domain's design (business reference model, data reference model, service-component reference model, technical reference model, and so on). Basing design on a reference model rather than designing from scratch raises company-wide consistency and design efficiency.

An IT strategist is pinpointing several issues layer by layer from an EA viewpoint. The field has raised four: (a) in order-taking, the sales department and the shipping department each perform the same input separately, twice; (b) customer data is held separately in three systems—sales, maintenance, and accounting—so an address change is not reflected in all systems and inconsistency arises; (c) three order systems with very similar functions proliferate per division, requiring individual interface development each time they integrate; and (d) the core server is aging, so during peak season the response worsens at the limit of the infrastructure's performance. Rather than blindly trying to solve these by "swapping systems," the strategist first pinpoints which domain each issue belongs to. (a) is duplication of the business process itself, so it is a business architecture (BA) issue, and the main line is redesigning the process to eliminate the double input. (b) is a problem of data structure and how data is held, so it is a data architecture (DA) issue, solved by company-wide sharing of customer data and master integration. (c) is a proliferation of same-function applications and difficult integration, so it is an application architecture (AA) issue, and the direction is to share the order function and organize an integration platform. (d) is a performance limit of the technical infrastructure, so it is a technology architecture (TA) issue, solved by infrastructure renewal or cloud migration. Mispinpointing the layer causes a miss—for example, trying to solve data inconsistency (a DA problem) by introducing a high-performance server (a TA measure), where the inconsistency does not resolve despite the investment. Next the strategist draws the As-Is and To-Be for each layer and, rather than closing the gap all at once, designs a migration plan. For instance, "first integrate the customer master as DA (stage 1), next reorganize each order system to reference the shared platform as AA (stage 2), and finally renew the aging infrastructure as TA (stage 3)," deciding a stepwise order of arrival that accounts for investment, risk, and operational impact. Trying to realize the To-Be in one leap invites the risk of operational stoppage during migration and a concentration of investment, so staging via the migration plan is precisely the practical crux of EA.

4.2.3Section summary

• EA visualizes operations and systems in the four domains BA/DA/AA/TA as a means of enterprise optimization
• Correctly pinpoint which domain (layer) an issue belongs to (data inconsistency = DA, platform performance = TA, etc.)
• Via As-Is -> To-Be -> migration plan, reach the enterprise optimum stepwise, accounting for investment, risk, and operational impact