Architecting the Connected Government: 
            Enterprise Architecture Concepts
               Defining EA
               Benefits of EA
Describing Enterprise Architecture
    •      An organization’s enterprise architecture                                   ...
Common Themes in EA
       •     Clear mission 
       •     Customer value proposition   (strategy formulation)
       • ...
Benefits of Architecture Driven Approach
   1. Captures organizational mission and business processes in an understandable...
Whom Does EA Concern?
 Business planners and managers contribute  IT planners and managers contribute to an EA 
   to EA a...
Elements of Enterprise Architecture

Architecture Description Conceptual Model

Architecture Blueprint
       • Formal description of an Architecture
       • Organized to support reasoning about the st...
Architecture Frameworks

                                                                 Source: A Comparative Study o...
Without an EA …

                                                                                Source: Enterprise Arc...
      • Enterprise Architecture Concepts
         • Defining EA
         • Benefits of EA
         • Need for an Ar...
Business Architecture (1/2)
    • An enterprise business 
Business Architecture (2/2)
      •     Specifies core business processes which execute organization’s strategy
      •   ...
Information Architecture (1/3)
   • Is a compilation of the business                                                      ...
Information Architecture (2/3)
              • Addresses issues like:
                       – What information is needed
Information Architecture (3/3)
       • Typically development of information architecture involves 
         creation of:
Application Architecture (1/2)
      • Facilitates development of                                                         ...
Application Architecture (2/2)
      Comprises of solution set which usually is a mix of:
      • In‐house developed appli...
Technology Architecture (1/2)
 • Is a disciplined approach for                                                            ...
Technology Architecture (2/2)
      • Examines the underlying technologies (technical 
        infrastructure) that is req...
      • Enterprise Architecture Concepts
         • Defining EA
         • Benefits of EA
         • Need for an Ar...
Architecture Governance
       • The practice and approach by which organizations manage 
         and control their archi...
What Does Architecture Governance Involve? 
       • Architecture governance encompasses:
               – Implementing sy...
Centralised Governance Mode

Decentralised Governance Mode

Federated Governance Mode

Singapore Government Agency (1/3)

       Source: Singapore Government Enterprise Architecture, iDA, 2006
Singapore Government Agency (2/3)
Singapore Government Agency (3/3)
(Example) Organizational Structure

Suggested Compliance 

      • Enterprise Architecture Concepts
         • Defining EA
         • Benefits of EA
         • Need for an Ar...
EA Design Model

Classical IT Planning Based Approach

EA Based Approach

                                                                                Source: Advances in ...
Enterprise Architecture: Describing Coherence

Key Questions Addressed by EA (1/2)
          Enterprise Level:                                       Business Level:
Key Questions Addressed by EA (2/2)
             Application Level:                                                 Inform...
Segmenting the EA Effort

      • Enterprise Architecture Concepts
         • Defining EA
         • Benefits of EA
         • Need for an Ar...
Greatest Myths about EA
       • We don’t have an architecture.
       • There are several EA tools available in the 
Imperatives to Establish & Sustain EA

       1. Realize that EA isn’t a fad.
       2. Position EA as a management practi...
Imperative 1: Realize that EA isn’t a Fad 
                                Why Enterprise Architecture isn’t a Fad?

Imperative 2: Position EA as a Management Practice
Imperative 3: Communicate the Reasons
                                                        Reasons to do EA
       •   ...
Imperative 4: Misplaced Priorities and Investments

Imperative 5: Set‐up EA PMO
                                               Key EA PMO Responsibilities

       •     Devel...
Imperative 6: Assess & Communicate GEA 
       • Connected government leads to impro...
In Conclusion,
                         Enterprise Architecture has:
                                           the most v...
Thank You

                        (2007)       ...
Upcoming SlideShare
Loading in …5

ICEGOV2009 - Tutorial 2 - part 1 - Architecting the Connected Government: Practices and Innovations in Singapore


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ICEGOV2009 - Tutorial 2 - part 1 - Architecting the Connected Government: Practices and Innovations in Singapore

  1. 1. MODULE 1/2 Architecting the Connected Government:  Practices and Innovations in Singapore  [Foundations of Enterprise Architecture]  United Nations International Conference on Theory and Practice of E‐Government ICEGOV 2009 November 10 – 13, 2009 Bogota, Colombia Dr. Pallab Saha National University of Singapore Institute of Systems Science © 2009  NUS Institute of Systems Science. The contents contained in this document may not be reproduced in any form or by any means, without the written permission of ISS, other than for the purpose for which it has been supplied.
  2. 2. Agenda Enterprise Architecture Concepts Defining EA Benefits of EA Need for an Architecture Driven Approach EA frameworks • Elements of Enterprise Architecture • Architecture Viewpoints • Business, Information, Solution & Technology Architectures • Architecture Governance Overview • Designing the EA • Imperatives for Adoption and Sustenance Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  3. 3. Describing Enterprise Architecture • An organization’s enterprise architecture  Business is the organizing logic for its core  The reason we do what we do, the people we  business processes and IT capabilities serve and the outcomes we seek.  captured in a set of principles, policies  and technical choices reflecting the  standardization and integration needs of  Information its operating model  How we treat our data, information, knowledge  (MIT Center for Information Systems Research  and wisdom. 2004) Application • A strategic information asset base, which  The software that supports the business mission. defines the mission, the information  necessary to perform the mission and  technologies needed to execute the  Technology mission, and the transitional processes for implementing new technologies in  The physical infrastructure that enables and/or  response to the changing mission needs  constricts our ability to take action.  (U.S. Federal Enterprise Architecture & E‐ Security Accessibility Privacy Other Government Act 2002) Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  4. 4. Common Themes in EA • Clear mission  • Customer value proposition   (strategy formulation) • Core business processes  (strategy execution) • Information needs  (key assets) • Technology needs  (IT enablement) • Strategic alignment (Biz‐IT alignment) Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  5. 5. Benefits of Architecture Driven Approach 1. Captures organizational mission and business processes in an understandable  manner to facilitate better planning and decision making 2. Improves communication and enriches engagement between business and IT  groups 3. Facilitates economies of scale by providing for sharing common services  across the enterprise 4. Enhances consistency, accuracy, and timeliness of IT‐managed information  shared collaboratively across the enterprise 5. Provides high‐level views to help communicate the complexity of large  systems 6. Highlights opportunities for building greater quality and flexibility into  applications without increasing costs 7. Supports analysis of alternatives, risks, and trade‐offs for the investment  management process, which reduces the risks of: • Building systems that do not meet business needs  • Expending resources on developing duplicative functionality Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  6. 6. Whom Does EA Concern? Business planners and managers contribute  IT planners and managers contribute to an EA  to EA and use it for key activities like: and use it for major activities: • Strategic planning  • Managing and prioritizing IT investments • Business process engineering and  • Determining the impact of changes to  redesign systems and infrastructure • Coordinating operations across the  • Modernizing legacy systems and  organization infrastructure • Consolidating or standardizing similar  • Protecting critical infrastructure functions • Assessing proposed technology solutions • Introducing automation to improve upon  • Dealing with declining vendor support and  manual processes skill base for IT components • Taking advantage of major new enabling  • Establishing key properties of systems early  technologies (e.g., wireless  in the design process when the cost of  communications, RFID) making changes or fixing problems is  • Reallocation of resources, including  smallest          reorganization Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  7. 7. Elements of Enterprise Architecture Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  8. 8. Architecture Description Conceptual Model Source: IEEE 1471‐2000, 2000 Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  9. 9. Architecture Blueprint • Formal description of an Architecture • Organized to support reasoning about the structural  properties of the system • Defines the components or building blocks that  make up the overall information system • Provides a plan from which products can be  procured, and systems developed, that will work  together to implement the overall system • Enables the management of overall IT investment in  a way that meets the needs of the business Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  10. 10. Architecture Frameworks Source: A Comparative Study of Enterprise Architecture Framework, Institute For Enterprise Architecture Development Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  11. 11. Without an EA … Source: Enterprise Architecture As Strategy, Weill, Ross & Robertson, 2006  Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  12. 12. Agenda • Enterprise Architecture Concepts • Defining EA • Benefits of EA • Need for an Architecture Driven Approach • EA frameworks Elements of Enterprise Architecture Architecture Viewpoints Business, Information, Solution & Technology  Architectures • Architecture Governance Overview • Designing the EA  • Imperatives for Adoption and Sustenance Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  13. 13. Business Architecture (1/2) • An enterprise business  Business architecture specifies the  The reason we do what we do, the people we  core business processes serve and the outcomes we seek.  that the enterprise must  Information deploy and practice in  How we treat our data, information, knowledge  and wisdom. order to satisfy its  customers, compete in  Application The software that supports the business mission. the market, partner with  suppliers, care for its  Technology employees and meet  The physical infrastructure that enables and/or  constricts our ability to take action.  regulatory requirements Security Accessibility Privacy Other Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  14. 14. Business Architecture (2/2) • Specifies core business processes which execute organization’s strategy • Identifies key goal and key performance indicators that drive performance • Forms the foundation for IT Architecture • (Usually) uses the following reference models: – Business Reference Model • An organized and structured construct of enterprise wide end‐to‐ end business processes – Performance Reference Model • A framework for performance management that provides common  measures throughout the enterprise Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  15. 15. Information Architecture (1/3) • Is a compilation of the business  Business The reason we do what we do, the people we  requirements of the enterprise,  serve and the outcomes we seek.  the information, process entities  and integration that drives the  Information business, and rules for selecting,  How we treat our data, information, knowledge  and wisdom. building and maintaining that  information Application The software that supports the business mission. • Information is data that can be  utilized, and can exist in both  Technology structured and unstructured  The physical infrastructure that enables and/or  form (65% of all organizational  constricts our ability to take action.  information do not reside in  Security Accessibility Privacy Other DBs!) Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  16. 16. Information Architecture (2/3) • Addresses issues like: – What information is needed – When the information is needed – Where the information is needed – In what form is the information needed – How is the information used – Who needs the information and how often Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  17. 17. Information Architecture (3/3) • Typically development of information architecture involves  creation of: – Conceptual model • This defines the information in the language of  business. It is the most abstract model and the main  intent is to define the functional / business view of  the data – Logical model • This depicts business information including business  relationships and business semantics adopted within  the enterprise. Logical models are developed  independent of technical / implementation details Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  18. 18. Application Architecture (1/2) • Facilitates development of  Business The reason we do what we do, the people we  ‘architectural solutions’ for the  serve and the outcomes we seek.  enterprise • An architectural solution follows  Information the development of the EA  How we treat our data, information, knowledge  and wisdom. blueprint • A solution architecture process  Application The software that supports the business mission. (SDLC) guides the organization in  specifying requirements and  Technology design for enabling the  The physical infrastructure that enables and/or  migration to the new EA constricts our ability to take action.  • Is linked to implementation  Security Accessibility Privacy Other planning for the EA blueprint Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  19. 19. Application Architecture (2/2) Comprises of solution set which usually is a mix of: • In‐house developed applications • Purchased applications • In‐house technical capabilities / services • Shared / utility technical capabilities / services • Integration capabilities Characterized by: • Specification of both functional and non‐functional (quality) requirements • Functional requirements are derived from Business Architecture (business  services) • Non‐functional (quality) requirements include: – Availability – Security – Modifiability – Testability – Performance – Usability  Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  20. 20. Technology Architecture (1/2) • Is a disciplined approach for  Business specifying the enterprise’s  The reason we do what we do, the people we  serve and the outcomes we seek.  current, emerging and retiring  technologies Information • The key goal is to leverage the  How we treat our data, information, knowledge  and wisdom. investments in technology  Application capabilities and maximize  The software that supports the business mission. their potential as solutions to  business problems Technology The physical infrastructure that enables and/or  constricts our ability to take action.  Security Accessibility Privacy Other Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  21. 21. Technology Architecture (2/2) • Examines the underlying technologies (technical  infrastructure) that is required to run the business (to  enable delivery of enterprise services as identified in  the Business Architecture) • Assumes technical capabilities as a set of services that business users (applications and systems) can  request for • Usually specified using a technical reference model Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  22. 22. Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  23. 23. Agenda • Enterprise Architecture Concepts • Defining EA • Benefits of EA • Need for an Architecture Driven Approach • EA frameworks • Elements of Enterprise Architecture • Architecture Viewpoints • Business, Information, Solution & Technology Architectures Architecture Governance Overview • Designing the EA • Imperatives for Adoption and Sustenance Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  24. 24. Architecture Governance • The practice and approach by which organizations manage  and control their architectures • Involves specifying the decision rights and accountability framework needed to encourage the desirable use of the  architecture  • Entails: – What architecture decisions are to be taken?  (governance decisions) – Who takes those decisions?  (governance structures) – How are those decisions taken,  (governance mechanisms) communicated, enforced and monitored  for compliance enterprise‐wide? Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  25. 25. What Does Architecture Governance Involve?  • Architecture governance encompasses: – Implementing system of controls over creation and monitoring of all  architectural components and activities, to ensure effective  introduction, implementation and evolution of the architecture – Implementing a system to ensure compliance with internal and  external standards and regulatory obligations – Developing practices that ensure accountability to a clearly identified  stakeholder community • Key architectural decision domains: – Architectural principles – Enabling implementation infrastructure – Business application needs – Investment management – Architectural compliance Transform – Architecture lifecycle Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  26. 26. Centralised Governance Mode Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  27. 27. Decentralised Governance Mode Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  28. 28. Federated Governance Mode Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  29. 29. Singapore Government Agency (1/3) Source: Singapore Government Enterprise Architecture, iDA, 2006 Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  30. 30. Singapore Government Agency (2/3) Committee/  Terms of Reference Group • Oversee & steer overall development & maintenance of the EA • Approve EA development strategy & deliverables such as architecture  EA Review  blueprints & models Committee • Approve EA policies, standards, procedures, & deviations to ensure  congruence & alignment • Resolve cross‐boundary architectural issues EA  • Develop EA components & building blocks Management  • Harmonise, communicate, maintain, coordinate, implement the EA Group • Manage the EA development, compliance & deviation processes Source: Singapore Government Enterprise Architecture, iDA, 2006 Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  31. 31. Singapore Government Agency (3/3) Committee/   Terms of Reference Group • Provide leadership, direction & supervision on data governance &  management matters Data Governance  • Approve data policies, standards & procedures, and deviations Board • Resolve cross‐boundary data issues & escalate to EA Review Committee  where necessary • Establish implementation of deliverables & schedule arising from defined  roadmap for data admin & mgt Data  • Formulate, maintain, communicate, & enforce data policies, standards &  Administration &  procedures Management  • Identify & recommend authorised users, sources & data owners of data  resources Committee • Propose resolution of cross‐boundary data issues for Data Governance  Board's approval Source: Singapore Government Enterprise Architecture, iDA, 2006 Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  32. 32. (Example) Organizational Structure Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  33. 33. Suggested Compliance  Outcomes Source: TOGAF Version 8.1, 2004, (The Open Group) Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  34. 34. Agenda • Enterprise Architecture Concepts • Defining EA • Benefits of EA • Need for an Architecture Driven Approach • EA frameworks • Elements of Enterprise Architecture • Architecture Viewpoints • Business, Information, Solution & Technology Architectures • Architecture Governance Overview Designing the EA  • Imperatives for Adoption and Sustenance Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  35. 35. EA Design Model Transform Source: Advances in Government Enterprise Architecture; Saha; 2008   Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  36. 36. Classical IT Planning Based Approach Source: Advances in Government Enterprise Architecture; Saha; 2008   Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  37. 37. EA Based Approach Source: Advances in Government Enterprise Architecture; Saha; 2008   Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  38. 38. Enterprise Architecture: Describing Coherence Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  39. 39. Key Questions Addressed by EA (1/2) Enterprise Level: Business Level: • Is my IT aligned to business? • Which business processes should receive our IT investments? • How much should we spend on IT? • Which business processes are used by most organization units? • What is our current IT spending  • Which business processes are distributed / fragmented most  profile? across multiple applications? • Who is accountable for all IT  • Which business processes have no applications supporting  programs? them? • How good should our IT services  • Which business processes use the highest number of  really be? technologies? • Which IT capabilities need to be  • Which business processes need to be managed and are  enterprise‐wide? candidates for redesign? • What is our criteria to retire  • Which business processes are used (or have touch‐points) by  technologies, applications and  most roles? information?  Organization Level: Technology Level: • Which organizational units are based  • Which technologies / technical services are used by most  at most locations (most dispersed)? applications? • Which organizational units are  • Which technologies are supported by multiple vendors? involved in most processes? • Which technologies are used by most business processes? • Which organizational units use most  • Which technologies are used enterprise‐wide versus those used  applications / technologies  by specific organizational units? (technical & application diversity)?  • Have we categorized our technologies into emerging, current  and sunset? Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  40. 40. Key Questions Addressed by EA (2/2) Application Level: Information / Data Level: • Which applications have multiple technologies for  • What are our key information  enablement and how many? requirements and how do we derive  • What is the intensity of usage of different applications? them? • Which applications are enterprise‐wide versus those that  • How many applications share a  are specific to organizational units? common database? • Which applications support the maximum number of  • How many business rules are explicitly  business processes? documented? • Which applications have no vendor support? • Can we trace back our business rules to  • Which applications need integration capabilities, within  organization policies? and outside the boundaries of the organization? • Which business rules govern our  • Do we have relevant scenarios for quality attributes (e.g.  business processes? security, performance and scalability, availability and  • Which business rules are used by our  resilience, evolution)? applications? Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  41. 41. Segmenting the EA Effort Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  42. 42. Agenda • Enterprise Architecture Concepts • Defining EA • Benefits of EA • Need for an Architecture Driven Approach • EA frameworks • Elements of Enterprise Architecture • Architecture Viewpoints • Business, Information, Solution & Technology Architectures • Architecture Governance Overview  • Designing the EA Imperatives for Adoption and Sustenance Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  43. 43. Greatest Myths about EA • We don’t have an architecture. • There are several EA tools available in the  market. • The architects do all the ‘architecting’. • It is a project. • All architects must be excellent analysts. • The primary purpose of EA is business‐IT  alignment for building better systems. Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  44. 44. Imperatives to Establish & Sustain EA 1. Realize that EA isn’t a fad. 2. Position EA as a management practice 3. Clearly understand and communicate the reasons  to do EA 4. Avoid misplaced priorities and investments 5. Set up an EA programme management office 6. Assess and communicate enterprise architecture  effectiveness Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  45. 45. Imperative 1: Realize that EA isn’t a Fad  Why Enterprise Architecture isn’t a Fad? • Architecture is the very essence of good design (good  enterprise) • Most architecture artifacts already exist – The important thing is to get them to be formal, consistent,  structured and connected • Architects build the rules, policies, semantics models,  structuring mechanisms and align them • Architecture is important for ‘what you do with it’, rather  than ‘what it is’ • Architects’ role is to ensure coherency – Designed, Organized, Consistent, Connected and Institutionalized Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  46. 46. Imperative 2: Position EA as a Management Practice EA provides a mechanism to  instill discipline and control  (governance) to business  processes and their enabling  IT infrastructures  Enterprise Line of  Business Transform Segment Lead Source: Advances in Government Enterprise Architecture; Saha; 2008   Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  47. 47. Imperative 3: Communicate the Reasons Reasons to do EA • An enterprise should be ‘doing EA’ if it suspects its: – External stakeholders are: • Not happy with the enterprise’s performance • Not receiving what they expect from the enterprise – Business processes are: • Unnecessarily complex • Under leverage enterprise’s IT investments • Poorly define roles and responsibilities • Break down at integration points – Employees and customers have difficulty finding the information they need and  when found they are often incomplete, fragmented, and out of date – IT infrastructure is not sufficient to scale up – Project portfolio is not aligned with enterprise strategic intent and is not actively  monitored and evaluated – Expenditure on IT is always seen as ‘costs’ and seldom as ‘investments’, and IT  always works to a budget and not to value  Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  48. 48. Imperative 4: Misplaced Priorities and Investments Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  49. 49. Imperative 5: Set‐up EA PMO Key EA PMO Responsibilities • Developing and administering the EA • Enforcement of EA governance • Developing the overall EA roadmap and adoption plan • Managing the EA review committees  • Assessing technology trends and studying their impact on the EA • Communicating and promoting the EA • Identifying ‘gaps’ between business and IT architectures • Assisting with budget and IT investment management activities • Participating as architecture advisors in projects • Ensuring architectural compliance • Providing updates in architectural best practices and advancements  Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  50. 50. Imperative 6: Assess & Communicate GEA  Effectiveness  • Connected government leads to improved  coordination of processes and systems within and  across government agencies and organizations Source: UN E‐Government Survey 2008; United Nations; 2008   Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  51. 51. In Conclusion, Enterprise Architecture has: the most value when it ensures business is well architected. great value when it ensures business has a good view of business. good value when it ensures IT has a good view of the business. EA is not done to build better systems, but to build better enterprises Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.
  52. 52. Thank You (2007) (2008) (2009) Transform Lead Inspire © Copyright 2009  E‐Government Leadership Centre @ NUS.  All rights reserved.