04/08/23 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

04/08/23 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!

04/08/23 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.

04/08/23 4

Enterprise Architecture

• Why do I need it?– In Steven Covey’s 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.

04/08/23 5

Enterprise Architecture

• What does it consist of…here 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.

04/08/23 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.

04/08/23 7

Principles &

Standards - Industry & Practices

General & Vendor Specific Implem.

Guidelines

Policies & Legislation

Supporting Purchasing Contracts

Workgroups &

CommitteesWhite

Papers

Glossary

Presentations

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

04/08/23 8

Enterprise Architecture

• I need more…what 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.

04/08/23 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.

04/08/23 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).

04/08/23 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

04/08/23 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?

04/08/23 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.

04/08/23 14

• SDLC continued: – Application Development Methodologies

• Waterfall• Iterative Waterfall• RAD - Rapid Application Development• Extreme Programming• SODA - Service-Oriented Development of Applications

– SOA – Service Oriented Architecture

Application Methodology

04/08/23 15

• 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.

Application Methodology

04/08/23 16

• 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.

Application Methodology

04/08/23 17

• 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”.

Application Methodology

04/08/23 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.

04/08/23 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.

04/08/23 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)

04/08/23 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

04/08/23 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….

04/08/23 23

Application Methodology

• Types of Testing– Unit– System– Regression– Interface– User Acceptance– Stress

• Testing Tools/Software

04/08/23 24

Application Methodology• Deployment Alternative

– Pilot Project• Production class with out massive scale.• Deployed to select portion of the business.• Not an Alpha/Beta.

04/08/23 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.

04/08/23 26

References

• Gartner Group– SODA Environments Support the Application Platform Suite (SPA-18-5159).– Some Vendors Will Survive SODA, and Others Won’t (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

04/08/23 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.

04/08/23 28

Questions

– Stan Jenkins– Senior Enterprise Architect– Office of Information Technology Services– Enterprise Technology Strategies– State of North Carolina

Stan.jenkins@ncmail.net