Chatper 5.3 - Enterprise Architecture for Collaboration

Revamping Enterprise Architecture for Collaboration#

Enterprise Architecture Management (EAM) has traditionally been a top-down affair, driven by leadership at the top echelons of a company. This approach, while structured, comes with its own set of advantages and limitations, reflecting a more classical view of EAM implementation within corporations.

Historical Context and Critique of Classic EAM#

Initially, IT departments were the champions of EA, recognizing the need to understand business operations to offer effective and economical IT support. This shift emerged from an IT-centric focus that often neglected the broader business perspective. Despite this progress, criticisms of EAM persist, both in the discipline itself and in its practical application within organizations. Figure below illustrates the negative perceptions of EA on one side and the requirements for an enhanced EAM on the other.

EA is often viewed as a top-down, bureaucratic entity, laden with governance protocols that slow down projects and operations due to excessive controls and approval processes.

EA’s goal of providing a holistic view is compromised if it becomes another silo, disconnected from IT and business units. Without collaboration, control mechanisms are less effective and can impede teamwork.

EA groups sometimes earn a reputation for being isolated “ivory towers,” with a theoretical grasp of business architecture but little practical engagement with operational processes. Enterprise architects must understand:

• Why current processes are designed as they are
• Unique aspects of the business
• Business rules and procedures

Engaging with other staff members is essential, but architects should focus on resolving business issues, not just fulfilling EA tasks like data collection or reducing software application numbers.

Frameworks are pivotal in EA, heavily featured in literature and consultancy services. Yet, merely adopting a framework like TOGAF without understanding the underlying problems can lead to an EA organization that exists in name only, without effectively addressing issues.

Excessive documentation and “future-state” planning by disconnected architects can meet resistance from other departments. It’s critical to base such decisions on solid business knowledge to gain buy-in.

Complicated standard maps and documents are often indecipherable to those without EA expertise, eroding trust in the EA team’s ability to facilitate business change.

Past initiatives have failed when EA did not deliver tangible benefits, being perceived as a cost center rather than a value-adding entity. Effective EAM requires extensive information gathering and method development to truly enhance business and IT alignment.

Towards a Collaborative and Agile EAM#

The right side of Figure above points to emerging literature advocating for a more flexible, cooperative EA organization. This new paradigm emphasizes:

• Implementation alongside stakeholders
• Collaborative work modes over governance by control
• Support for other departments by delivering results and value
• Engagement with business needs and stakeholder activities

Innovative approaches are integrating techniques from other successful disciplines, such as:

• Lean techniques from business process management
• Agile methods from software development
• Principles from lean organization design
• Incorporating social media into EAM tools

These methods aim to create a flexible EA methodology centered on business needs. This approach is adaptable to changing objectives and focuses on producing only those documents that provide real value to stakeholders.

The EA organization must prioritize understanding business requirements before data collection. It should aim to deliver immediate benefits through relevant visualizations and clear value propositions tailored to business needs. The following sections will explore potential structures for such an organization.