From Software Engineering to Enterprise Architecture: Evolution of Design Methodologies and the Role of EBA and the Middle Platform

The author begins by reflecting on the difficulty of deciding what to design, quoting Frederick P. Brooks: “The hardest part of design is deciding what to design.” This sets the stage for a discussion of architecture methodology.

Software engineering began in the 1940s with the ENIAC, but early development lacked formal engineering practices. The 1968 NATO conference introduced the term “software engineering,” emphasizing systematic, economical development.

In 1970 Winston Royce described the Waterfall model, dividing development into seven stages. Although Royce warned of its risks, the model became a de‑facto standard, with the analysis phase implicitly covering architectural design.

The 1987 Zachman framework offered a comprehensive enterprise‑architecture model based on six dimensions (What, How, Where, Who, When, Why) and six layers, providing a 36‑cell matrix for describing an enterprise.

Barry Boehm’s 1988 Spiral model added iterative risk‑driven development, addressing Waterfall’s shortcomings in requirements management.

In the mid‑1990s the Open Group Architecture Framework (TOGAF) emerged, separating business architecture from IT architecture and defining a set of deliverables for enterprise‑wide design.

Agile development, formalized in 2001 with the Agile Manifesto, challenged the Waterfall approach by promoting incremental delivery and lightweight documentation. While Agile focuses on product and user concerns, it often neglects the extensive documentation required by enterprise architecture.

Domain‑Driven Design (DDD), introduced by Eric Evans in 2003, aligns domain models with software design, offering a unified language within bounded contexts. DDD complements microservices by guiding service decomposition.

Microservices, popularized by Martin Fowler and James Lewis in 2014, advocate independently deployable services with dedicated data stores, enabling flexibility, scalability, and technology heterogeneity.

The article then shifts to Enterprise Business Architecture (EBA). EBA aims to understand business capabilities, model them structurally, and translate them into IT implementations, providing a strategic bridge between business goals and technical solutions.

Real‑world EBA cases are highlighted: the US Patent and Trademark Office’s TMNG project and China’s large banks (e.g., Construction Bank) that used EBA to restructure core systems, map thousands of business components, and drive digital transformation.

EBA’s design process is illustrated with several diagrams (general process, overall logic, and iterative IT implementation), emphasizing “knowledge‑action unity” and the need for organizations to cultivate architectural expertise.

The relationship between EBA, DDD, and microservices is explored. While EBA focuses on enterprise‑level data models and capability reuse, DDD provides bounded‑context modeling for service design, and microservices implement those services. Combining them can yield a coherent, scalable solution, but trade‑offs in data modeling and coupling must be managed.

Agile methods can accelerate EBA implementation when business architects participate in Scrum teams, ensuring that rapid iterations stay aligned with the strategic EBA blueprint.

The concept of the “middle platform” (or “mid‑platform”) is examined. Originating from Alibaba’s practice, the middle platform seeks to modularize and service‑orient business capabilities, reducing system complexity and enhancing reuse. It shares goals with EBA but differs in execution details.

Discussion continues on whether the middle platform is a specialized (context‑specific) or generalized methodology. The author argues that while Alibaba’s implementation is highly specialized, a generalized approach requires clear articulation of tools, costs, and applicability for different enterprises.

Finally, the article looks ahead to open architecture, where internal unified architectures evolve to collaborative ecosystems that integrate external partners and customers. Banking industry examples illustrate the transition from fragmented mainframe systems to centralized enterprise architectures and now toward open, ecosystem‑driven designs.

Overall, the piece identifies three major trends: moving from software to enterprise architecture, combining multiple methods into a “combo‑punch,” and shifting from closed internal designs to open, ecosystem‑centric architectures.