Enterprise Architecture Governance – Why It Is Important (Part 1)

(Editor’s Note: This is Part 1 of Enterprise Architecture Governance – Why It Is Important, written by Dr. Gopala Krishna Behara. Part 2 will publish Thursday, August 19.)

Enterprise Architecture Governance (EAG) comprises the Enterprise structure and a set of policies, processes, and procedures by which enterprise can control the IT solutions it deploys to ensure that they are consistent with the enterprise architecture vision, principles and standards.

EA Governance is the responsibility of not only the IT executives (CIO and IT Directors), but also executives from business organization as well, along with critical participation from Enterprise Architects, Domain Architects, Subject Matter Experts and other support staff throughout the enterprise.  Successful enterprise designing is not simply a function of the IT organization, but needs the total enterprise’s participation.

Lack of or improper EA Governance leads to ineffective EA thereby resulting in not reaping the benefits of EA. Without a proper EA Governance, organization cannot maintain proper alignment of business and IT. This will also result in non-standard technology/product selection/purchasing, inconsistencies in architectures that lead to monolithic implementations (“built in silos”), which are very hard to integrate with internal and external systems. In the absence of a proper EA Governance model/process, EA data becomes stale or obsolete and hence becomes useless or less useful impairing strategic decision-making based on this stale/obsolete data thereby defeating the very purpose of EA.

EA GOVERNANCE VS IT GOVERNANCE

EA Governance consists of organizational leadership, organizational structure, direction and processes that ensure Information Technology (IT) sustains and extends the enterprise’s vision, mission, strategies and goals in a  planned manner.

IT Governance is defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals.

EA Governance is not same as the IT Governance.  The following table describes the high-level comparison of EA Governance and IT Governance.

Aspect EA Governance IT Governance
Nature Primarily strategic Primarily operational
Scope Enterprise-wide Restricted to IT
Focus Directing the evolution of the enterprise towards achieving desired business objectives and competency Directing how IT services can enable business operations
Responsibilities •       Enterprise-wide policies, standards, guidelines, and procedures – covering business, data, applications and technology

•       Future design of the IT environment

•       Ensure effectiveness of IT services

•       IT project management, configuration management, incident and problem management, disaster recovery plans

The following diagram depicts the indicative end to end governance of an organization and their relationships.

gopola 8 18 1

CHALLENGES IN EA GOVERNANCE ADOPTION

EA is an ongoing activity that helps in managing and maintaining architecture of the organization. It is not an isolated discipline, but an integral part of an enterprise to look after business and IT alignment.

As an architect being part of many EA programs, I have come across following major challenges,

  • Role of EA is not articulated across the line of businesses of an organization
  • Involvement of EAs are not extended at project and product team level. EAs operate at high level
  • EA training programs are ad hoc and not formally adopted across organization. Enterprise Architecture competencies and related skill sets are missing across organization
  • Duplicate EA efforts across enterprise due to lack of identified scope of each EA domain and responsibilities
  • All activities within each EA domain are being performed by individual EA teams – more as silos
  • Enterprise Architecture Review Board (EARB) exists at some organizations, but not fully functional. Roles and responsibilities are not clearly articulated. EARB is only paper tigers
  • EA Governance processes are limited to reviews and approvals
  • Architecture governance content such as service level agreement within organization, Metrics, regulatory requirements, Metrics etc. are not defined and documented
  • Ad hoc usage in absence of governance content will lead to non-standard adoption, extra effort & cost for IT Infrastructure

GUIDING PRINCIPLES OF EA GOVERNANCE

The Objectives of the EA Governance are,

  1. Ensure enterprise is adopted and complied
  2. Guide the decision making process in order to maintain architectural coherence
  3. Enable architecture assurance for all key stakeholders
  4. Maintain the relevancy of the enterprise to meet changing requirements.

Design and planning of any new development should relate to its context, which is a series of processes, cultural orientation and a set of owned responsibilities. It is, therefore, important to understand the context of EA governance in the wider scheme of things surrounding EA initiatives of the enterprise any attempt to form a governance strategy taken.

The EA Governance Guiding Principles are broadly classifying into People, Process and Technologies.

People

  • Every element of the IT Architecture will have an identified owner
  • Enterprise Architecture will drive enterprise technology service provisioning through focus groups of technology domain expertise.
  • Corporate IT must provide policy guidance, advice, and assistance in the definition, design and implementation of Enterprise Architecture discipline and practice throughout the enterprise
  • Architectures facilitate change. Architectures continuously change and require transition
  • IT services will be provisioned and made accessible to the enterprise by architects

Process

  • Enterprise architectures must reflect enterprise strategic plan
  • IT processes and systems will conform to the Enterprise Architecture
  • All Enterprise assets and information entrusted to IT will be secured in accordance with business objectives
  • Enterprise Architecture will enable solutions, services, processes, and support that are consistent across all business units
  • Architecture will build in capability of scaling up or down IT resource requirements in response to changes with minimal impact to IT total costs
  • A framework is needed to model and apply enterprise architecture disciplines
  • Enterprise Architecture will need to continue refreshing and updating the framework as well as the taxonomy, and to mature the enterprise architecture model
  • Solution architecture development process must be monitored, reviewed, and validated to minimize risks and optimize results
  • IT values must be mapped out and managed to understand and control IT total cost of ownership
  • IT decision processes will balance the IT risk vs. business reward to achieve business objectives
  • Technology selection when implementing a solution will include an assessment of build, buy or reuse of available packages and development options.
  • Information Technology will assess and plan for obsolescence, including retirement planning, when selecting solutions to meet business requirements
  • Approved standards will conform to industry standards unless they conflict with specific business objectives

Technology

  • Technologies will be leveraged to enable and support business
  • All technology adoptions and retirements must follow the evaluation process defined in the IT Architecture, and must consider operational aspects and lifecycle management
  • Elements of the IT Architecture will be designed, implemented and tuned to meet the service requirements of each application system they support
  • Elements of the IT Architecture will be designed and implemented to meet the business continuity requirements of each business system they support
  • Architectures must be appropriately scoped, planned, and defined based on the intended use of the architecture
  • Architectures must allow many disparate hardware and software systems to connect and integrate with each other, and exchange data as needed to perform the desired business transactions

Part 2 will be shared tomorrow, August 19.

Dr.Gopala Krishna Behara is a Distinguished Member and Lead Enterprise Architect in Wipro Technologies with 25+ years of extensive experience in the ICT industry. He serves as an Advisory Architect, Mentor on Enterprise Architecture, Application Modernization and continues to work as a Subject Matter Expert and Author. He is certified in Open Group TOGAF, AWS Solution Architect -Associate, IBM Cloud Solutions and UNPAN. Published number of research papers, books in IT industry. He has been a speaker at National and International forums and bodies like The Open Group, National e-Governance Forum. He has been a moderator and panel member for multiple technical/business forums like IGI Global, AEA, Open Group and Premium College meets. Recipient of EA Hall of Fame International Award – Individual Leadership in EA Practice, Promotion and Professionalization Award.  He can be reached at gopalakrishna.behara@gmail.com

The views expressed in this article/presentation are that of authors and Wipro does not subscribe to the substance, veracity or truthfulness of the said opinion.

1 Trackback / Pingback

  1. Enterprise Architecture Governance – Why It Is Important (Part 1) - Slowhorse Ltd

Comments are closed.