2003 North Carolina Conference - Geographic Information Systems - PowerPoint PPT Presentation

1 / 28
About This Presentation
Title:

2003 North Carolina Conference - Geographic Information Systems

Description:

2003 North Carolina Conference - Geographic Information Systems Enterprise Architecture and Application Development Best Practices Stan Jenkins – PowerPoint PPT presentation

Number of Views:137
Avg rating:3.0/5.0
Slides: 29
Provided by: Katheri138
Category:

less

Transcript and Presenter's Notes

Title: 2003 North Carolina Conference - Geographic Information Systems


1
2003 North Carolina Conference - Geographic
Information Systems
  • Enterprise Architecture and Application
    Development Best Practices
  • Stan Jenkins
  • Senior Enterprise Architect
  • State of North Carolina
  • February 21, 2003

2
Objectives
  • Introduce the basic concepts of Enterprise
    Architecture and Application Development
    Methodologies.
  • Quantify why it is critical that these
    disciplines be applied to the world of GIS.
  • Provide insights based on results of previous
    implementations.
  • Provide links to additional resources including
    Lessons Learned.
  • All in 25 minutes or less So lets get started!

3
Enterprise Architecture
  • What is it?
  • A framework that guides Organizations (both
    public and private) in the design,
    implementation, and support of Enterprise Class
    applications which can be used to accomplish the
    specified business objectives/requirements.
  • What it is Not!
  • A network diagram.
  • A Buy List of software and hardware
    technologies.

4
Enterprise Architecture
  • Why do I need it?
  • In Steven Coveys book, Seven Habits of Highly
    Effective People, one of the core principles is
    Begin with the end in mind, that is what EA
    does.
  • An Enterprise Architecture establishes
    fundamental Principles, Standards, Best
    Practices, and Implementation Guidelines that
    guide in the proper design and delivery IT
    projects.
  • By following proven techniques, not only is
    initial project success more likely, must so is
    the long term viability of the project.

5
Enterprise Architecture
  • What does it consist ofhere are a few key
    elements
  • Core Principles
  • Examples include Business Driven, Economies of
    Scale, Infrastructure Leveraging, Data Value,
    Openness, Scalability, Availability, Redundancy,
    Adaptability, Securability, Reusability,
    Consistency, Interoperability, Portability,
    Accessibility, etc.
  • Standards
  • Generally based on Industry or Defacto standards
    such as IEEE, W3C, ANSI, OASIS, Open GIS, etc.
  • Best Practices
  • Generally based on proven IT related practices
    that have been performed in successfully IT
    endeavors.
  • Implementation Guidelines
  • Generally product or technology specific.

6
Enterprise Architecture
  • Here are some examples.
  • Principles
  • Primary design point is to facilitate change.
  • Business processes drive technical solutions.
  • Data is a key corporate asset that must be
    protected.
  • Standards
  • TCP/IP
  • Ethernet
  • ANSI SQL
  • Best Practices
  • 3/N Tier or Service Oriented Architectures.
  • Avoid use of extensions that create vendor
    lock-in.
  • Implementation Guideline
  • Referential Integrity must be system managed.

7
  • EA is comprised of a collection of informational
    items/elements. Collectively, these elements are
    used to guide IT decisions.

8
Enterprise Architecture
  • I need morewhat are we really talking about
    here
  • GIS has become essential to the IT of today.
  • It is used both operationally and analytically to
    solve address critical business issues. Everyone
    agrees that the data provides high value.
  • Therefore
  • Enterprise grade principles and approaches must
    be followed, regardless of Organization size or
    limited success and/or failure is almost certain.
  • An Enterprise Architecture should be designed to
    fit the environment. However, some amount of
    resources will be needed to create and keep the
    architecture current. In addition,
    governance/management will be needed to ensure
    that compliance occurs.

9
Enterprise Architecture
  • I hear what you are saying but I am not sold.
  • Well, here are a few example of things that you
    might want to consider.
  • What happens if the business requirements change,
    can you adapt, and if so how fast?
  • What happens if the primary software vendor of
    choice goes out of business, what happens if the
    company direction changes or is bought out, what
    happens if the pricing structure for the software
    becomes to expensive?
  • What if your systems are maliciously hacked, can
    you recover, how long will it take, what data was
    stolen, what are the ramifications of the
    incident, should law enforcement be contacted,
    etc?
  • These are just three examples of why the
    Enterprise Architecture discipline is essential.

10
Application Methodology
  • Why follow one?
  • Wild Wild West days are over.
  • Must think Enterprise Class, even if budgets are
    limited.
  • Perspective should be I will not always be here,
    I should leave a good legacy.
  • Forward focused how can I do more with less.
  • Align with predefined Application or
    Service-based Architectures.
  • Build using Industry Guidance (e.g. IEEE based).

11
Application Methodology
  • System Development Life Cycle (SDLC) includes 
  • Process Management
  • CMM
  • TQM
  • Six Sigma
  • Project Management
  • Staffed, Formalized, and Tool Based
  • Metrics Management
  • Primary
  • Secondary

12
Application Methodology
  • Project Management
  • Primary Metrics
  • Quality
  • Did the user get what they wanted?
  • How well does deliverables map to Functional
    Requirements?
  • How many defects are in the code?
  • Schedule
  • Did the project come in on time?
  • What parts of the project slipped?
  • Budget
  • Over or Under?

13
Application Methodology
  • Project Management
  • Secondary Metrics
  • Change
  • 5 or more must be approved.
  • Scope Creep can cause a project to fail.
  • Training, Training, Training, Training,
  • Good training plans are essential.
  • Developers may need new skills.
  • Users will need to be trained on the new system.
  • Resource
  • Needs rise and fall over the life of the project.
  • Staff comes and goes - must be able to adapt
    (contingency plans?)
  • Issue/Risk Mitigation
  • Must be tracked and resolved.
  • Staff assigned, description, status, etc.

14
Application Methodology
  • SDLC continued 
  • Application Development Methodologies
  • Waterfall
  • Iterative Waterfall
  • RAD - Rapid Application Development
  • Extreme Programming
  • SODA - Service-Oriented Development of
    Applications
  • SOA Service Oriented Architecture

15
Application Methodology
  • Waterfall - Characteristics
  • Monolithic.
  • Rigidly requirement focused and change limited.
  • Highly structured and documentation oriented
    process.
  • Delays often occurred due to poorly understood or
    changing requirements.
  • Tightly coupled design and coding techniques did
    not accommodate change.
  • Massive changes are often required late in the
    project which caused slippage or even failure to
    occur.
  • Goes against the need for change and flexibility.

16
Application Methodology
  • Iterative Waterfall - Characteristics
  • Breaks large deliverables into smaller
    accomplishable units while still focusing on
    accomplishing overall business requirements.
  • Collaborative in nature.
  • Frequent releases due to fine grained components
    accommodate change and provide early customer
    satisfaction.
  • Easily can build on base implementation.
  • Strong continual feedback loops improve quality.
  • Avoids running into large changes that can not be
    performed in timely manner.
  • Iterations must remain release focused and must
    not become ad-hoc in nature.

17
Application Methodology
  • RAD - Characteristics
  • Rapid Application Development.
  • Similar to Iterative Waterfall in concept.
  • Tools and Technology based.
  • 4GLs
  • Code Generators
  • Code reuse is essential
  • Implementation times are usually very short.
  • Use cautiously for enterprise class systems.
    Proven formalized processes must exist and be
    followed.
  • Have to avoid the issue of generating bad code
    faster or coding yourself in corner.

18
Application Methodology
  • Extreme Programming - Characteristics
  • Leading edge.
  • Informal and narrowly scoped.
  • Viable for Tier 1/Class A organizations only.
  • Highly collaborative based.
  • Shifts focus from defined starting and stopping
    points to continued development.

19
Application Methodology
  • SODA - Characteristics
  • Service Oriented Development of Applications.
  • Fundamental shift from classic Application
    Development to Providing Software Services.
  • Deliver high quality highly reusable software.
  • Leverage Service Oriented Architectures (SOA).
  • Service reuse is a cornerstone philosophy.
  • Encourages purchase of Web Services from 3rd
    Party Vendors.
  • Establishes a discipline of code only when
    necessary.
  • Technology Model (e.g. .NET or J2EE) agonistic.
  • Introduces new roles such as Designers/Modelers,
    Assembly Editors, Orchestration Editors, Rules
    Editors, Business Analysts, Software Quality
    Experts.

20
Technology Terminology
  • Web Services
  • XML, WSDL, UDDI, SOAP
  • Service Oriented Architecture (SOA)
  • Many flavors available. Market is still
    stabilizing.
  • Service Oriented Development of Applications
    (SODA)
  • Methodology for development of WS application
    using SOA.
  • Integrated SODA Environment (ISE)
  • SunOne/Forte, Borland JBuilder, VB.NET, ArcGIS
  • Frameworks/Languages
  • J2EE Java, Java Beans, EJBs, JSP
  • .NET VB, ASP, VB.NET, ASP.NET
  • Business Process Modeling
  • UML (Unified Modeling Language)
  • RUP (Rational Unified Process)

21
Application Methodology
  • Major Phases of Application Development
  • Project Planning
  • Business Functional Requirements
  • High Level Design
  • Detail Level Design
  • Construct/Build (Code)
  • Testing
  • Implementation
  • Post Implementation Support

22
Application Methodology
  • Construct/Build
  • Fine grained/Loosely coupled components.
  • Component builds (ROT 40 hours or less).
  • Weekly (not weakly) peer review of code.
  • Strongly commented code.
  • Teams based on functions and skill sets.
  • User interfaces
  • Business Logic
  • Data access
  • Testers
  • Trainers
  • The list goes on.

23
Application Methodology
  • Types of Testing
  • Unit
  • System
  • Regression
  • Interface
  • User Acceptance
  • Stress
  • Testing Tools/Software

24
Application Methodology
  • Deployment Alternative
  • Pilot Project
  • Production class with out massive scale.
  • Deployed to select portion of the business.
  • Not an Alpha/Beta.

25
Resources
  • NC Statewide Technical Architecture
  • http//irm.state.nc.us/techarch
  • Information Resource Management Commission
  • http//irmc.state.nc.us/
  • Policy and Standards
  • Implementation Framework for Statewide
    Information Technology Projects.
  • Lessons Learned From IT Projects.

26
References
  • Gartner Group
  • SODA Environments Support the Application
    Platform Suite (SPA-18-5159).
  • Some Vendors Will Survive SODA, and Others Wont
    (SPA-18-7422).
  • Producer Platforms and SODA Will Shift the AD
    Approach (T-16-5731).
  • AD Cultural Revolution Services-Oriented
    Development (COM-18-9221).
  • Service-Oriented Architectures Foster Real-Time
    Capability (COM-18-9401).
  • Predicts 2003 SOA to Stir up Application Server
    Market (SPA-18-8377).
  • Predicts 2003 SOA Comes of Age via Web Services
    (SPA-18-8378).
  • Implementing Web Services Development Roles
    (TU-16-2389).
  • ARAD Brings Architectural Compliance and
    Developer Productivity (COM-18-9804).
  • Architected RAD Tools Are Delivering Major
    Benefits (T-19-0792).
  • The Cost and Risk of Application Development
    Decisions (R-16-1411).
  • Application Development Skills and Technology
    Trends (R-18-0318).
  • Number SPA-18-515

27
References (continued)
  • META Group
  • META Delta Application Delivery Strategies
    Delivering Iteratively (File 939).
  • META Delta Service-Oriented Architectures Part
    1 Defining Reusable Enterprise Services (File
    ADS 1244).
  • META Delta Service-Oriented Architectures Part
    2 Governance for Enterprise Services (File ADS
    1245).
  • META Delta Service-Oriented Architectures Part
    3 The Case for Services (File ADS 1246).
  • META Client Advisor A Model Approach to
    Business Process Modeling A Primer.

28
Questions
  • Stan Jenkins
  • Senior Enterprise Architect
  • Office of Information Technology Services
  • Enterprise Technology Strategies
  • State of North Carolina
  • Stan.jenkins_at_ncmail.net
Write a Comment
User Comments (0)
About PowerShow.com