Simon Rohrer Redefines Modern Enterprise Architecture: Emphasizing Outcome-Driven Design

Simon Rohrer began his GOTO 2025 talk by discussing the modern definition of Enterprise Architecture (EA). He cited Barry O'Reilly's remark that 'enterprise architecture doesn't exist,' acknowledging skepticism towards traditional EA.

This reflects the understanding that current enterprise architecture struggles to resolve the complexities of modern businesses using only past principles and practices. Rohrer opened his talk by presenting the necessity of a new approach within this context.

Simon Rohrer explained that modern enterprise architecture is inspired by Dave Farley's approach to modern software engineering. This suggests a departure from past enterprise architecture methods, focusing instead on 'outcomes.'

Rohrer emphasized that this new approach should not merely remain technical but should concentrate on creating actual business value and deliverables. This means enterprise architecture must evolve beyond just designing and managing systems to become a strategic tool that directly contributes to corporate performance.

Simon Rohrer presented the 'ABCD' model as the five core elements of enterprise architecture for modern businesses. 'A' signifies 'Aligning people and value and technology.' This aims for all elements to work in synergy towards a common goal.

'B' emphasizes 'Better value sooner, safer, happier,' reflecting Lean principles and Agile philosophy. 'C' denotes a 'Continuous and conversational' approach, indicating that architecture should evolve through constant communication and feedback. 'D' aims for 'DevOps at enterprise scale,' maximizing efficiency through the integration of development and operations. Finally, 'E' stands for 'Evolutionary enterprise architecture,' stressing that architecture is not static but must continuously change and adapt.

Simon Rohrer discussed the early history of software engineering, referring to the 'Chaos Report' published by the Standish Group in 1994. This report presented shocking statistics, stating that approximately 70% of software projects failed at the time, prompting fundamental reflection on existing software development methods. This served as a critical backdrop for the emergence of modern architectural approaches.

Simon Rohrer pointed out that traditional software development methods of the past were highly inefficient. He explained that the problem was a staged process: months spent on planning before coding, then months on coding, followed by months of testing by a separate test team.

This approach led to disconnections between stages and significant increases in correction costs when issues were discovered late. Rohrer emphasized that such long-cycle waterfall models are entirely unsuitable for today's rapidly changing business environment, advocating for new approaches.

Simon Rohrer stressed that the distinction between monoliths and microservices in software architecture misses the core point. Instead, he explained that team-owned software and independent deployment and testing are far more crucial.

He argued that the success factor in modern software development is not the architectural form itself, but rather teams taking responsibility for their software and leading the entire process from development to deployment and operation. This enables faster and more efficient development through team-centric autonomy and accountability.

Simon Rohrer clearly redefined the role of a modern enterprise architect. He explained that architects should not be people who dictate to teams what to do, but rather 'coaches' who help team members make the right architectural decisions within the team. Architects, as team members, should empower teams, provide technical guidance, and support them in finding optimal solutions.

This shift in role aligns with modern organizational culture, moving away from traditional top-down decision-making structures to foster team autonomy and collaboration. Architects share knowledge and offer advice based on experience, helping teams to grow and develop independently.

Consequently, the architect's role contributes to maximizing team performance based on technical expertise and enhancing the architectural capabilities of the entire organization.

Simon Rohrer pointed out that it is virtually impossible for enterprise architects to hold the entire complex modern system in their heads. Instead, he emphasized that the architect's role should focus on 'sociotechnical architecture.' This approach centers on team relationships and communication methods, such as who belongs to which team, what each team does, and whom to contact when information is needed.

Rohrer explained that understanding and optimizing the interactions and information flow between teams is more important than knowing every detail of the system. This implies an integrated architectural approach that considers not only technical elements but also social elements like organizational structure and communication patterns.

Such sociotechnical architecture plays a vital role in managing system complexity, fostering efficient collaboration, and ultimately contributing to the achievement of corporate goals.

Simon Rohrer presented an example of an inefficient organizational structure commonly found in legacy architectures. He cited a structure where separate teams handle UI, API layers, a 'greeting service,' a 'planet service,' and yet another team owns the database.

Such a layered team configuration requires complex collaboration and coordination among multiple teams for specific feature implementation, which is a major cause of slowing down development speed and increasing communication costs. Rohrer emphasized that this structure is unsuitable for today's fast-paced development environment and proposed breaking down team boundaries and forming function-oriented teams.

Simon Rohrer pointed out that even if it's not the best way to design microservices, small services, or monolithic architectures themselves, a layered structure between teams is highly inefficient, especially in distributed systems. An approach where each team is responsible for only a specific layer requires coordination across multiple teams when changes are needed across the service, inevitably slowing down development and increasing complexity.

This layering hinders independent deployment and operation by each team, and can also obscure accountability when problems arise. Rohrer emphasized that in a distributed system environment, it is far more efficient for teams to own and manage the entire lifecycle of a service, urging a move away from traditional hierarchical organizational structures.

Simon Rohrer explained the asymmetry of architectural complexity. He pointed out that while adding new complexity to a system might be relatively cheap, reverting or removing complexity once added is much more expensive and asymmetric. Especially in distributed systems, the cost and effort to remove complexity increase exponentially as changes must be applied across multiple locations.

This demands careful consideration in architectural decisions and highlights the importance of not introducing unnecessary complexity from the outset. Complexity can easily lead to technical debt and becomes a significant hindrance to system maintenance and expansion in the long run. Therefore, architects must carefully weigh the value and cost when adding complexity.

Simon Rohrer emphasized the importance of 'dialogue' when a new service is requested, not simply saying 'a new service is needed,' but thoroughly examining what complexity that service adds to the existing architecture. He explained that processes like submitting a 'pull request' should be used to ponder the complexity a new service would bring to the existing environment.

This leads to the question of whether a new service provides enough value to justify the additional complexity. Rohrer stressed that architects must go beyond simply adding new features to consider overall system complexity management and long-term maintenance costs.

Simon Rohrer emphasized the importance of platform strategy, explaining that using standardized platforms provided by the company can largely automate 'architectural compliance.' Since the platform already meets most checklist items or resolves a significant portion of them, development teams can adhere to security and architectural standards with minimal additional effort.

This helps developers focus more on core business logic and contributes to maintaining enterprise-wide architectural consistency. Rohrer suggested that platform usage is an efficient method for ensuring overall technical health and compliance within an organization.

Simon Rohrer stressed that modern enterprise architects do not simply work on the 'dev' side. He emphasized that architects must collaborate and communicate very closely with colleagues working in service management and 'service reliability' areas.

This means moving away from traditional silo structures and approaching architecture from an integrated perspective that encompasses development, operations, and reliability. Rohrer explained that this high level of collaboration and alignment is essential for the success of modern enterprise architecture.

Simon Rohrer explained that the essence of a 'full product team' is not merely technical, but also includes 'product ownership.' This means that a product team must take overall responsibility not just for developing code, but for the product's vision, strategy, user experience, and post-launch success.

Rohrer emphasized that a true product team emerges when technical capabilities are combined with business insight and product management skills. This approach ensures that the product better meets market and user needs and lays the foundation for long-term success.

Simon Rohrer stressed the need for continuous attention to system complexity. He warned that if neglected, entropy would erode the system, and continuous investment to reduce 'complexity debt' is essential. He mentioned allocating 20% of the budget for continuous improvement, clarifying that complexity management is not a one-time task but an area requiring ongoing effort and resource allocation.

This continuous investment plays a decisive role in maintaining system health, reducing future development and maintenance costs, and ensuring the company's technical agility. Rohrer implied that complexity management is not merely a technical issue, but a critical financial investment for business continuity and innovation.

Simon Rohrer recalled that about seven years ago, when the Standish Report was published, he mentioned it was 'time to forget projects and focus on software development and implementation.' He argued that since companies already know they will spend money on software, they should no longer be tied to short-term projects but transition to a sustainable, product-centric mindset.

This emphasizes the understanding that software development is not a one-time event but a continuous process of improvement and value creation. Rohrer stressed that moving away from a project-centric mindset to an approach that takes responsibility for the entire product lifecycle is essential for the success of modern enterprises.