More Related Content
Similar to ICEGOV2009 - Tutorial 2 - part 1 - Architecting the Connected Government: Practices and Innovations in Singapore
Similar to ICEGOV2009 - Tutorial 2 - part 1 - Architecting the Connected Government: Practices and Innovations in Singapore (20)
ICEGOV2009 - Tutorial 2 - part 1 - Architecting the Connected Government: Practices and Innovations in Singapore
- 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. 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. 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. 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. 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. 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.
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Transform
Lead
Inspire
© Copyright 2009 E‐Government Leadership Centre @ NUS. All rights reserved.
- 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. 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. 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.
- 28. Federated Governance Mode
Transform
Lead
Inspire
© Copyright 2009 E‐Government Leadership Centre @ NUS. All rights reserved.
- 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. 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. 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.
- 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. 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. 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. 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. EA Based Approach
Source: Advances in Government Enterprise Architecture; Saha; 2008
Transform
Lead
Inspire
© Copyright 2009 E‐Government Leadership Centre @ NUS. All rights reserved.
- 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. 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. Segmenting the EA Effort
Transform
Lead
Inspire
© Copyright 2009 E‐Government Leadership Centre @ NUS. All rights reserved.
- 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. 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. 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. 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. 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. 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.
- 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. 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. 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. Thank You
pallab@nus.edu.sg
(2007) (2008) (2009)
Transform
Lead
Inspire
© Copyright 2009 E‐Government Leadership Centre @ NUS. All rights reserved.