Enterprise Architecture and Application Development Best ...


Published on

1 Like
  • Be the first to comment

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

No notes for slide
  • The STA currently has 14 domains, which will be consolidated into 9 domains (e.g. Application, Network, and Data Domains)
  • Talk about convergence of traditional OLTP and OLAP with GIS and the need to focus on the Enterprise Business needs of the future not just today.
  • In the early days of EA, simple examples were give about why you put 2X4’s on sixteen inch centers. Answer being because plywood is 4ft wide and after you leave, people coming in behind you, can count on certain things to be true. Another example is consistency is why utility workers can come from across the nation to assist in the event of large scale power outages, because things were done consistently. But the fact of the matter is things are very much more complex than this, each application is like a automobile. It is very complicated and intricate. Proper design as well as process are critical to production of quality products. So while each application may be a little “different” what part of them can be done the same “repeatable”. Because the question becomes…”how quickly can I get the next major model year out”. It use to be 4 years now I would estimates it at 6 to 12 months. That is what we have to do in IT. 8 millions credit cards stolen. EA is all about focusing on the needs of the business, don’t build a skyscraper that can’t be easily changed.
  • Iterative Waterfall is still very effective Floodplain Mapping Information System is a good example. SODA may be the way of the future
  • Enterprise Architecture and Application Development Best ...

    1. 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. 2. Objectives <ul><li>Introduce the basic concepts of Enterprise Architecture and Application Development Methodologies. </li></ul><ul><li>Quantify why it is critical that these disciplines be applied to the world of GIS. </li></ul><ul><li>Provide insights based on results of previous implementations. </li></ul><ul><li>Provide links to additional resources including Lessons Learned. </li></ul><ul><li>All in 25 minutes or less… So lets get started! </li></ul>
    3. 3. Enterprise Architecture <ul><li>What is it? </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>What it is … Not! </li></ul><ul><ul><li>A network diagram. </li></ul></ul><ul><ul><li>A “Buy List “ of software and hardware technologies. </li></ul></ul>
    4. 4. Enterprise Architecture <ul><li>Why do I need it? </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>An Enterprise Architecture establishes fundamental Principles, Standards, Best Practices, and Implementation Guidelines that guide in the proper design and delivery IT projects. </li></ul></ul><ul><ul><li>By following proven techniques, not only is initial project success more likely, must so is the long term viability of the project. </li></ul></ul>
    5. 5. Enterprise Architecture <ul><li>What does it consist of…here are a few key elements </li></ul><ul><ul><li>Core Principles </li></ul></ul><ul><ul><ul><li>Examples include Business Driven, Economies of Scale, Infrastructure Leveraging, Data Value, Openness, Scalability, Availability, Redundancy, Adaptability, Securability, Reusability, Consistency, Interoperability, Portability, Accessibility, etc. </li></ul></ul></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><ul><li>Generally based on Industry or Defacto standards such as IEEE, W3C, ANSI, OASIS, Open GIS, etc. </li></ul></ul></ul><ul><ul><li>Best Practices </li></ul></ul><ul><ul><ul><li>Generally based on proven IT related practices that have been performed in successfully IT endeavors. </li></ul></ul></ul><ul><ul><li>Implementation Guidelines </li></ul></ul><ul><ul><ul><li>Generally product or technology specific. </li></ul></ul></ul>
    6. 6. Enterprise Architecture <ul><li>Here are some examples…. </li></ul><ul><ul><li>Principles </li></ul></ul><ul><ul><ul><li>Primary design point is to facilitate change. </li></ul></ul></ul><ul><ul><ul><li>Business processes drive technical solutions. </li></ul></ul></ul><ul><ul><ul><li>Data is a key corporate asset that must be protected. </li></ul></ul></ul><ul><ul><li>Standards </li></ul></ul><ul><ul><ul><li>TCP/IP </li></ul></ul></ul><ul><ul><ul><li>Ethernet </li></ul></ul></ul><ul><ul><ul><li>ANSI SQL </li></ul></ul></ul><ul><ul><li>Best Practices </li></ul></ul><ul><ul><ul><li>3/N Tier or Service Oriented Architectures. </li></ul></ul></ul><ul><ul><ul><li>Avoid use of extensions that create vendor lock-in. </li></ul></ul></ul><ul><ul><li>Implementation Guideline </li></ul></ul><ul><ul><ul><li>Referential Integrity must be system managed. </li></ul></ul></ul>
    7. 7. <ul><li>EA is comprised of a collection of informational items/elements. Collectively, these elements are used to guide IT decisions. </li></ul>Principles & Standards - Industry & Practices General & Vendor Specific Implem. Guidelines Policies & Legislation Supporting Purchasing Contracts Workgroups & Committees White Papers Glossary Presentations
    8. 8. Enterprise Architecture <ul><li>I need more…what are we really talking about here… </li></ul><ul><ul><li>GIS has become essential to the IT of today. </li></ul></ul><ul><ul><li>It is used both operationally and analytically to solve address critical business issues. Everyone agrees that the data provides high value…. </li></ul></ul><ul><li>Therefore… </li></ul><ul><ul><li>Enterprise grade principles and approaches must be followed, regardless of Organization size or limited success and/or failure is almost certain. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
    9. 9. Enterprise Architecture <ul><li>I hear what you are saying but I am not sold…. </li></ul><ul><li>Well, here are a few example of “things” that you might want to consider…. </li></ul><ul><ul><li>What happens if the business requirements change, can you adapt, and if so how fast? </li></ul></ul><ul><ul><li>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? </li></ul></ul><ul><ul><li>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? </li></ul></ul><ul><li>These are just three examples of why the Enterprise Architecture discipline is essential. </li></ul>
    10. 10. Application Methodology <ul><li>Why follow one? </li></ul><ul><ul><li>Wild Wild West days are over. </li></ul></ul><ul><ul><li>Must think Enterprise Class, even if budgets are limited. </li></ul></ul><ul><ul><li>Perspective should be “I will not always be here, I should leave a good legacy”. </li></ul></ul><ul><ul><li>Forward focused “how can I do more with less”. </li></ul></ul><ul><ul><li>Align with predefined Application or Service-based Architectures. </li></ul></ul><ul><li>Build using Industry Guidance (e.g. IEEE based). </li></ul>
    11. 11. Application Methodology <ul><li>System Development Life Cycle (SDLC) includes:  </li></ul><ul><ul><li>Process Management </li></ul></ul><ul><ul><ul><li>CMM </li></ul></ul></ul><ul><ul><ul><li>TQM </li></ul></ul></ul><ul><ul><ul><li>Six Sigma </li></ul></ul></ul><ul><ul><li>Project Management </li></ul></ul><ul><ul><ul><li>Staffed, Formalized, and Tool Based </li></ul></ul></ul><ul><ul><ul><li>Metrics Management </li></ul></ul></ul><ul><ul><ul><ul><li>Primary </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Secondary </li></ul></ul></ul></ul>
    12. 12. Application Methodology <ul><li>Project Management </li></ul><ul><ul><li>Primary Metrics </li></ul></ul><ul><ul><ul><li>Quality </li></ul></ul></ul><ul><ul><ul><ul><li>Did the user get what they wanted? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>How well does deliverables map to Functional Requirements? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>How many defects are in the code? </li></ul></ul></ul></ul><ul><ul><ul><li>Schedule </li></ul></ul></ul><ul><ul><ul><ul><li>Did the project come in on time? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>What parts of the project slipped? </li></ul></ul></ul></ul><ul><ul><ul><li>Budget </li></ul></ul></ul><ul><ul><ul><ul><li>Over or Under? </li></ul></ul></ul></ul>
    13. 13. Application Methodology <ul><li>Project Management </li></ul><ul><ul><li>Secondary Metrics </li></ul></ul><ul><ul><ul><li>Change </li></ul></ul></ul><ul><ul><ul><ul><li>5% or more must be approved. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Scope Creep can cause a project to fail. </li></ul></ul></ul></ul><ul><ul><ul><li>Training, Training, Training, Training, … </li></ul></ul></ul><ul><ul><ul><ul><li>Good training plans are essential. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Developers may need new skills. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Users will need to be trained on the new system. </li></ul></ul></ul></ul><ul><ul><ul><li>Resource </li></ul></ul></ul><ul><ul><ul><ul><li>Needs rise and fall over the life of the project. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Staff comes and goes - must be able to adapt (contingency plans?) </li></ul></ul></ul></ul><ul><ul><ul><li>Issue/Risk Mitigation </li></ul></ul></ul><ul><ul><ul><ul><li>Must be tracked and resolved. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Staff assigned, description, status, etc. </li></ul></ul></ul></ul>
    14. 14. <ul><li>SDLC continued:  </li></ul><ul><ul><li>Application Development Methodologies </li></ul></ul><ul><ul><ul><li>Waterfall </li></ul></ul></ul><ul><ul><ul><li>Iterative Waterfall </li></ul></ul></ul><ul><ul><ul><li>RAD - Rapid Application Development </li></ul></ul></ul><ul><ul><ul><li>Extreme Programming </li></ul></ul></ul><ul><ul><ul><li>SODA - Service-Oriented Development of Applications </li></ul></ul></ul><ul><ul><ul><ul><li>SOA – Service Oriented Architecture </li></ul></ul></ul></ul>Application Methodology
    15. 15. <ul><li>Waterfall - Characteristics </li></ul><ul><ul><li>Monolithic. </li></ul></ul><ul><ul><li>Rigidly requirement focused and change limited. </li></ul></ul><ul><ul><li>Highly structured and documentation oriented process. </li></ul></ul><ul><ul><li>Delays often occurred due to poorly understood or changing requirements. </li></ul></ul><ul><ul><li>Tightly coupled design and coding techniques did not accommodate change. </li></ul></ul><ul><ul><li>Massive changes are often required late in the project which caused slippage or even failure to occur. </li></ul></ul><ul><ul><li>Goes against the need for change and flexibility. </li></ul></ul>Application Methodology
    16. 16. <ul><li>Iterative Waterfall - Characteristics </li></ul><ul><ul><li>Breaks large deliverables into smaller accomplishable units while still focusing on accomplishing overall business requirements. </li></ul></ul><ul><ul><li>Collaborative in nature. </li></ul></ul><ul><ul><li>Frequent releases due to fine grained components accommodate change and provide early customer satisfaction. </li></ul></ul><ul><ul><li>Easily can build on base implementation. </li></ul></ul><ul><ul><li>Strong continual feedback loops improve quality. </li></ul></ul><ul><ul><li>Avoids running into large changes that can not be performed in timely manner. </li></ul></ul><ul><ul><li>Iterations must remain release focused and must not become ad-hoc in nature. </li></ul></ul>Application Methodology
    17. 17. <ul><li>RAD - Characteristics </li></ul><ul><ul><li>“ Rapid Application Development”. </li></ul></ul><ul><ul><li>Similar to Iterative Waterfall in concept. </li></ul></ul><ul><ul><li>Tools and Technology based. </li></ul></ul><ul><ul><ul><li>4GLs </li></ul></ul></ul><ul><ul><ul><li>Code Generators </li></ul></ul></ul><ul><ul><ul><li>Code reuse is essential </li></ul></ul></ul><ul><ul><li>Implementation times are usually very short. </li></ul></ul><ul><ul><li>Use cautiously for enterprise class systems. Proven formalized processes must exist and be followed. </li></ul></ul><ul><ul><li>Have to avoid the issue of generating “bad code faster” or “coding yourself in corner”. </li></ul></ul>Application Methodology
    18. 18. Application Methodology <ul><li>Extreme Programming - Characteristics </li></ul><ul><ul><li>Leading edge. </li></ul></ul><ul><ul><li>Informal and narrowly scoped. </li></ul></ul><ul><ul><li>Viable for Tier 1/Class A organizations only. </li></ul></ul><ul><ul><li>Highly collaborative based. </li></ul></ul><ul><ul><li>Shifts focus from defined starting and stopping points to continued development . </li></ul></ul>
    19. 19. Application Methodology <ul><li>SODA - Characteristics </li></ul><ul><ul><li>“ Service Oriented Development of Applications”. </li></ul></ul><ul><ul><li>Fundamental shift from classic Application Development to “Providing Software Services”. </li></ul></ul><ul><ul><li>Deliver high quality &highly reusable software. </li></ul></ul><ul><ul><li>Leverage Service Oriented Architectures (SOA). </li></ul></ul><ul><ul><li>Service reuse is a cornerstone philosophy. </li></ul></ul><ul><ul><li>Encourages purchase of Web Services from 3rd Party Vendors. </li></ul></ul><ul><ul><li>Establishes a discipline of code only when necessary. </li></ul></ul><ul><ul><li>Technology Model (e.g. .NET or J2EE) agonistic. </li></ul></ul><ul><ul><li>Introduces new roles such as Designers/Modelers, Assembly Editors, Orchestration Editors, Rules Editors, Business Analysts, Software Quality Experts . </li></ul></ul>
    20. 20. Technology Terminology <ul><ul><li>Web Services </li></ul></ul><ul><ul><ul><li>XML, WSDL, UDDI, SOAP </li></ul></ul></ul><ul><ul><li>Service Oriented Architecture (SOA) </li></ul></ul><ul><ul><ul><li>Many flavors available. Market is still stabilizing. </li></ul></ul></ul><ul><ul><li>Service Oriented Development of Applications (SODA) </li></ul></ul><ul><ul><ul><li>Methodology for development of WS application using SOA. </li></ul></ul></ul><ul><ul><li>Integrated SODA Environment (ISE) </li></ul></ul><ul><ul><ul><li>SunOne/Forte, Borland JBuilder, VB.NET, ArcGIS </li></ul></ul></ul><ul><ul><li>Frameworks/Languages </li></ul></ul><ul><ul><ul><li>J2EE – Java, Java Beans, EJBs, JSP </li></ul></ul></ul><ul><ul><ul><li>.NET – VB, ASP, VB.NET, ASP.NET </li></ul></ul></ul><ul><ul><li>Business Process Modeling </li></ul></ul><ul><ul><ul><li>UML (Unified Modeling Language) </li></ul></ul></ul><ul><ul><ul><li>RUP (Rational Unified Process) </li></ul></ul></ul>
    21. 21. Application Methodology <ul><li>Major Phases of Application Development </li></ul><ul><ul><li>Project Planning </li></ul></ul><ul><ul><li>Business Functional Requirements </li></ul></ul><ul><ul><li>High Level Design </li></ul></ul><ul><ul><li>Detail Level Design </li></ul></ul><ul><ul><li>Construct/Build (Code) </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>Post Implementation Support </li></ul></ul>
    22. 22. Application Methodology <ul><li>Construct/Build </li></ul><ul><ul><li>Fine grained/Loosely coupled components. </li></ul></ul><ul><ul><li>Component builds (ROT = 40 hours or less). </li></ul></ul><ul><ul><li>Weekly (not weakly) peer review of code. </li></ul></ul><ul><ul><li>Strongly commented code. </li></ul></ul><ul><ul><li>Teams based on functions and skill sets. </li></ul></ul><ul><ul><ul><li>User interfaces </li></ul></ul></ul><ul><ul><ul><li>Business Logic </li></ul></ul></ul><ul><ul><ul><li>Data access </li></ul></ul></ul><ul><ul><ul><li>Testers </li></ul></ul></ul><ul><ul><ul><li>Trainers </li></ul></ul></ul><ul><ul><ul><li>The list goes on…. </li></ul></ul></ul>
    23. 23. Application Methodology <ul><li>Types of Testing </li></ul><ul><ul><li>Unit </li></ul></ul><ul><ul><li>System </li></ul></ul><ul><ul><li>Regression </li></ul></ul><ul><ul><li>Interface </li></ul></ul><ul><ul><li>User Acceptance </li></ul></ul><ul><ul><li>Stress </li></ul></ul><ul><li>Testing Tools/Software </li></ul>
    24. 24. Application Methodology <ul><li>Deployment Alternative </li></ul><ul><ul><li>Pilot Project </li></ul></ul><ul><ul><ul><li>Production class with out massive scale. </li></ul></ul></ul><ul><ul><ul><li>Deployed to select portion of the business. </li></ul></ul></ul><ul><ul><ul><li>Not an Alpha/Beta . </li></ul></ul></ul>
    25. 25. Resources <ul><li>NC Statewide Technical Architecture </li></ul><ul><ul><li>http:// irm .state. nc .us/ techarch </li></ul></ul><ul><li>Information Resource Management Commission </li></ul><ul><ul><li>http:// irmc .state. nc .us/ </li></ul></ul><ul><ul><li>Policy and Standards </li></ul></ul><ul><ul><ul><li>Implementation Framework for Statewide Information Technology Projects. </li></ul></ul></ul><ul><ul><ul><li>Lessons Learned From IT Projects. </li></ul></ul></ul>
    26. 26. References <ul><li>Gartner Group </li></ul><ul><ul><li>SODA Environments Support the Application Platform Suite (SPA-18-5159). </li></ul></ul><ul><ul><li>Some Vendors Will Survive SODA, and Others Won’t (SPA-18-7422). </li></ul></ul><ul><ul><li>Producer Platforms and SODA Will Shift the AD Approach (T-16-5731). </li></ul></ul><ul><ul><li>AD Cultural Revolution: Services-Oriented Development (COM-18-9221). </li></ul></ul><ul><ul><li>Service-Oriented Architectures Foster Real-Time Capability (COM-18-9401). </li></ul></ul><ul><ul><li>Predicts 2003: SOA to Stir up Application Server Market (SPA-18-8377). </li></ul></ul><ul><ul><li>Predicts 2003: SOA Comes of Age via Web Services (SPA-18-8378). </li></ul></ul><ul><ul><li>Implementing Web Services Development Roles (TU-16-2389). </li></ul></ul><ul><ul><li>ARAD Brings Architectural Compliance and Developer Productivity (COM-18-9804). </li></ul></ul><ul><ul><li>Architected RAD Tools Are Delivering Major Benefits (T-19-0792). </li></ul></ul><ul><ul><li>The Cost and Risk of Application Development Decisions (R-16-1411). </li></ul></ul><ul><ul><li>Application Development Skills and Technology Trends (R-18-0318). </li></ul></ul><ul><li>Number: SPA-18-515 </li></ul>
    27. 27. References (continued) <ul><li>META Group </li></ul><ul><ul><li>META Delta – Application Delivery Strategies – Delivering Iteratively (File 939). </li></ul></ul><ul><ul><li>META Delta – Service-Oriented Architectures: Part 1 – Defining Reusable Enterprise Services (File: ADS 1244). </li></ul></ul><ul><ul><li>META Delta – Service-Oriented Architectures: Part 2 – Governance for Enterprise Services (File: ADS 1245). </li></ul></ul><ul><ul><li>META Delta – Service-Oriented Architectures: Part 3 – The Case for Services (File: ADS 1246). </li></ul></ul><ul><ul><li>META Client Advisor – A Model Approach to Business Process Modeling: A Primer. </li></ul></ul>
    28. 28. Questions <ul><ul><li>Stan Jenkins </li></ul></ul><ul><ul><li>Senior Enterprise Architect </li></ul></ul><ul><ul><li>Office of Information Technology Services </li></ul></ul><ul><ul><li>Enterprise Technology Strategies </li></ul></ul><ul><ul><li>State of North Carolina </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul>