Architecting Future Enterprise Applications with Progress

Architecting Future Enterprise Applications with Progress
OpenEdge Reference Architecture Welcome to Progress Open Edge Reference Architecture (OERA) Series. This Presentation give you an Overview of - The Challenges faced by businesses and how architecture fits in to help your business and applications stay competitive. - The High Level Architecture including the evolution of software towards a N-Tiered, Process Oriented Approach to modern application architectures. - How the Progress Technologies fit within the architecture and how other technologies can be integrated to form complete business solutions. The Models and Concepts for thinking about the components within OERA and how they fit together. The Methods for modernization and maintaining your business application going forward. Paul Petersen Senior Product Manager and OpenEdge Evangelist

Today’s Agenda The Challenge The Architecture Future Models
A Methodology Conclusions [copy of notes from previous slide] Today’s Presentation give you an Overview of - The Challenges faced by businesses and how architecture fits in to help your business and applications stay competitive. - The High Level Architecture including the evolution of software towards a Open Distributed, Service Oriented Approach to modern application architectures. - How the Progress OpenEdge Technologies follow the OERA, as well as how other technologies can be integrated to form complete business solutions. Future Models including SOA and how it effects applications, enterprise and extended enterprise systems. We will also look at Concepts for thinking about the components within OERA and how they fit together. The Methods for transforming your modernization and maintaining your business application going forward. Please, Remember this is an overview, so we will be introducing concepts and ideas first. Later Web Seminars will follow with progressively give you more detail. If you have an immediate business need, like many of the customers I currently engaging and find that that you need more information after this web presentation, please get in contact with your local account manager. So lets get started.

Business Challenges Streamline operations Greater visibility
Automate operations Grow Profit Gain new efficiencies Expose opportunities Increase customer value Excite prospects Grow Revenue WIN new business Its all about competitive positioning. Businesses must be constantly improving their competitive position if they are to survive. Eliminating or reducing expenses not directly related to the main competitive advantages of a company frees up resources to tackle those things that are directly related to competitive advantages. That’s how companies get ahead. That’s how company create more value for their stakeholders. From Giga 2002 : There are three main drivers to cost reduction: - Relentless drive for efficiency—internally and across business relationships - Shift to self-service - Customer, suppliers, partners, employees - Return to core competencies - Focus on business value differentiation vs. technical infrastructure Every company is, and will remain on a relentless drive for efficiency in every corner of the business. Most of the individual processes in a business have already been automated in one fashion or another. Inefficiencies remain, however, in how these processes interact with each other within the organization, and how these processes interact with similar processes external to the organization. There is much to be gained by tackling the inefficiencies found in every business where departments interact, where the company interacts with customers and suppliers, and in the interaction that every business has with the many partners and organizations that it deals with on a daily basis. Business are also looking for greater flexibility in how they work with customers, suppliers, and other partners. They are searching out all of the ways that they might gain efficiencies through smoother interaction with others. One of the primary answers in this search is the idea of self-service. If customers can enter and check the status of their own orders, they are happier and the company saves money. If suppliers can check for inventory replenishment needs themselves, everyone saves money. If financial customers can make loan payments, check interest rates, and initiate transfers without making phone calls, everyone saves time and money. A flexible environment enables these changes in information flow and information sourcing. - Finally, focusing on core competence, is an acceleration of a trend that started years ago. With limited money, time, people, and other resources, businesses are taking a more critical approach to what is core to the business. They are out-sourcing everything from human resources to warehousing, assembly to order fulfillment. But effective out-sourcing requires new definitions of business partners. As increasing amounts of the business are out-sourced to partners, new process management techniques must be put in place to ensure that efficiencies gained from outsourcing are not lost in the management of the relationship. This requires business applications that are more open to external integration and cooperation. In other words, it requires applications that collaborate with other applications.

The Technology Challenge - Keeping up with Technology
Linux AIX Solaris HP/UX Windows Applications Application Framework Integration Application Server Data Management Client Processing Business Processing Analytical Processing Application Management Development Tools Platforms SNMP .NET Services HTML Java JMS XML SOAP WSDL JCA One of the biggest challenges is how to keep up with technology – certainly I and many CTOs I talk to struggle to keep up on top of the myriad array of new product features and ways to leverage them for maximum business benefit. There has been waves of new technology innovation, but it how slowed a little since the internet and tech boom burst. With the latest recession there has been a far more balanced approach with business departments demanding more value and outcomes from IT. The Progress OpenEdge platform give our customers the ability to focus on business ready applications. It does not require that you abandon industry and vendor standards. We respect those standards and help you work with them. Progress OpenEdge technology is reliable …. Simple, effective. It is the culmination of years of development that has addressed building competitive, business-ready applications that are also ready for e-business. The tight integration between each of the products within OpenEdge brings you all the advantages that Progress is known for: performance, quick implementation, and cost effective deployment. In addition, the Open nature of the platform, the adherence to industry standards required for Internet-ready applications, brings to you the advantages of a business application platform that is ready for any aspect of e-business and collaborative commerce. The result is a platform that has enabled customers to build some of the most innovative e-business systems. (Click) And, industry analysts agree. OpenEdge has all the pieces required for building e-business applications. So, anything you can imagine, A brand-new e-business application Moving an existing back-office application to the Web Integrating suppliers, trading partners, customers…. … you can do with Progress OpenEdge. SSL HTTP HTTP/S HTML XML Java .NET SOAP Oracle SQL Server XML, Objectstore ODBC JDBC ODBC SQL92

Meeting the Challenge – by Leveraging Change
Business Technology Industry Direction, Input and Feedback Agile and Streamlined Business Models Changing Industry Models Emerging Technologies New IT Systems Thinking Globalization, E-Business, Deregulation, Disintermediation, Supply Chain Integration, Economic Vulnerability Internet, Standards, Java, Integration tools, HTML, XML, SOAP, JMS, New Platforms Time-to-market, Mergers & Acquisitions, New Products & Services, CRM, Business Intelligence, Business Agility, Business Process Reengineering EAI, Data Integration, J2EE, .NET, OpenEdge, Component Reuse, Web Services, Distributed Deployment, Agile Methods Strategic Business and Partner Plans Industry Enterprise Architecture – System Roadmap Products & Services Process People Operational Excellence, Continuous Improvement $ - IP Bank Commercial Innovation Technical Innovation So how might we meet the Business and Technology challenges, both on the Industry and Enterprise front. First of all we must continue to engage with Industry to get input and feedback on the service we deliver to customers, partners etc. Enterprise Product Plans – New Technology Use

Enterprise Application Requirements
1. Compelling User Interface / Experience The Application Needs to Sizzle 2. Integration Everywhere Advanced Integration and Collaboration 3. More Agile and Easier to Customize Service Easier to Add New Features and Functionality 4. Distributed Access Logic Access from All Points and Technologies Compelling User Interface UI Appearance / Presentation (WOW Factor) User Reporting User customized/personalized access to Data/selection of report presentation, timing etc (Also overlaps Integration everywhere) 2. Integration Everywhere Better integration - building block approach, need real-time monitoring Standards, Standards, Standards – but there is always exceptions Select Standards Based Service Adaptors, Use a Service Bus as an integration fabric 3. Active Application (N-Tier, SOA Models) Business and systems are automated/make decisions across an enterprise, Humans are the exception! Separate Business Logic (make N-tier) – method of documenting and protecting IP This allows the logic and process flows to become Interface independent for automation. Logic and tasks become reusable and better prepared for various integration scenarios. Service Oriented (SOA) implies Business Transactions can be split up and progressed forward or backed out one interaction at a time. It also implies the potential for consumer-based input, orchestration, consumer based packaging (use of services) BM3 –Business Modelling, Management and Monitoring are placed in the users hands. New tools are required. Other Benefits - Leverage existing IP in new products or use parts in variants, new business models possible. Reduced maintenance 4. Better Packaging and Deployment Two Types - Business and App oriented 1. Business Services/Product Packaging (Grouping of Services into Business Models eg Order Management), Repackaging for Rebranding, Outsourced/Insourced Industry Chains 2. Application Packaging and Electronic Deployment, upgrade, web delivery, just in time etc. 5. Performance Boost Manifests as quality control, tuning, coding and designing for performance, analysing bottlenecks, scalability Let the framework do the job for you to concentrate on business domain not technology. Integrate with real-time monitoring s/w 5. Scaleable “Plug and Play” Applications Grow with the Business, Standards Based 6. Simple to Deploy and Configure Minimize Administration and Setup Effort

Today’s Agenda The Challenge The Architecture Future Models
A Methodology Conclusions This is the outline for our agenda today. [notes are on previous slide] Remember this is an overview, so we will be introducing concepts and ideas first. Later sessions will follow with progressively more detail. So lets get started.

What is a Reference Architecture?
A Reference Architecture “describes a high level system design and guidelines for engineering …” modern, component-based enterprise applications. “What is a Reference Architecture?” … A reference architecture describes a high level system design and guidelines for engineering a modern, component-based enterprise applications. [click] For Example - Think of a reference architecture like the blueprints or plans to a house extension, a new city or urban development project. In terms of software architectures a high level design can represent an application, an enterprise system or extended enterprise system. By utilizing a modern design and the guidelines, you can transform your current situation to the desire new situation.

What is the OpenEdge Reference Architecture?
A guide to best practices in application development A map for Progress products and their applicability A method for delivering competitive advantage The OpenEdge Reference Architecture is more … It is a … One size does not fit all! We understand…

A Guide to Best Practices
Good Software Architectures - Stand the Test of Time! Anticipate trends in technology Accommodate evolving business requirements Manage complexity Optimize planning and resources Reuse valuable intellectual property Main Point(s): 1) Progress is delivering more then just product, we are delivering best practices for building competitive business applications. 2) The Reference Architecture is designed to make it easier to develop and sustain competitive advantage. COMBINE THIS SLIDE with the next to shorten the presentation. There is a slide in the hidden section that already combines the message of these two slides. Use that in place of this slide and the next. Do not remove the next slide only, as it provides the visual diagram that will be used the rest of the way through the presentation. Script: Look behind the scenes at any business application that has remained highly competitive over a long period of time and you will find three distinct characteristics: 1) Continuing attention to the distinct needs of the industry served by the application, 2) Constant upgrade to features, technology, and functionality, and 3) a strong application architecture that makes it much easier to evolve and enhance then application, keeping it fresh and ahead of the competition. That’s the idea behind the OpenEdge Reference Architecture. We want to provide the best practices of business application construction to the entire Progress Community. We worked with dozens of partners and industry experts to pull together an architectural vision designed to help our partners get the most out of our platforms and their applications. The reference architecture is specifically designed to more easily anticipate and accommodate future application and technology trends. It is designed to reduce complexity by carefully segmenting and cataloging application components. And, used properly, it can serve as a guildeline for planning – projects, products, and resources. The reference architecture is not a product. You can’t order it on our price list. But you definitely can benefit from it. We’re working every day with partners that are applying all or parts of this architecture. We’ll be rolling out classes, seminars, white papers, and presentations on the OpenEdge Reference architecture all through And the reference architecture will play a prominent role at Exchange this year. Details: Clearly articulate the Value Proposition of the underlying capabilities Balance competing forces eg user demands vs technical cost, flexibility vs performance, first vs best, art vs craft Roadmap paths that incorporate Industry Trends, Business and Technical aspirations Capturing and evolving Valuable Intellectual Property ($) Design Objectives, Principals, Assumptions, Alternatives and Decisions System Capabilities, Use, Limits Essential Artifacts eg Specifications, Practices, Terms Value Proposition (architectures marketable capabilities) Reducing complexity, optimizing resources and improving quality through a system of Models eg SOA, MDA, MVC Patterns eg Façade, Active Record, Standards eg Methods and Techniques eg RUP, Incorporate proven and applicable industry standards, models and methods ETC Provide a Solid, Modern Foundation for Competitive Business Applications

A map for Progress products and ..
Evolutionary Parallels technology market trends. New, but evolutionary Progress has made it easy to move up to the next technology version. Allowing you to retain and maximise your investment by allowing the old stuff to continue to work it has been a mantra – future-proof. Other technologies often force you embark on a larger rewrite – this can be very beneficial but may not match to your investment strategy or budget. What we find is that may partners, businesses and IT shops do not always the best way or how to maximize their ROI keeping the older stuff where the pay-off remains good but is not growing, while at the same time . Example: Progress though business empowerment, the new technical empowerment, the use of OERA and consulting are working every day with more partners to help them evolve there Investment forward, finding new ways to leverage Intellectual Property often only maintained in code and move it forward to place new capabilities into the . The new way is componentized, distributed service oriented applications. A mouth full but each part provides the basis for significant business benefit as we will see throughout the remaining presentation. We can use history and the industrial revolution as a parallel analogy for how software provision of the future will occur. Parts or components are used to manufacture or build new products and capabilities … some areas will commoditize like perhaps General Ledger or other basic financial recording provision … every company needs one. It’s always been about the Business Logic V8 was about Client/Server V9 was about n-tier scalability OpenEdge 10 is about Distributed Service Oriented Applications

.. and their applicability
Componentize Integrate Collaborate Know where you are Know where you want to go Extended Enterprise Enterprise N-TIER Application

A Method for Delivering Competitive Advantage
Awareness Business Assessment Application Analysis Positioning Transformation Monitor & Review Engagement Capability Gap Fulfillment Project Planning & Management Commitment 2nd Iteration Nth Iteration … 1st Iteration

Technology Transformation
Has driven architecture transformation Application development and application architectures have had an interesting and sometimes painful evolution Process-Oriented Applications Distributed AppServer Client Host Centric Client Server Business Process High-Level: To move to collaborative applications, we have to start at the architecture level. Monoliths don’t collaborate. Even when they exchange, they don’t collaborate. While previous architectural transformations were primarily system-driven, this change will be business-driven. By positioning the business processes as the primary architectural force, we can start thinking about applications differently and we can implement an architecture that supports their central role. Detail: A quick look at current architectural models will show the changes that must happen. Over time, we’ve moved from a single single “block” view of an application to a tiered view. That has been a good transition. But each step of that transition has been driven by technology demands, not business demands. In talking to developers, you get the feeling that if they could all figure out how to get back to the host-centric architectural model, they would. After all, it worked, it solved business problems, and many of today’s applications are still ground in that simpler architecture. But user interface models and network restrictions moved us through the client server model to the distributed, n-tier model. But all for the sake of the technology, not the business requirements. The next transition will change all of that. Process oriented architectures are all about focusing on the business first. These approaches break the application up into small segments defined by the business processes that the application provides. This process-based approach is designed to make interoperability easier. Each process exists separate from all others, but each can also call on any other process to help perform a task or present a set of information. This is where the concept of “business services” comes from in the application world – a process that exists as a service for any other process. Think of it in this way: For years now, people have been talking about separating business logic from the user interface. But the components were separated in only a single dimension – between process and screen. With SOA, we need to also split the application into pieces by functionality. There should be a single, standalone component, for example, that checks for customer credit. It may be used in dozens of places, but it is only designed and developed once. And yes, this is like object orientation – but at the business component level. It has nothing to do with technology or programming widgets. This is a fundamental change in the way applications are thought of, organized, and built. This is the theory upon which Web services are based. And it is the core fundamental philosophy of the service oriented architecture. Story: There was an inventory system that I remember that had a problem in its algorithms that were used to calculate average cost when products were brought into inventory. Sounded simple to me – find it and fix it. But it turned out that there were 47 different places where inventory came into the system and costs were calculated! It was about impossible to fix correctly, and would have been impossible to expose as a service. If a 48th requirement for inventory had come in, the developers would written a 48th iteration. They couldn’t use any of the other 47 because each was well embedded in its particular place – it could not be separated from its context. Under this scenario, the best you get is “cut-and-paste” re-use, which doesn’t help our integration cause at all. – we need to change the fundamental thinking to prevent this and get real reuse – not cut & paste Architecture Evolution Service-Oriented Architecture (SOA) is the next-generation interoperation methodology Technologies such as Web Services are a means to that end

Older Applications – Host-Based, Fat Client
Char/GUI Web O F I Data Storage Users Multiple UIs – More Intuitive then Character Remote Customers/Users Logic still entangled Duplicated functionality Integration not the focus Network may bottleneck Define & discuss “Fat Web” Confirm duplicate/redundant code

New Demands Look Customers New Integration Char/GUI Web Data Storage O
F I O I O F I O F I S Data Storage

Centralized Business Functions
Customers Users Enterprise Services New Look Integration - Presentation - Functional - Doc / Data Char Web Order Mgmt Financials Inventory Supplier So coming back to our applications, what we really need to think about is how to change the application architecture to facilitate reuse (not just cut & paste). We need to encapsulate the business functions so that they can be called from any interface (User or application)… as the pace for integration speeds up the ability to “plug and play”.. Is key.. You can do that with centralized functions (business processes) And you also need to keep that layer of functionality separate from the interfaces (front and back).. Data Storage

Modern Application Architectures
OpenEdge Reference Architecture – a layered view Users Presentation Layer/s Business Servicing Layers Data Access Layers Managed Data Stores Unmanaged Enterprise Services Integration Layer/s Separated presentation and integration layers Common business logic with advanced models Data access abstracted from storage Extra Introduction Notes: Business Domain – Each business has it’s own unique policies, processes, rules, products, customers, services – business models. Understanding differences in terminology, use, business operations etc and documenting the model is the first step to developing a successful commercial enterprise application that can be packaged to meet the needs of a broad potential customer base. Packaged Enterprise Application – To sell across a spectrum of customers, your enterprise application must be flexible to handle different changing business requirements. Understanding common patterns within industries leads to . These patterns form the basis of your switch-able Application Systems Model. Once completed your Enterprise Application must be packaged so it looks tailored or can be tailored to the target customer base in a repeatable and cost-effective manner. Reuseable Application Framework - Technology Platform – The platform on which you deploy should be customer driven. Your application and framework should be platform independent but streamlined where necessary for performance. …. Main Point(s): 1) The reference architecture is starting to permeate all areas of information delivery within Progress. 2) Future product roadmaps and enhancements are being planned around the requirements of the various parts of the architecture. Script: This is a very simplified, high-level diagram of the architecture. We don’t really need to go into the details here today, but do want to point out a couple of very relevant points. <CLICK> First, the presentation and integration layers are both designed to sit on top of the same business logic layer, utilizing the same business logic and providing independence from that business logic. <CLICK> Nest, there is the business servicing layers themselves. It is not detailed here, but we have specific models for how business logic should be modeled and implemented to make applications easier to enhance. We’ll see more on that in a few minutes. <CLICK> Note also the separation of data access from data storage. Features such as the new ProDataSet make it easier to describe and implement an abstract data layer that makes applications easier to build and less restricted by the physical data layout. It also makes it easier to modernize existing applications. Materials on the details of the architecture are being readied for distribution currently. These materials will make their way through our empowerment, training, and services channels. Hides the complexity of the schema… very few APs will be able to change their schema frequently, and so a logical data model will assist them

OpenEdge = Implementation Options
Users Presentation Layer/s Business Servicing Layers Data Access Layers Managed Data Stores Unmanaged Enterprise Services Integration 4GL, Char, GUI, HTML WebSpeed .NET, ASP JSP/Applet Other - Devices Sonic ESB I-Way Adaptors BPM Bridges – MQ-Series Sonic ESB Adaptor Web Services In/Out XML 4GL Sockets / Streams 4GL / AppServer Smart Objects OE Framework ProDataSets OS Independence Main Point: Don’t assume technology into this architecture. We fully expect that the technology choices will be varied as people put this into play. A few basic facts: 1) A given implementation may be all Progress products or a mix of Progress and non-Progress products. 2) This architecture can be implemented with quite a choice of Progress versions and technology. OE 10 makes it easier then V9, but it can be implemented in V8! 3) Sonic is an important part of this architectural vision, but again, the architecture can be implemented with or without Sonic. 4) Some will build new applications in this manner, some will re-engineer in this manner, others will gradually migrate to this approach. Not every implementation need be ‘pure’ or complete. Progress RDBMS Oracle, SQL Server New Data Types ObjectStore Flat Files e.g. Log, Audit etc XML Server Registry

Guiding Principles of OpenEdge
… applications are a collection of software components that reflect changing business processes. Business Logic … they do not exist as an island. Interoperability and integration is an inherent requirement. Integration Main Point(s): The big release for 2003, of course, was OpenEdge 10. The emphasis for OpenEdge 10 is around the three areas of Business Logic Capabilities, Integration Capabilities, and User Interface Capabilities. Script: One of the largest releases of the year occurred right at the end of the year – OpenEdge 10. We want to spend some time on OpenEdge 10, so let’s start with a quick reminder of the guiding principles behind the product. These should be familiar to all of you, as we have highlighted these at various conferences and meetings over the year. It starts with a simple concept. Good business applications are nothing more then someone’s idea on how a business should run, expressed as software. It is our job to make that task as simple as possible. Building applications is still harder then we would like. With OpenEdge, it is our job to constantly be making it easier to build business applications. That’s one of the reasons that we are looking at service oriented architectures and service oriented business applications – both are approaches that hold great promise for making application logic easier to build and enhance. But that’s not enough. Standards based integration has become a requirement for every application and every account. Non-standardized integration methods tend to be costly, difficult, and not scaleable. We believe that new applications will be designed with integration as a core capability, and that gradually, all applications will evolve to be integration aware based on a set of industry standards. Finally, we need to take another look at user interface techniques. For years, most applications have been tightly bound to one concept of a user interface. In fact, applications are still built from the “outside in”, starting with the user interface. This presents quite a problem, given the changing nature of user interface technologies, new integration technologies, and always-changing standards. We need to make it easier to build new applications and remodel existing applications such that business logic can be used and re-used with any number of user interface approaches and for more automated integration approaches. … and are not bound by any one user interface technology, methodology, or platform. User Interface

Applications are a Collection of Software Components
OERA – Component View Presentation Layer Users Enterprise Services Integration Layer Component-Based Architectures … Handle multiple UI’s Service Enabled Enterprise Connectivity Reuse Business Logic Multiple Data Sources Scalable Foundation Service Interface and Environment Utilities Business Workflows Business Tasks Business Entities Component-Based for Flexibility. Data Access Services Persistent Storage Services Managed Data Store Unmanaged Data Store

Components - Generic and Purposed
UI Components UI Controllers Integration Controllers Environment Logic Data Source / Persistence Interface (Services, Events, Admin) Data / Schema Persistent Storage Services Service Interface and Environment Utilities The Application Architecture has many components. The components can be thought of in generically in terms of common parts that make them up or in terms of the their purpose/use. From a generic sense - each component has a number of common pieces to it – - A defined interface through which communication with the component and external components occurs - Logic to perform calculations, business tasks and manipulate subjects - Data and its structure that may represent a domain entity, temporary cache for calculations, memory holding context and state information etc. - Persistence to/from a data source where information is stored beyond the life of the in-memory component - The component must also exist and operate within its environment. The component has a life-cycle within its environment. From a programming sense they are just all objects, pieces of code etc. However the value of modeling an application comes when you give define components with a purpose/role. For example, Business Entity components are purposed to encapsulate Domain Subjects including the definition of their attributes (data), the operations involved in managing their persistence to/from a data source such as a RDBMS and the basic actions that can be performed on the Subject ie finding, creation, update and deleting methods (logic). By defining a Business Entity, you can encapsulate and hide the messy details of mapping the in-memory model of a domain object form the source and storage model of the object as a set of tables in, say a RDBMS, XML store or even flat file. Business Tasks are purposed to complete a distinct part or a business process eg calculate commission. is common set of generic pieces. ThWe can define a component as he Architectural Components Business Entities Business Workflows Business Tasks

Business Logic Architecture
Exposed through service interfaces & standard data access Users Enterprise Services Componentized and normalized Business Entities structure the subjects of the application Business Tasks structure the actions of the application Business Workflows structure the processes of the application UI Components Enterprise Service Bus UI Controllers Integration Adapters Service Interface and Environment Utilities Business Workflows Business Tasks Business Entities Data Access Services Persistent Storage Services Managed Data Store Unmanaged Data Store

UI Architecture User Interface Independence
Users Enterprise Services OE UI Components .NET UI Controllers Web UI Components Web UI Controllers Enterprise Service Bus Integration Adapters .NET UI Components .NET UI Controllers DataSet OrderTT The foundation can be based upon a platform that supports business processing with Open UI ProDataSet Business Objects ProDataSet Data Sources Any Front End Service Interface and Environment Utilities Business Workflows Business Tasks Business Entities Data Access Services Persistent Storage Services Managed Data Store Unmanaged Main Points(s): 1) Possible implementation of the architecture using OpenEdge ) User Interface independence. Script: One of the important things to remember about the architecture is that it is a model, not a technology. It can be implemented in a number of ways with any number of tools and technologies. Here we have an example that is being used by several of our partners as they consider application upgrades using OpenEdge 10. The are using ProDataSets for the data access and service interface layers of their application, and using a combination of approaches for user interface components. The same service interface and business logic can then be used with integration adapters through the enterprise service bus for interoperability.

Integration Architecture Interoperability and Integration
Users SAP Web Service Web Service Adapters EDI / Proprietary EDI Adapters .NET UI Components .NET UI Controllers Sonic ESB IWay SAP Adapters The Business Logic remains the same for UI and Integration requirements Web Service Business Objects Interface Invoke other Web Services ESB Out of the Box Service Interface and Environment Utilities Business Workflows Business Tasks Business Entities Data Access Services Persistent Storage Services Managed Data Store Unmanaged Similarly it should be possible to handle changing Integration requirements. Many people still struggle with batch oriented file transfer …

Components and Productivity
Productivity: The means to solve a limited set of problems quickly in a proscribed manner. Traditional General Purpose Languages Purposed Component Managers Traditional Form-Based Frameworks Purposed Application Language Main Point(s): 1) Languages tend to sacrifice productivity to flexibility. Frameworks tend to sacrifice flexibility to productivity. 2) The answer are better purposed languages supplemented by strong component models. Script: Most programming languages stress flexibility. The idea that you can use the language to do anything is pretty powerful. But with many languages, productivity is pretty low. In fact, fourth generation languages got started on the concept that conventional languages of the day were simply not productive enough. Even today, the Progress 4GL is much more productive then say, Java. <CLICK> At the other end of the scale are forms and frame-work based development systems. Think of systems like PowerBuilder, or the older forms packages that it grew from. Productivity is such systems is much higher, but almost always at the expense of flexibility. Such systems tend to do simple things well, but complex things not at all or only with great difficulty. Such is always the issue with such systems. <CLICK> We believe that the answer lies in a combination approach. It starts with a more highly purposed language well suited for business, sophisticated data manipulation objects that help to model the real world. That’s the language found in OpenEdge, and it’s our intent to make that language both simpler and more sophisticated in what it can accomplish. The ProDataSet is just the first example. <CLICK> But to provide true productivity, that language should be supplemented by by an advanced component model – a model that supports re-usable components as a part of the development and deployment environment, and supports a container model for developing re-usable components as a part of the application itself. Flexibility: The means to solve almost any problem in almost any manner.

Architecture Summary OpenEdge has... Technology Platform
Architectural Vision to meet business and technical requirements Has the necessary flexibility without sacrificing productivity

Agenda The Challenge The Architecture Future Models A Methodology Conclusions

SOA - Service-Oriented Architecture
Process-Oriented Applications Business Process Business Process Business Process Standards Platform Integration User Interface Methods High-Level: A service oriented architecture is build on two basic premises: The concept that applications should consist of components build to and supporting standards that allow sharing between components and applications. The business processes are at the heart of the application and provide the basis for the application. Processes are organized into services that can be used both within and between applications. There are four parts to an SOA: Business process components that contain the intelligence of the application. User interface methods that provide human input and output sources for the business processes. Integration methods and platforms that provide non-human input and output sources fo the business processes. An agreed upon set of standards and contracts that describe all of the interface methods between the components. Detail: The most important aspect is the business processes themselves. An application is, in essence, a “catalog” of business processes that can be hooked together to form a complete application. So far, this sounds familiar. But the trick is turn the logical “catalog” into physical discrete business process “services” tied together through a common API. That API might be represented by an integration standard, a user interface method, or (most likely) both: Business Processes. Discrete processes that can be exposed to any standard method of integration or user interface with a thin API layer. The process should not depend on any workflow or operational context to do its work, and it should not have user interface or integration methods embedded in the process itself. User Interface Methods. Common ways for humans to interact with a business process. Keep in mind that a single UI might span multiple business processes, and a single business process might have multiple UI’s – both for functionality and technology purposes. For example, a pricing process might be implemented as part of an Order Entry screen and as a part of a web catalog. UI’s should not, of course, have business logic embedded in them. Integration Platform. While it is theoretically possible to have each process control its own integration requirements, that is probably not the right approach. The processes should connect to and depend on an integration platform that can handle standard requirements such as transformation, validation, security, and routing. Standards. This whole idea works only if there are standards in place for format, method, integration “language”, and standardized contracts between the processes and the other components. Some of these standards will be industry imposed, while others will take the form of contracts both within the application as a part of the API to the rest of the world. Service-Oriented Architecture

Extract from “Architectures and Patterns for Software Infrastructure”
Gartner Research note, 28 January 2003 “In the future, applications will increasingly be implemented by combining new developments and pre-existing systems, and by chaining business components - often referred to as "services " - that run on multiple systems. Business components will be technologically diverse and may even belong to different technology generations." And from Jason Bloomberg Principles of SOA Application Development Trends “…Service-oriented architectures provide the framework that will enable IT to offer value in the form of business agility…" Massimo Pezzini

SOA – A Sea of Services 1 10 2 9 6 3 7,8 4 5 1. Order Entry
Online Ordering Service Req. Order Notify Buyer OrderEntry 1. Order Entry 2. Request Supply 3. Validate Order 4. Check Credit 5. Bureau Check 6. Hold Stock 7. Approve Order 8. Fulfill Order 9. Notify of Supply 10. Notify Buyer 1 10 2 9 Supplier Service Check Credit Hold Stock Valid Order? 6 Inventory Mgmt Service Hold Ship Lookup 3 7,8 4 Order Mgmt Service Credit Services Approve Notify Chk Credit Valid Order Credit Bureau Approve FulfillOrder 5

Growing Complexity of Business
Extended Enterprise Enterprise Solution Complexity Application AP customers need to make this happen, and so this means that to keep competitive the application providers also need to be able to “play” well… Requirements

Maximizing Value to Business
Intelligent Connected Solution Value Components Business gets a return on its investment value when the solution gives both 1. Reuse – the ability to harvest a component for multiple purposes 2. Efficiency – the performance, economy etc of the system Questions: What happens as the reusable parts become more commoditized? Where does the value then come? The growing complexity of business (from application to enterprise to extended enterprise) adds complexity to the design , we need to reuse to maximize the value to the business, also reuse to gain new efficiencies. How do we encapsulate what the business functions (processes) are? Understanding this leads to components, and then knowing how to connect them and how to make them intelligent Parallel the manufacturing of cars for example. Reuse and Efficiency

Reference Architecture – Matrix
Desired Situation Scope Componentize Integrate Collaborate GLOBAL BUSINESS SERVICES FULL SOA GLOBAL BPM Supplier of choice to Global Accounts - Transacting across Industry Supply Chains Extended Enterprise SERVICE GROUPS FORMALISE WORKFLOW Supplier of choice for Enterprise Solutions Enterprise Admin, Management and Monitoring Reference Architecture (Non-Build Slide) This is the complete high level reference architecture that will be used as a starting point for discussing various conceptual models, model components, subject areas and architectural views of enterprise systems. The aim of the reference architecture is to describe a high level generalized design that is independent of any implementation details. It maps out a building block approach for describing various high level software architecture elements that vary in scope and by subject matter. (as previously introduced) N-TIER EXPOSE CO-ORDINATE Modern Best of Breed Business Applications Application Platform Tool Support Processing Engines Services

Clearly Define Your Goals
Know where you are, and where you want to go Desired Situation Scope Componentize Integrate Collaborate GLOBALISE BUSINESS SERVICES Service Enable Your App 4 Hor. & Vertical Int. Full SOA - Contracts Service Desc Open Stds - Security etc models Global BM3 – Model, Manage, Monitor BPM –Business Process Mgmt Supplier of choice to Global Accounts - Transacting across Industry Supply Chains Extended Enterprise MODULARISE Group Bus. Functions into Service Domains EXPOSE Expose Process Level Business Components as Services WORKFLOW Template process / work flow control with Flex rules Supplier of choice for Enterprise Solutions Enterprise Admin, Management and Monitoring Reference Architecture This is the complete high level reference architecture that will be used as a starting point for discussing various conceptual models, model components, subject areas and architectural views of enterprise systems. The aim of the reference architecture is to describe a high level generalized design that is independent of any implementation details. It maps out a building block approach for describing various high level software architecture elements that vary in scope and by subject matter. (as previously introduced) N-TIER Separate BL from UI, Data Access, External Conn. FORMALISE Formalise Interface Defns / APIs CO-ORDINATE Manage Events and In-Process Flow / Thread Control Growing Businesses with Modern, Best of Breed Business Applications Application Platform Tool Support Processing Engines Services

Extended Enterprise Level Services

The Extended Business Landscape
Agencies E-Procurement Customers Supply Chain Self-Service Suppliers HR GL Distribution Planning AP Payroll Devices Distributors Collaboration CRM Offices High-Level: The complications in all of this change come in when you look at all of the elements that have to talk to each other. Where once it was just the applications within the organization (and a limited set of those), today it is a whole extended enterprise – everyone that a business touches and all of their applications! So we’ve grown the number of applications within an enterprise, we’ve grown the number of interactions with partners, suppliers, and customers, and we’ve introduced new concepts such as commerce networks. The result is a complex network of interactions that must be coordinated and automated appropriately. Details: Most of the current applications that we have in place today were designed and implemented in a time of where environments were much simpler. Integration was an afterthought, not a core fundamental. The applications have been adapted to more complex environments over the years, but the core, fundamental concepts and operating principles are still rooted in a time and place that simply doesn’t exist anymore. The diagram above actually represents three different integration requirements: Enterprise Application Integration (EAI), Business to Business Integration (B2B), and commerce exchange integration. But to build the right architectures and applications, they need to be looked at as one. The diagram here represents information coming all to a central hub, but the problem is more realistically expressed as a web or fabric of integration. Each of the points on this chart will likely have mulitple integration points with multiple players in the diagram. The result is often a very confusing integration map with proprietary integration methods, data formats, and integration points. As the number of participants grow, the problem grow exponentially. Estimates of integration costs run as high as $50K per point per year, so the whole system soon become unmanageable just from a business standpoint, not even considering technology. Story: Take an order entry system as an example. The primary order entry system design always started with a customer service representative at the core. The systems were designed to provide key supporting information for that representative, and to record the actions requested by the representative. In other words, they assumed the existence of an employee to serve as the interpretive element of the order process. We later adapted these systems to the web, to EDI, and to other forms of B2B and B2C interchange. But the core application is still crafted around an old paradigm that describes order entry. Imagine a new order entry system that recognized and embraced a new, more complex environment. Such a system would be able to respond to requests automatically, regardless of the source of the request, with or without human operator intervention. Similar examples can be found in any application at any point in the extended enterprise. We need to move from applications that adapted to the complex environment to applications that are designed around the complex environment. Brokering Sales Collaborative Commerce Networks

Extended Enterprise Direction Sonic ESB
Operational Awareness Business Acceleration Adapter Distributed Standards-based Connectivity Verbatim initial view You can now see how this strategy stacks on top of the ESB architecture. At the bottom is the ESB layer, providing a distributed standards-based connectivity. where the white circles represent service interfaces the little documents represent XML messages flowing between services and arcs represent asynchronous message routes along the bus **click **In the middle is a process management layer, providing business acceleration so enterprises can squeeze out inefficiencies wherever they may exist. Where the process flow diagram represents the modeling and execution of processes and the bars represent splits and joins – where state is managed persistently **click** On top is an event monitoring layer, providing operational awareness through the use of XML services which can capture and analyze data to allow companies to respond reflexively to business vents in their business. Where the heart beat represents business and system events are captured the charts represent analysis processes which interpret this data the decision trees trigger new actions within ESB – starting the whole process over So there is a parallel between integration done on an ESB and traditional integration brokers. But let’s look at the implications of a enterprise-wide “bus” architecture and see how this might impacts the value of an ESB-enabled integration strategy. N E X T S L I D E …. SCM Integration Broker CRM Tracking Service Adapter Adapter Adapter Order Entry CRM ERP SCM Partner Finance Enterprise

Enterprise Level Services

Basic Enterprise Architecture
Remote Employees Partner Employees Partners Local Employees Customers Customer Systems Portal Application/s eg Enterprise, Employee, Public/Trusted Customer, Partner CRM Order, Job Management Inventory, Portfolio HR / Payroll Services Trading, Manufacturing Product Information Accounting, Treasury, GL Management Reporting

Business Processing Trends
Generate more granular, reusable business tasks Separate of rules for flexibility eg business/regulatory rules Wrap business logic with several service interfaces Generate front-side service logic to manage non-business task related issues eg Security, Transformation, Validation, Dispatch etc Separate business flow control Connect course-grained automated background tasks and loosely coupled process flows through an internal event bus There are some important trends we are seeing within the general software community as well as the Progress Community. One big trend is towards more granular business tasks to accommodate higher levels of flexibility, scalability and automation and servicing of the extended enterprise. Generation of more granular business tasks, providing greater ability to reconfigure tasks into new flows with different mixes of User and External Integration points There is also more Isolation of specialized/configurable algorithms and dependencies Separation of Intensive Business and Regulatory Rules as well as Product/Service Definitions Eg Stock Market Trading Rules, Mortgage Approval, Abnormal Credit Transactions, Insurance Claims Processing Rules, Alert Notification Rules Wrapping of Business Logic with Service Interfaces and Facades Used to mask proprietary integration protocols and logic spaghetti May require some re-engineering of existing logic Generate front-side service logic to manage non-business task related issues, eg. Different integration protocols, security, contract validation, session context, translation . . Separate business flow control Users can model and change work flows Connect course-grained automated background tasks and loosely coupled process flows through an internal event bus for Alert/exception management and monitoring Event/transaction - surge/shock-absorbers This also supports an easier way to scale up/down for the right market….. Ie small businesses may not be able to afford full feature rich functionality that a large organization can.. They can take the application and get more features as their business grows…

Enterprise Strength Services
Alert STOP Enterprise Service Bus Embedded Event Bus Alert STOP

Agenda The Challenge The Architecture Architecture Details A Methodology Conclusions

Application Level Services
Desired Situation Scope Componentize Integrate Collaborate GLOBAL BUSINESS SERVICES FULL SOA GLOBAL BPM Supplier of choice to Global Accounts - Transacting across Industry Supply Chains Extended Enterprise SERVICE GROUPS FORMALISE WORKFLOW Supplier of choice for Enterprise Solutions Enterprise Admin, Management and Monitoring N-TIER EXPOSE CO-ORDINATE Modern Best of Breed Business Applications Application Platform Tool Support Processing Engines Services

Business Systems Thinking …
Logic Processes Services Flows Orchestration Domain Nouns Subjects Verbs Actions Features Visualization Navigation Functions Customization Monitors Application Functionality

The Features Presentation Adding Sizzle to your Look and Feel - Role-Centric “Personal” Workplaces/Spaces Flexible Navigation – Hyperlink Style Summary Views – Dashboard Staged Workflows over Manageable Tasks Data Entry Performance Driven or Enquiry Oriented Active Alerts / Notification Events Automated Process Exceptions eg Missing Details in an Order Business Constraints eg Near $1M Overdraft Limit Customization eg Made-to-Order etc

The Domain Model – Nouns
Business Entities Users, Group Access and Config Settings Enterprise Management Eg Branches, Employees Business Environment Eg Countries, Calendar, Taxes Orders, Request Mgmt Eg Loan Applic, Job, Service Customer Information Eg Patient, History, Types Partners Eg Supplier, Distrib, Cpty Transactions, Positions Eg Inventory Products, Prices eg Stocks, Parts,Schedules Systems Integration And Data Loading The Domain consists of different types of Entities (Nouns): Subjects eg Customer, Supplier, Order The Subject is always kept current Business Control Items eg Flow Control Table, Rules, Configuration Switches etc System Control Items eg Program/Component Lists, Users, Groups Captured Events/ eg Order Requests, Payments, Reciepts History eg Customer History, Monthly, Statistics Events are usually captured to keep a history of events. The action taken from the receipt of an event usually updates the status of one or more “subject” entities. The previous state of the “Subject” customer may be stored as a record of what happened into a History Entity. Financial Information Eg GL, Bank Accts, Paymts System Support Eg Menus, Program, Auditing

The Domain Model – Verbs
Business Tasks Create New Users, Groups Change Branch Address Relocate Employees Change Income Tax Rates Enter Compliance Rules Accept/Update Order, Close Down Job Maintain Customer Enquire History Cancel Purchase Order Enter Transactions, Update / Increment Position Load Products Change Prices Send Load Delivery Schedules Accept Payment, Create Statements Change Configuration Monitor Kill Reports

Mapping the Business Domain to the Application
Nouns, Verbs, Sentences Events and Actions On receipt of price change from supplier update the product catalogue price Notify each SalesRep of the impact on their margins for all Open Quotes Rules The Bank Statement: total must reconcile to the sum of the banking transactions Exception If there is a bank reconciliation difference then alert the nominated financial controller Cause & effect

Inside the Business Services Layer
Consumer Service Interface Bus. Services Data Source Simple 1:1:1 EG Code Tables 1 Source / Table 1 Bus Entity Usually None or Native API 1 Consumer Type Medium Few :Few:Few EG Cash Receipt Few Tables / Data Sources Simple Tasks/ Few Entities Optional Service Interface Multiple Screens/ Consumer Types Request Across the top we have the layers including Clients/Consumers layer – eg UI and external enterprises Service Interface eg a special layer for business services that must be exposed to many different clients possibly across different technologies. Business Services layer Data Access and Source layer Basic Entity Methods and Entity Representation Tasks utilize Entity Methods to perform their work Services and workflows string together tasks to perform complex operations Combine it with the boxes we have now, and it helps to define the rules between entity, task, and workflow. While the rules will always be somewhat grey and should be defined by the application designer, the "simple" represents common business entity methods, while the "medium" represents atomic or tightly-couple sets of business tasks, while the "complex" represents larger sets of tasks that are more subject to outside exposure, task or step re-use, and business rules that alter the order or the execution of the tasks. So I think that this slide presents an explanation of how we see that middle layer being defined. In the next section we will take a closer look at the components that make up the Business Services Layer and how the interact at a high level. The Business Services layer is made up of a set of components. These include but are not limited to – - Service Interface/s - Workflows - Tasks - Entities - Environment Utilities and Managers The Service Interface describes the service to external consumers. External consumers can make service requests. After a service request is received, the Service Interface may need to - validate the request - perform security checks – authorization / authentication - transform the request - activate / route or start processes / objects to service the request - re-establish context / session state It will then invoke a business workflow component or directly invoke a business task to perform the service. Business Workflows are designed to invoke a series of tasks according to the business rules to compete the service request. One important thing to note is that there may be zero or many of each types of components and that each component may utilize environment managers as well as other components at or below its level but not above. If external services need to be invoked, then the Business Task or Workflow would call these with or without the help a Connection Manager/Agent to find and bind to it. …… Complex 1-N : 1-N : 1-N EG Sales Order n Source / Table Work Flow, Multiple Tasks, Entities, Sources Multiple Interfaces API, Msg, Services Complex Interactions Request Alert STOP XML

Business Servicing and Data Access
Users Enterprise Services UI Components Enterprise Service Bus UI Controllers Integration Adapters Service Interface and Environment Utilities Environment Managers and Utilities Business Entities Business Tasks Business Workflows We can now dive into the data access and business servicing layers of the application. With the OpenEdge Reference Architecture, it is already assumed that the application will be architected and constructed in layers. In this high-level view, each layer has its own components and architectural layers that ensure the layer is properly constructed and connected with layers above and below. In the case of the Data Access Layers, the key point is that data access needs to be separated architecturally from all use of the data by higher layers. This allows an application to deal with data from a wide variety of sources without business logic or user interface dependencies on the details of the data source. It also allows you to change out one data source for another as requirements change or as you refine or modernize your database definition without the logic or the interface of the application having to be changed. We can think of data sources or Data Stores as being in one of two basic categories. A Managed Data Store is one with a database manager of one kind or another controlling access to the data. The OpenEdge RDBMS is of course our chief example of a managed data store. Because of the tight coupling between the Progress database and application logic written in the 4GL, it is possible to achieve a high degree of flexibility and control of the data in the application. In the Reference Architecture, we deliberately separate the data storage from the application logic, however, so as not to introduce dependencies that can cause problems as the nature of the data changes. However, the ProDataSet object and its Data-Source objects let you define the relationship between the database storage and the internal representation of the data such as most of the work of getting data back and forth is still handled automatically for you, while maintaining the necessary separation and flexibility. Other Managed Data Stores include the Oracle RDBMS and MS SQL/Server, both of which are directly accessible as Data-Source objects using the OpenEdge DataServers. In addition, there are other Managed Data Stores such as ObjectStore that, while not directly mapped to the Data-Source object or to the 4GL< can nonetheless be integrated into an application using a custom data access layer. Data Access Services Persistent Storage Services Managed Data Store Unmanaged Data Store

Business Entities and the Data Access Layers
Service Interface and Environment Utilities Business Workflows Business Tasks Business Entities Alert STOP Data Access Layers DataSet DataSet The Business Entities themselves start with the DataSet definitions that are the internal representation of your business data. To this they add standard access methods for Read and Update operations (CRUD), and the validation logic you need to assure your data integrity in a standard way. You can then extend the API of each Business Entity to provide as many variations of access to the data as you need. As long as you standardize the data access so that all references to the data go through its business entity and use the same DataSet definition, then you can be assured that your validation and other business logic are executed consistently. You also know that if you need to change the data definition and the data access, you need to do this is only one place. Once you’ve defined your business entities, you can provide them with one or multiple user interfaces and interfaces from other programs as well. You can then connect multiple business entities into Business Tasks that define a whole process that may involve multiple steps and decision points, and multiple entities, and into workflows that define the ways in which data flows through your business and your application at the highest levels. Data Store Layer

The ProDataSet: All data for a Business Entity
DataSet dsOrder Order Header Lines Item Inventory 27 1 2 3 So at the base level, the DataSet defines the internal representation of a set of related data, to be used as the basis for a Business Entity.

Data Access Object using a DataSet
dsOrder Data Access Object Attach- Data- Source DataSet dsOrder You then isolate all the logic and definitions that map that DataSet to its Data-Source, whatever that may be. You can then later change the Data-Source without changing anything else outside this layer. The transformation symbol inside the oval represents a Data-Source, which is defined as a separate object from the DataSet it is attached to. Field mapping and other transformation logic Data Store

Data Access Object for a Managed Data Store
dsOrder Data Access Object Attach- Data- Source DataSet dsOrder Let’s work our way up through the levels of a Business Entity. As discussed, it’s important to define the Data Access layer with some independence from the rest of the Business Entity, so that the mapping of source data to internal DataSet is done only once, and can be replaced without disrupting the rest of the application. In the case of a Managed Data Store, the Data-Source object lets you define most of the mapping so that Progress can fill the DataSet for you. You can define your own queries for Progress to use when that’s necessary. The ATTACH-DATA-SOURCE method lets you associate the Data-Source with its DataSet buffer and define the field mapping for any fields with different names. If there are calculated fields or if other special processing is needed, there are FILL events you can attach that logic to. And finally, if some of the methods that make up the Entity’s API need specific queries on the database table(s) to define the selection criteria, you should think of these as part of the Data Access layer as well, since they contain database table and field references that will change if the nature of the data source changes. You can package all of this as its own procedure if you wish, and run the procedure as part of the startup of the Business Entity API. Field mapping and other transformation logic Progress or DataServer database Queries for request methods FILL event logic

Data Access Object for an Unmanaged Data Store
DataSet dsOrder FILL event logic Field mapping and other transformation Queries for request methods dsOrder Data Access Object XML document / Flat file / data stream In the case of an Unmanaged Data Store, there is no Data-Source object to do the work of filling the DataSet tables with the right fields. You have to supply that in the code for the FILL events, to do field mapping and any other transformation logic between the original data source and the DataSet, along with calculated fields. Otherwise your Data Access object can have essentially the same structure as for a Managed Data Store. And that, after all, is the point – that the upper levels of the application shouldn’t be aware of the nature of the data underneath.

Eg Loan Applic, Job, Service
Business Entity NOUNS: Orders, Request Mgmt Eg Loan Applic, Job, Service BE_Order.p VERBS: Accept/Update Order, Close Down Job Create / Read / Update / Delete Interface Data Access Object DataSet dsOrder Validation and Business Logic Queries ttOrder FILL ttOline Order OLine You then wrap the Data Access Object in the API for all of the read and update methods, along with whatever logic you need to support those methods. This makes your Business Entity.

Business Entities without DataSets
A Business Entity need not contain a DataSet at all Its API could directly reference an XML document or other data source where transformation to a DataSet isn’t appropriate The API and its behavior makes it a Business Entity, not the DataSet itself

Entities in Context of Business Processing
Business Entities Basic Entity Methods and Entity Representation Tasks utilize Entity Methods to perform their work Services and workflows string together tasks to perform complex operations Business Entities Business Tasks Business Workflows Bus Entity Bus Task Service 1 2 3 4 Data Access Services Persistent Storage Services So the Business Entity can support simple nouns or complex ones. It can support simple CRUD operations or complex data retrievals involving specific selection criteria and many calculations, or updates that have specific validation for every field and checks between every level of data managed by the entity. When multiple steps in a process require the application to keep track of context from one step to the next, and to make decisions about the nature of the next step, then that logic is better represented as a Business Task. Order Entry might be a task, in that, while it is generally carried out and completed at one time, it requires the use of a number of different Entities and perhaps even external services to complete the job. A Credit Check might require a call to a service from a completely independent service provider such as a credit agency. A price calculation could require a call to a complex set of calculations that are defined independent of the different places in the application that use them. In between these steps, the application has to keep track of where it’s at in the sequence of events, and what the data is that the user is entering or using. These different entity methods and service calls together can make up a task. Your application can also string together a series of Tasks to perform even more complex operations that we call Workflows. There is perhaps no strict boundary between a task and a workflow, but a good way to think about it is that a workflow may have control transfer points where one integrated task is complete and then responsibility for continuing the workflow is either done at a later time or perhaps transferred to a completely different area of responsibility. The steps of initially entering an order, processing and approving the order, and finally confirming shipment of the order may take place over an extended period of time and be done by different people. There may also be more basic decision points within the workflow that determine what the next task is going to be, whether it is going to take place or not, whether all the prerequisites are in place for the next task, whose queue it should go onto, what its priority is, and so forth. This all means a more persistent store for context information such as Order Status, and a more specific rule-based decision-making process that determines the sequence of events. Tasks and Workflows are explained in more detail in a separate presentation.

Business Tasks Finer-grained in nature
Key characteristics Business Tasks Finer-grained in nature Typically, does not maintain state beyond invocation Can be invoked By presentation components (tightly coupled) Through service interface layer (loosely coupled) By other business tasks By internal or externally controlled workflow managers May do some boundary checking Shields presentation layers from data access and vice versa “state” is not maintained after invocation, but is likely to be moved on from task to task… (ie the state of the entity will change, ie empty to filled.. etc…) Boundary checking – ie is order open to be closed etc

Entities and Tasks Validate Enter Customer Order Customer Entity
Entry Task Validate Customer if ? then Agreement Enter Order if ? then Customer Entity Order Entity Agreement Confirm Inventory if ? then Agreement Calculate Price if ? then The Entities can then be used to build up tasks that use multiple Entities and represent a controlled sequence of events with context maintained and decision points along the way. Inventory Entity Pricing Entity Context

Introduction to Workflow
What is workflow? Business Workflows Alert STOP “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant* to another for action, according to a set of procedural rules.” * participant = resource (human or machine) What is Workflow? Put simply - Work Flow is the automation of a business process according to a set of business rules. It can involve passing information between machines and/or humans. The Extended Definition comes from WARIA – Workflow and Re-Engineering International Association. What is a Business Task? A Logical step within the work flow is known as an activity/task. Several coordinated activities form a plan or an itinerary. The Workflow Management Coalition

Workflow Manages a business process with multiple tasks
Key characteristics Business Workflows Alert STOP Manages a business process with multiple tasks Maintains the state of the business process May invoke compensating transactions, and/or alert users of exceptions Exposes an interface to receive, and service, business events Documents, information or commands passed from one participant to another in a way that is governed by business rules May control, measure, and report timing & workload Lets look at business workflow and business tasks, what they are and how they differ. Business Workflow components – co-ordinate a set of business tasks (activities) using defined business rules to complete a part or whole of a Business Transaction. Workflows Systems and components - - Needs access to a decision making engine based on Business Rules or has decision making/rules built in. - Usually needs to maintain, store and report the state of the long running Business Transaction/Sub-Transactions, as well as the parts that make it up ie Business Entities. - May be fully automated or Interact with UI/Visual Components to get User input eg authorization, missing context/information - Know how to handle exceptions either by notifying a user, sending a rejection or failure message, or processing compensating transactions.

Tasks and Workflows Order Processing Workflow Context Context Store
Alert STOP Order Processing Workflow Order Entry Task Order Approve Order Ship Task Task if ? then if ? then Context Finally, when your tasks grow large enough that control completely passes from one part of the application to another, you can assemble your tasks into workflows. Status and other context is represented persistently for later analysis of the state of the objects the workflow is managing. Decision logic can provide the flexibility to determine which tasks are executed, in what order, by whom, and with what constraints and other guiding rules. Context Store

Business Servicing Layers
Working with Data Sets Users Present Presentation Layer/s Filter/View Cache Transport Business Servicing Layers There is a parallel between how the presentation layers work and interact and how the business service layers work and interact. This parallel is easiest to understand if we look at each and how the work with data. Starting at the bottom, data is stored in a database. In relational databases, this information is stored row-by-row, table-by-table. The storage schema is impacted by the relationship between these various rows and tables, but doesn’t truly represent it. Traditional access methods – find and for each in Progress, select in SQL – does not inherently represent the complex nature of this data. The most basic elements of the business servicing layer is responsible for reconstructing the complex data object from the underlying physical flattened storage. The result is a complex data object called a ‘dataset’. This dataset represents the data including all calculations, access rules, and relationships that are a natural part of that data object. As an example, think of a sales order. The order itself is complex document that includes data about the customer, the order, the individual line items and products, and related data and rules about tax, credit, and other supporting information. In a database, this information is broken down and stored as single-keyed unique rows in tables designed to hide the overall complexity of the object. This data is then streamed, in one format or another, back and forth to the other application layers. The conversion of the data from complex object to serial streams is usually invisible to the programmer and to the user. This streaming is more a function of the transport requirements then any specific requirements of the platform. Once on the presentation side, the information is reconstructed and often cached for easy use in the higher layers of the presentation layer. Depending on the technology and the programming technique, this data is then further filtered and formatted for direct interaction with the user through common visualization techniques, including viewers and browsers. The important aspect of this is in the duplicate view of the information on the presentation and business service layers. The complex data object – the dataset – is the common element between the two layers. As such, its definition is an important part of the ‘contract’ between the user interface and the business logic. Later, we’ll look at the task definition that forms the other part of this contract. It is important to understand the balance that goes into the design and definition of the business object. To one extent or another, the server-side object mirrors the most common usage of the object in user interface and integration layers. If the business object does not resemble common usage, then the presentation layer and the integration layer will be required to do too much work and will wind up with too much embedded business logic. This leads to destabilization and inconsistencies in the application. On the other hand, if the business service data object is a complete slave to the interface object, then there is little opportunity for re-use and the number of business objects in the application will skyrocket. It stands to reason, then, that the contract between business service, integration, and user interface layers is a prime element in determining the success or failure of the application project. Derive / Calc Form Relationships Database/s

DataSet Read / Update Layer
Client data requests / changes User Interface Data Transfer Create / Read / Update / Delete Interface Data Access Object DataSet dsOrder Validation and Business Logic Here is the complete basic Entity. Around the Data Access definitions and logic you’ve built an interface for the basic actions you need to perform through the Entity, reading and writing data to and from the data source. At this level the API can be fairly standardized, and there should be a template for both the API for CRUD operations and the hooks for validation logic underneath. The user interface, or any other part of the application that needs the entity’s data, uses its API to access it in a consistent way. Queries FILL

Complete Business Entity
Client data requests / changes Order Entity Specialized API CRUD Interface Specialized Access / Update Methods Data Access Object This slide illustrates that you go far beyond the default CRUD API and still be within the confines of a single Business Entity. There can be specialized API calls on both the read and write sides of the data management. Retrieving header summary data for browsing as opposed to all detail for a single header is one example of how the API can be specialized. Input parameters can specify how to filter the data, which levels to return, how many rows to return at a time in cases that require batching, which fields from which tables are needed, and so forth. On the update side, there may be a need for special calls when a complex object is first created as opposed to when it is being maintained, or when mass changes need to be made to a set of related rows. As long as these actions can be made in a single request to a single Business Entity, they can properly be defined as part of the Entity. When they span multiple requests or multiple Entities, then they should be organized at a higher level as part of a Business Task. DataSet dsOrder Validation and Business Logic

Entity with Multiple DataSets
Client data requests / changes API Many variations are possible. For example, there is no reason why a Business Entity can’t contain multiple DataSets. Each DataSet may be used in its own Entity, for example, but be combined with another Entity to handle special logic that requires both of them. In cases such as this, it’s important not to duplicate Data Access logic or Business Logic. You can run the same supporting procedures from both entities, and you can define separate logic for them if they’re used in different situations. Data Access Object Data Access Object DataSet dsInventory DataSet dsOrder Validation and Business Logic

Interaction Between Entities
Business Logic DataSet dsOrder Data Access Object API Order Entity Likewise, sometimes one Entity needs to refer to data managed by another. One Entity should normally use the public API of another Entity to access its data, so that the unity of the data definitions is preserved. Inevitably, there will be cases where this is unacceptably expensive, and some level of compromise may be necessary. One approach in the case of a Managed Data Store is to segregate all direct database access from one entity’s data to another in the database triggers, which by their nature access the database directly, and can do a CAN-FIND on a related table much more efficiently that executing a FIND method on a DataSet. In the case of unmanaged data, you will likely have little choice except to go through the Entity for all access, and in this case it is a good thing, as the complication of accessing unmanaged data from many parts of the application is something you definitely want to avoid. Logic DataSet dsInv DAO API Inventory Entity Logic DataSet dsCust DAO API Customer Entity

Delivering Service Session/Context Transaction Security Customers
(Service requesters) Users Enterprise Services Session/Context Transaction Security GUI Desktop Web Service Message Based Service We will start by turning a set of Business Tasks into set of Services. First we will define an Order Service that groups 3 tasks: - New Order - Cancel Order - Check Order Status [Think of three methods or internal procedures within a persistent procedure.] The Service must run in a service container eg an AppServer Session. We want to make the Order Service available to a wide variety of Consumers eg Direct Customers, Distributors and Internal Call Centre Staff. [ie anyone we can get to buy our stuff] We do this by exposing the Order Service through one or more Service Interfaces. To cater for the difference requirements of the consumers we will support 3 types of interfaces – A GUI Desktop Service (for call centre staff) A Web Service (Direct Customers) A Message-Based Service (For Distributors). We do not want the Order Service to have to deal with the differences in the way the service requests arrive, security or the technologies involved. We just want the Order Service to handle order processing logic. This will make it re-usable when new or extra service interface types need to be supported. The consumer needs to have some a way to find our service …. The Same Services and Service Container can expose DIFFERENT Service Interfaces. Service Container Order Service New Order Cancel Order Check Order Status

Container Managed – Support Services
Presentation Container Security Transaction Control Session/Context Management Client Side Fn() Service Proxy Service Container Service Interface Order Mgmt Server Side …

Session Startup Example
startup.p Initialize Session (paths, etc.) Session Configuration Manager Process Bootstrap Configuration File & Set Session Parameters Connection Manager Connect to Appserver, DB’s, etc. Start Managers Referential Integrity Manager Session Runtime Manager Utility Manager Security Managers Repository Managers Personalization Manager Launch Startup UI Localization Manager Customization Manager Cache Manager Authenticate User, Establish Context, Apply Profile Data Pass Control Back to User

Presentation Container
GUI Rendering Example 1 Presentation Container Session Runtime Manager GUI Rendering Engines Repository Manager Localization Manager Security Manager Personalization Manager Customization Manager Cache Manager

GUI Rendering Example 2 Presentation Container Session Runtime Manager Repository Manager GUI Rendering Engines Cache Manager Service Proxy Service Container Repository Manager Localization Manager Security Manager Personalization Manager Customization Manager Cache Manager

GUI Rendering Example 3 Presentation Container Session Runtime Manager Repository Manager GUI Rendering Engines Cache Manager Service Proxy Service Container Repository Manager Localization Manager Security Manager Personalization Manager Customization Manager Cache Manager

WEB Rendering Example Presentation Container Service Container WEB Request Manager WEB UI Manager Security Manager Session Runtime Manager Repository Manager Localization Manager Personalization Manager Customization Manager Cache Manager

Agenda The Challenge The Architecture Future Model A Methodology Conclusions

How do you Transform an Application?
Just start coding, right? Legacy Application Modern Application

problems of the present with the solutions that produced them.”
Words of Wisdom Its a different world “You cannot solve the problems of the present with the solutions that produced them.” Take the time to decide what you need – not what you already have Assess honestly which parts of your DB and application can be salvaged And which will really benefit from redesign Be realistic about time frames and goals You won’t rework a major app in a few weeks Balance a step-wise progression against the benefits of a complete redesign Take advantage of advances in language and tools Consider the big picture - It’s not only Progress Einstein

Plan / Methodology for Change
Abstract Concrete Older App Modernized App Logical Design Physical Design Implementation Deployment Conceptual Context Analyze & Model Redesign Harvest Build & Test

Where to Start Breaking down the job of modernising
Human Interaction Menu List Maintenance Enquiry Reports Transactions Sys Admin Functional Groups Menu Hierarchy Job Control/Monitor Automated / Background System Integration Imports / Exports Extracts Document/Message/ Socket-based Reporting /BI / Warehouse Data Sources / Storage DB Schema DB’s / Areas Tables Fields Indexes Sequences etc Views Access Permissions Stored Proc’s etc Subjects (Nouns) Eg Customer’s, Patient’s Current State Actions Performed Transaction Tables Event History Tables WFlow / Processes Business Tasks Service Sets / Modules

Moving Forward - Evolutionary
Directions for your Application Architecture Better Separation into Business Logic components Independent User Interface Control Components Expose Business Functions for Reuse Select Standards Based Service Adapters Expose Business Functions as Services Use a Service Bus for Enterprise Integration Form new Solutions from Collaborative Components Integrate with real-time monitoring s/w 1. First, we need IT systems that quickly adapt to the changes we make in the business. 2. Then we need to improve sales productivity by putting the right information in the hands of the sales reps. 3. At corporate, we need to know exactly what we have, where we have it, what it cost, and when we can deliver. 4. Finally, we’ve gotta move quickly. We need to acquire competitors and integrate their business with our own.

Agenda The Challenge The Architecture Future Model A Methodology Conclusions

OpenEdge Reference Architecture is:
Conceptual Guide / Roadmap Combines latest Industry, Progress and Community Best Practice Links to Reference Models and Patters Scenarios and Use Cases Transformation Methodology Common Vocabulary for discussion Technology Aware, but not dependent The reference architecture provides a conceptual guidebook / roadmap covering a broad range of concepts. It includes the latest industry, Progress and Progress Community thinking. Provides a conceptual starting point from which more levels of detail can be introduced such as models, patters, methods, use cases Common vocabulary so everyone can collaborate to develop the best solution. Provides Guidelines that can be tailored to specific Solutions Is Technology Aware but not dependent. Progress OpenEdge and a range of other technologies can be incorporated to implement the solution. Obviously OpenEdge is the preferred / best platform.

Next Steps Learn modern techniques Assess your situation
Business Environment Architecture/ Technical Capability Define the Target Plan the roadmap Execute

Leading to Higher Productivity! Leading to Streamlined Operations!
Achieving your Goals The OERA enables you to … Deliver a Compelling User Experience The Application has Sizzle Support Integration Everywhere Advanced Integration and Collaboration Remain Agile and Enhance Customer Value Easy to Add New Applications, Features and Functionality Provide Distributed Access Logic Access from All Points and Technologies Globally Scale with Best of Breed Applications Grow with an Intelligent Component-Based System 1. Compelling User Interface UI Appearance / Presentation (WOW Factor) Conformance with Surrounding Desktop (Meets User Expectations) High Usability and High Sellability (Sizzle UI pertains mainly to prospects) 2. Customizable User Interfaces User Reporting User customized/personalized access to Data/selection of report presentation, timing etc Personalization lowers customization requirements and demonstrates ‘fit’ 3. Handling Multiple UI’s and Technology Choices Easier to adapt to changing and evolving UI technologies and methodologies Ability to more easily meet requirements of different prospects / customers Ability to more easily adapt business process to different types of users 4. Disconnected / Remote Access Performance Select UI Technologies more easily adapt to remote access Well architected and constructed UI’s schemes make it easier to work disconnected / remote 5. Ease of Deployment and Servicing Smaller, more consistent client footprint when properly architected Fewer changes and problems when UI components are well componentized Adapt to technologies that best fit the deployment / servicing requirements 6. Integrates w/BI, Reporting, Desktop, and Portal Facilities Well layered UI approach is easier to adapt to existing portals and desktop schemes Well componentized UI’s make it easier fit into portals Universal access to desktop, reporting, and desktop facilities 7. Special Needs UI components can be easily translated into special-purpose technologies Controllers make it easier to introduce special requirements with minimum modification Leading to Higher Productivity! Leading to Streamlined Operations! Leading to Competitive Advantage!

Summary Architecture is Good SOA is Future OpenEdge is the Platform Transformation is the Method Progress is the Partner Start Today!

Questions? Paul Petersen Senior Product Manager

Architecting Future Enterprise Applications with Progress

Similar presentations

Presentation on theme: "Architecting Future Enterprise Applications with Progress"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Architecting Future Enterprise Applications with Progress

Similar presentations

Presentation on theme: "Architecting Future Enterprise Applications with Progress"— Presentation transcript:

Similar presentations

About project

Feedback