Enterprise Architecture In the Current e-Government Context in Sri Lanka By Ctishantha Nanayakkara Head of Technology, ICTA
Enterprise architecture in the current e-Government context in Sri Lanka
Aug 18, 2015
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Enterprise ArchitectureIn the Current eGovernment Context
in Sri Lanka
By Ctishantha NanayakkaraHead of Technology, ICTA
2
Do we really have an Government Do we really have an Government Enterprise Architecture (GEA) strategy in Enterprise Architecture (GEA) strategy in
Sri Lanka?Sri Lanka?
3
If YES, what is the strategy so far?If YES, what is the strategy so far?
4
Enterprise Architecture
5
Enterprise Architecture
Enterprise architecture is a complete expression of the enterprise
An enterprise architecture is a description of the goals of an organization, how these goals are realized by business processes, and how these business processes can be better served through technology.
6
Definitions
“Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate.” The Open Group
“Enterprise Architecture is a strategic information asset base, which defines the business mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transitional processes for implementing new technologies in response to the changing mission needs.” USA Federal CIO Council
“A means for describing business structures and processes that connect business structures.” CMU
7
Enterprise Architecture Frameworks
In a large enterprise, a rigorously defined framework is necessary to capture a vision of the entire organization in all its dimensions and complexities
An enterprise architecture program is supported by such frameworks
8
Enterprise Architecture FrameworksAn EA Framework is a communication model for developing an
Enterprise Architecture (not an architecture per se.)– It is a set of models, principles, services, approaches,
standards, design concepts, components, visualizations and configurations that guide the development of specific aspect architectures
An EAF is a generic problem space and a common vocabulary within which individuals can cooperate to solve a specific problem
9
Enterprise Architecture Frameworks
Other 6%
CIMOSA (Computer Integrated Manufacturing
Open Systems Architecture) framework
6%
Organization own 32%
C4ISR, US Defense Architecture Framework
6%
TOGAF, the Open Group Architecture Framework
9%
FEAF, US Federal Enterprise Architecture
Framework 6%
Zachman Framework 18%
IAF, Cap Gemini Ernst & Young's - Integrated
Architecture Framework 7%
ISO/IEC 14252 (IEEE Std 1003.0) Guide to the
POSIX Open System Environment
3%
TEAF, US Treasury Enterprise Architecture
Framework. 4%
PERA (Purdue Enterprise Reference
Architecture) Framework 3%
Source: EA Survey 2003, IFEAD
10
11
Enterprise Architecture Frameworks
90% of the field uses one of the following four methodologies:– The Zachman Framework for Enterprise Architectures,
which, although selfdescribed as a framework is actually more accurately defined as a taxonomy
– The Open Group Architectural Framework (TOGAF), which, although called a framework is actually more accurately defined as a process
– The Federal Enterprise Architecture, which can be viewed either as an implemented enterprise architecture or as a prescriptive methodology for creating an enterprise architecture
– The Gartner Methodology, which can be best described as an enterprise architectural practice
12
Most EA Frameworks have different evolutions
Most EA Frameworks serve different purposes
Most EA Frameworks are different in scope
Most EA Frameworks are based on different principles
Most EA Frameworks have different structures
Most EA Frameworks are supported by different approaches
Source: http://www.finance.gov.au/policy-guides-procurement/australian-government-architecture-aga/
Australia
Source: https://www.ict.govt.nz/guidance-and-resources/architecture/enterprise-architecture/
NewZealand
India
16
Do we really have an Government Do we really have an Government Enterprise Architecture (GEA) strategy in Enterprise Architecture (GEA) strategy in
Sri Lanka?Sri Lanka?
Yes
17
If YES, what is the strategy so far?If YES, what is the strategy so far?
The SOA based infrastructure
18
19
EA using SOA
20
TOGAF is a generic EA framework, it provides enterprises with a 4 dimensional model.
Business Architecture Information Architecture Application Architecture Technology Architecture
TOGAF allows to design, evaluate and build the right architecture for any organization ensuring BusinessIT alignment at the enterprise level
EA using SOA
21
TOGAF ArchitectureDevelopmentMethod (ADM)
Phase 0 – PreliminaryPhase A – Architecture VisionPhase B – Business ArchitecturePhase C – Information Systems ArchitecturePhase D – Technology ArchitecturePhase E – Opportunities and SolutionsPhase F – Migration PlanningPhase G – Implementation GovernancePhase H – Architecture Change Management
22
TOGAF ADM Phases
Phase 0 – Preliminary Phase This is where the architecture footprint is defined This is the starting point of adopting a proper EA
framework (i.e. TOGAF) and SOA architecture principles
23
TOGAF ADM Phases
Phase A – Architecture Vision This is where the architecture scope is defined. A High Level description of the final architecture is
produced
24
TOGAF ADM Phases
Phase B – Business Architecture This aligns enterprise's business processes, people,
operations and projects with the overall strategy This builds the foundation for the “Information
Systems Architecture” and the “Technology Architecture”
25
TOGAF ADM Phases
Phase B – Business Architecture This stage will result the following
• Business Process Model• Business Roles Catalog• Business Vocabulary• Business Rules Catalog• Business Services Catalog
26
TOGAF ADM Phases
Phase C – Information Systems Architecture This defines the types and sources of data that are
necessary to support the business and the applications necessary to process data
This “Data Architecture” will produce• Business Data Models• Logical Data Models• Data Architecture Building Blocks
27
TOGAF ADM Phases
Phase C – Information Systems Architecture The “Application Architecture” includes
• Service Interaction Model – To show service interaction along with the use of data
• Business Process/Service Matrix shows which service caters to which business process
• Service Consumer Matrix – shows which human or external system consume which service
• Service Contract and Policy Catalog – Service contracts and related policies
• Service Access Control Model – How service level access control is defined
28
TOGAF ADM Phases
Phase D – Technology Architecture This phase maps the application components
defined in the Application Architecture into set of software and hardware technology components
• Service based integration – ESB• Service Compositions – BPS (using BPEL)• Service Monitoring – BAM• Service Governance – Registry• Service level Data Security – WSSecurity, OAuth2
29
TOGAF ADM Phases
Phase E – Opportunities and Solutions– This looks at the implementation options identified
in the target architecture – Build vs Buy vs ReUse– Existing services and solution portfolios in the
enterprise are viewed before making a decision on whether to develop the services inhouse, or use the services provider by external companies, or acquire software products that perform the services.
30
TOGAF ADM Phases
Phase F – Migration Planning– This phase is about planning the implementation to
the target architecture using the solutions that we have chosen in Phase E
31
TOGAF ADM Phases
Phase G – Implementation Governance– SOA Governance is viewed as the application of
corporate governance, information technology (IT) governance, and enterprise architecture (EA) governance to SOA.
– SOA Governance extends IT and EA governance, ensuring that the benefits of SOA are realized. This means governing, not only the execution aspects of SOA, but also the strategic planning activities.
32
TOGAF ADM Phases
Phase H – Architecture Change Management– The Architecture Change Management phase
establishes procedures for managing changes to the target architecture.
33
EA vs SOA (Using TOGAF)
34
Developing a complete enterprise architectural model of every element in an organization is a complex and daunting task
Such an EA effort may divert focus away from alignment & validation and may prevent important crossbusiness area collaboration processes which are critical to the overall successful definition & implementation of the EA
The level of enterprise architectural detail within the EA should be governed by the overall objectives of achieving collaboration, alignment, validation and the ability to implement & assess risk
The EA Approach
35
The better path to EA
When enterprise architectures work well, they are a great asset in finding effective ways to better use technology
When they don’t work well, they can be a huge counterproductive drain on organizational resources. Often, it is this case which is realized!
The failure to manage complexity is the key reason so many attempts at creating enterprise architecture fail
Few existing methodologies for enterprise architectures address the management of complexity in any meaningful way. And the architectures of today’s organizations are highly complex.
36
Managing Complexity of EA
Partitioning complexity is one of the keys to reducing complexity
The best way to analyze partitions of complexity is to iterate through them, and to do that iteration with a focus on speed rather than completeness
37
Partitioning
38
The Traditional Approach
39
The PartitionedIterative Approach
40
The PartitionedIterative Approach
Start with partitions that have a high perceived value in your organization
Start with projects that have high visibility across the organization. This will improve your changes of getting buyin from others on future projects
Start with projects that have a low cost. You want to establish a track record of Time to Value
Start with projects with low risk to establish credibility. You can afford to take chances in later iterations.
Start with projects that can be completed as quickly as possible. Your goal is to establish a track record of delivering value quickly.
41
But have we achieved what we But have we achieved what we wanted?wanted?
No, we need a improve our strategy
42
43
Interoperability
44
Why?So many distributed & diverse systems,
May have used:• Various technologies • Various data architectures • Conflicting policies, procedures, guidelines
45
Interoperability is the ability of disparate and diverse organizations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organizations via the business processes they support, by means of the exchange of data between their respective information and communication technology (ICT) systems. [European Communities 2008, p. 5]
Reference: European Communities. Draft Document as Basis for EIF 2.0. Official Publications of the European Communities, 2008.
What?
46
Achieving interoperability requires addressing a wide range of technical and nontechnical issues that are influenced by a number of factors.
47
Addressing interoperability challenges will improve efficiency of service delivery, access to the services, coordination among existing services
Can avoid potential future costs such as inflexibility due to
vendor lockin and the high price of new development by leveraging existing systems in new ways
Enhances transparency and accountability, resulting in better overall governance
Benefits
48
Interoperability Levels
49
Interoperability Levels Technical Interoperability
Maps to the goal of data interoperability including harmonization for standards for transport, messaging, discovery, security
Semantic Interoperability Maps to the goal of meaning exchange, Using ontologies,
etc Organizational/ Business Process Interoperability
Maps to the goal of process agreement. Using BPEL, AWL, etc
• e.g. The Austrailian Government Business Process Interoperability Framework
50
Interoperability Influencing Factors
51
Open Standards
Open standards play a key role in achieving interoperability
Helps to define component interfaces, which leads to simpler, repeatable and quicker efforts of integration
Features:Easy accessibility for all to read and useDeveloped by a process that is open and relatively easy for anyone to participate inNo control or tiein by any specific group or vendor
Avoids “Vendor lockin”, that creates many horizons by minimizing risks and lowered cost
52
Private Sector Companies
Services
ApplicationServices
Application
The Department of Motor Traffic
Vehicle Domain
Services
Application
The Department Registration of Persons
Personal Domain
Services
Application
The Land Ministry
Land Domain
53
DMTDMT
Translationin the
Middleware
Translationin the
Middleware
WPDMTWPDMT
Owner First NameOwner Last NameOwner Address Line1Owner Address Line2Owner CityVehicle Reg NoFuel TypeWeightNumber of Seats
Owner First NameOwner Last NameOwner Address Line1Owner Address Line2Owner CityVehicle Reg NoFuel TypeWeightNumber of Seats
Owner Full NameOwner AddressVehicle Reg NoFuel TypeWeightNumber of Seats
Owner Full NameOwner AddressVehicle Reg NoFuel TypeWeightNumber of Seats
54
Interoperability Frameworks
55
Lanka Interoperability Framework (LIFe)
http://life.gov.lk
Integrated Information Infrastructure Reference Model (IIIRM)
Source: TOGAF 9.1 III-RM
57
[Jaap06] “How to Survive in the Jungle of Enterprise Architecture Frameworks”, Jaap Schekkerman, published by Trafford; 3rd edition, 2006.
[EAIns1] “Enterprise Architecture Assessment Guide”, by the Institute for Enterprise Architecture Developments, Editor, J. Schekkerman, Version 2.2, 2006.
[Sess07] “Comparison of the Top Four Enterprise Architecture Methodologies” by Roger Sessions, CTO of ObjectWatch Inc., 2007.
[Sess06] “A Better Path to Enterprise Architectures”, by Roger Sessions, prepared for Microsoft Corporation, March 21, 2006.
[NASCIO] “NASCIO Enterprise Architecture Maturity Model”, by the National Association of State Chief Information Officers (NASCIO), Version 1.3, December 2003.
References
58
Interoperability in the eGovernment Context, Marc Novakouski, Grace A. Lewis, Software Engineering Institute, Carnegie Mellon University, http://sei.cmu.edu, Jan 2012
The Australian Government Business Process Interoperability Framework, Enabling Seamless Service Delivery, July 2007
References
Related Documents
![Abeyesekere The Protection of folklore in Sri Lanka[2] · Indunil Abeyesekere* ... In the context of Sri Lanka the indigenous communities ... specifically those of the common law](https://static.cupdf.com/doc/110x72/5b80e80e7f8b9af0088e59bc/abeyesekere-the-protection-of-folklore-in-sri-lanka2-indunil-abeyesekere.jpg)
