The purpose of the Enterprise Architecture (EA) team should be to provide expertise in business processes, enterprise systems, and data to help executives frame strategy. EA should provide advice to executives in leveraging processes, technology, and data to drive business outcomes. EA team should be identifying opportunities for significant process improvements, helping executives adjust systems and processes to changing market conditions, and alerting them of risks and bottlenecks in systems and processes. Unfortunately, many times EA teams focus on creating documentation, spend the majority of their time reviewing architectures and stamping approvals. Hence, EA is often criticized for slowing progress, hindering innovation, and creating non-value-add documentation and processes. Leading Enterprise Architecture Frameworks are a great example of process-heavy, rigid and documentation-centric frameworks that justify large Enterprise Architecture organizations that produce expensive non-value-add work. The cost of EA based on these frameworks becomes difficult to justify. In this article, we propose an alternative organizational structure for the EA team to address these issues.
We believe the EA team should consist of a small diverse group of Enterprise Architects with expertise in Business Architecture, Solution Architecture, Information Architecture, and Technology. These Enterprise Architects should be experts in their field with deep knowledge of the industry. The core purpose of this team should be to help business executives succeed in achieving business outcomes. Hence EA should focus on high-impact initiatives at the senior executive level. In addition, EAs can act as advisors on key strategic programs. They should not be used for stamping approvals of architecture documents.
We suggest the Enterprise Architecture Team report to a business executive in the company’s leadership team. Ideally, this executive should be Chief Digital Officer, or someone with the responsibility for enterprise processes and operations (such as COO). EA team can be dotted lined to other executives including CIO. This alignment ensures EA is focused on business goals and objectives and doesn’t get sucked into IT programs, projects, and architecture review sessions.
While enterprise architects should be available for strategic advice and planning during the initial phases of programs, CIO should have a pool of Solution Architects to provide deeper architecture engagement and oversight.
EA team should also include at least one Enterprise Information Architect and one Principal Technologist. There should be a separate Data Architecture team for platforms, programs, and projects under Chief Data Officer. Similarly, Solution Architecture Team should report to CIO and should be assigned to programs. A pool of Technical Architects should be reporting to CTO and can be assigned to projects. We believe that using the EA team for Solution and Technical Architecture on programs and projects undermines the effectiveness and value of Enterprise Architecture.
An Enterprise Architect should be a skilled business analyst with expertise in business process optimization, complex problem-solving skills, and expertise in applying information technology to achieve business outcomes. While the EA team should also include expertise in enterprise information architecture, technology, and solution architecture. We recommend EA team to be no more than a 10 member group. EAs should be responsible for supporting senior executives build business strategy, achieve business outcomes, optimize processes, provide clarity for the entire organization on key business processes and entities. EAs should not be managing projects or selling solutions to managers. Selling solution to the organization is not EAs job. This approach only builds resistance to EA and results in organizational politics and is detrimental to EA organization. As such EA team should primarily serve up the organization hierarchy.