customer’s background information… The City of Chicago, the third largest in the U.S. serving nearly 3 million residents, has been a BEA customer since 2003. The City of Chicago has a very strong relationship with BEA, to the extent that the CIO has made BEA the de facto standard for SOA and application development, and views the BEA team as a trusted advisor. The mayor is focused on trying to find ways to better serve and respond to the city’s constituents (citizens, employees, vendors of the City), and started a “Transparent Government Initiative” nearly five years ago Because of the need to inter-connect and share data, the Transparent Government Initiative evolved into a SOA strategy for the City of Chicago. customer wanted to… Reduce costs while following through on the Mayor’s mandate to move towards a shared services organization for the entire City government Other city departments and agencies lacked faith in the City of Chicago’s Business and Information Services department (known as BIS, their centralized IT department) – projects coming from BIS were late, over budget and sometimes didn’t work. City departments and agencies stopped going to BIS and were developing applications on their own, causing overspending and much duplication of effort. BIS was also fragmented, with multiple vendor licenses from IBM and Oracle. Generate more revenue for the City in order to fund programs such as housing developments, better schools and programs for the needy, by making it easy for citizens to pay their bills. Several departments shared a common need: to accept payments from citizens and vendors. A payment engine to accept online payments could be easily reused across various city departments, as the backend processes were similar. Re-use applications across the various City departments and simplify their development The City of Chicago was using many different SIs, who were building applications using multiple technologies and languages. The City standardized on Java and BEA, which enabled them to achieve economies of scale and efficiencies in deploying applications. As the City of Chicago scaled their services, their “point-to-point” services became burdensome to change and manage. SOA was appealing to the City of Chicago primarily because of its reusability, which would lower costs, and allow them to share services across agencies and departments.
Starting with Point-to-Point Services Another prevalent scenario is that a customer has started experimenting with service technology approaches, primarily web services, and has realized that every time a service changes, either in interface or data, that all consumers of a service must be updated. This creates a situation of coupling where incremental changes in a service result in required updates to all use of the service Stage 1: Isolation, Isolation, Isolation In this stage, the effect of the coupling that is tight between the consumers and producers of services is creating more pain than the advantage provide by using a service-based approach. With this in mind, a customer would look to the introduction of AquaLogic Service Bus (ALSB) to create an initial bus segment through which to provide isolation and ultimately abstraction between the service consumer and producer. The Service Bus segment allows service provides to evolve without the need to update service consumers by abstracting the interaction paradigm and transport of the service provider away. In addition, the Service Bus segment also provides the ability to introduce both lightweight and heavyweight data transformations and augmentations without the need to update the consumer, thus allowing for evolution of the data model used by the enterprise. Stage 2: Where are my Services In this stage, the customer discovers that services have begun to proliferate and is now having difficulty locating the services that are being hosted throughout the enterprise and exposed through the Service Bus segment. In addition, the service consumers are connecting to the service proxies hosted in the bus and thus must know the location of each proxy. To address this need, a customer would typically turn to the AquaLogic Service Registry (ALSR) as a means to locate the vast services available for use in production environments and to hide the existence of the Service Bus segment from the developers of service consumers. This is because the integration between the Service Bus segment and the Service Registry abstracts the service proxies away so that service consumers believe that are accessing the service providers directly without knowledge of the existence of the Service Bus segment itself. In addition, customers would begin to look at the Service Registry as the foundation of a governance policy. At this stage in the evolution of a SOA approach, the Service Registry not only takes on the task of being the location service which is consulted by consuming applications needing to locate the existence and location of a service, but also a the location where additional information about the service, such as SLA statements, dependencies, etc can be found. Although the Service Registry is ill equipped to handle all of the future needs, unlike a meta-data repository, its often used to boot strap a more formal governance process. Stage 3: Orchestrate Human and System Activities within a Business Process At this stage, the customer now has the basis to introduce new services into the environment to allow the orchestration or processes and creation of new composite applications. Of particular interest to business-oriented user community is the ability to create new applications more quickly.
Starting with a Portal One of the most prevalent scenarios is where a customer has started with some presentation aspect, typically a portal, and is trying to figure out how to move from that point into SOA. This is a very common scenario in a number of commercial markets where people have started to perform initial integration through the use of a portal that provides a common presentation of a concept such as customer, order, and the like. Stage 1: Introduction of Information Services In this stage, the customer comes to the realization that although the presentation technology such as portals allows them to encapsulate logic into portlets that can be utilized in separate portals, the logic which understands how to create that common view of some type of information isn't shareable except to other portals as presentation. In addition, each time the portlet which creates the common view is updated, it is very likely that every portal will need to be updated to take advantage of this information. This is especially true if the customer has multiple presentation environments supporting multiple different programming languages. While a federated portal scheme could be used to address the sharing of the presentation aspects, it doesn't provide any solution to the issue of sharing the information itself, without presentation, to other applications. To address the sharing amongst both presentation technologies and applications, a customer would typically turn to creating data services which would expose the common view of information as one or more services. Here, AquaLogic Data Services Platform (ALDSP) can be utilized to automate the tedious task of hand-creating the code needed to interact with various data sources, including SQL, web services and others, to create the common or unified view of information such as customer, order, etc. In addition to exposing the common view of information as a programming object, Data Services Platform provides a means to compose these newly exposed services as web services, allowing them to be composed into higher level capabilities transforming data into information and information into knowledge. Stage 2: Where are my Services In this stage, the customer discovers that services have begun to proliferate and is now having difficulty locating the services that are being hosted throughout the enterprise. This is especially true with number of information services that are popping up as various project utilize existing services, expose new services, and are now beginning to expose the first set of composite services. These initial composite services come about as the information services introduced in the first phase become part of a larger service as well as take on presentation aspects via techniques such as WS-RP. To address this need, a customer would typically turn to the AquaLogic Service Registry (ALSR) as a means to locate the vast services available for use in production environments. In addition, customers would begin to look at the Service Registry as the foundation of a governance policy. At this stage in the evolution of a SOA approach, the Service Registry not only takes on the task of being the location service which is consulted by consuming applications needing to locate the existence and location of a service, but also a the location where additional information about the service, such as SLA statements, dependencies, etc can be found. Although the Service Registry is ill equipped to handle all of the future needs, unlike a meta-data repository, its often used to boot strap a more formal governance process. Stage 3: Change - Adapt or fall Victim At this stage, customers are beginning to feel the pain of an ever proliferating set of services that are being composed together to create new applications without a complete understanding of the issues concerning coupling between services that they are creating. None of the changes looms as ominous as the realization that the information and data services exposed in the early stage are now beginning to change and the point-to-point connections made between the services must now be re-coded to introduce either new versions of services, required transformations of data, or ever changing business processes to meet business or mission goals. Addressing the issues of coupling, as a result of point-to-point communication, and just general evolution of an application is the AquaLogic Service Bus (ALSB). The Service Bus provides the abstraction and isolation infrastructure to allow changes in service providers, injection of data transformation, and changes in business processes to be a removed from service consumers. If a composite application is built to obtain the location of services from a Service Registry integrated with the Service Bus, it is possible that the introduction of a Service Bus segment can be an administrative exercise that does not require changes in either the service consumer or service producer. In addition, the pipeline capabilities in the Service Bus segment can be used to relieve the burden of exception handling, retry, and other low-level aspects that can make a service consumer tightly coupled to the service producer.
customer’s background information… Pacific Gas & Electric (PG&E), one of the world’s largest utilities, based in San Francisco, generates, distributes, and sells gas and electricity services to approximately 5 million customers in California. PG&E has been a BEA customer since late 2000 and the relationship has grown from a tactical one to a more strategic relationship over time. Partial deregulation in the retail gas and electricity industries caused problems for PG&E in recent years – they struggled with paying high prices for fuel supplies while their revenue was limited by CPUC which set the rate they could charge consumers. PG&E recently emerged from bankruptcy due in part to the partial de-regulation policies of the CA state legislature and CPUC. PG&E brought in a new executive management team in 2004 with ambitious goals to restore PG&E’s leadership position in customer service, operational efficiency customer wanted to… Improve customer satisfaction, business efficiency, safety and innovation while “keeping the lights on” for California. Restore PG&E’s leadership position and become a major global player in the consolidating utility industry Initiate a business transformation and, with Accenture’s assistance, identify critical areas needing focus to become a world class utility. Take a broad look from end-to-end: across generation, distribution, transmission, operations, retail, sales, and all other aspects of the business, for areas needing improvement. The focus on an IT Transformation was one of the top two critical areas identified by Accenture for successful execution of PG&E’s Business Transformation (the other was an HR Transformation) Overhaul PG&E’s IT approach to systems, information, and processes. Improve IT responsiveness to business and decrease time to market. IT transformation is what opened the door for SOA.
The domains and the challenges they address include: Business Strategy and Process: Companies need IT implementations that support the business and its changing needs. This domain provides an environment that links the management and measurement of IT with the business strategy. Architecture: Nearly all enterprises fund and build IT by projects in lines of business, leaving enterprise-wide processes and integration to be considered as afterthoughts and creating barriers to change. This domain helps companies build and IT environment based on standards, distribution, loose coupling and business process representation that is designed to respond to change and integrate functionality at the enterprise level. Building Blocks: A lack of consistency and repeatability in IT implementation hinders most enterprises in achieving their goals with respect to IT budgets and agility. This domain offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximizing the ability to repeat successes by reusing implementations and the core infrastructure. Projects and Applications: IT is traditionally developed by projects within lines of business – often creating excessive capital spending on duplicate functionality and compromising the integrity of enterprise processes. This domain helps companies catalog, categorize, and re-factor functionality offered by systems and applications – standardizing the manner in which that functionality is offered, while reducing redundancy and promoting consistency in execution. Organization and Governance: The organic growth of enterprises yields an IT infrastructure that is difficult and costly to change. This domain concentrates on creating an organizational structure and mandate to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimize IT utility.
Briefing Notes - BEA SOA Readiness Assessment Tool BEA introduced the SOA Readiness Assessment Tool in August of 2004. As of January 05, over 500 accounts have taken the assessment. The tool was developed as a collaborative effort by BEA Consulting, IT, Engineering organizations and allows clients through a series of questions to gage their SOA Adoption and Maturity. The BEA SOA Maturity Matrix and six key domain areas are the foundation of the tool and highlight BEA’s approach to SOA adoption and organize the Assessment questions. At the conclusion of the assessment the customer submits their responses and receives a customized SOA Readiness Benchmark report. The report provides the respondent with their scoring for each domain, comparative scores for all respondents who have participated in the Assessment, a Profile that outlines their SOA Maturity for each of the domain areas as well as some practical suggestions on improving their SOA Maturity. Early Findings/Key take aways: 1. Respondents Familiarity with SOA is low, we are seeing an average rating of 1.71 on a scale of 1-4 2. Respondents clearly see the Business Importance of SOA, we are seeing an average rating of 2.71 on a scale of 1-3. 3. Respondents clearly see the IT Benefits of SOA, we are seeing an average 2.67 rating of a scale of 1-3. 4. Respondents see their SOA proficiency as low averaging a score of 1.77 on scales ranging from 1-3 to 1-5. Some highlights: Introduced in August of 2004 Available in US, UK English, French, Spanish, Italian, German, Chinese, Korean, Japanese and shortly Portuguese Predominantly North America and European participation to date, Asia and South America are starting to introduce the tool in Q1. The tool has been “federalized” for our Federal Government Clients Over the 5 month period over 500 accounts have participated Prominent industries represented o Transportation o Computer HW/SW o Healthcare o Telecom o Finance o Banking o Education o Government o Insurance o Manufacturing Participants thus far: o 64% from America’s o 36% from Europe and Asia Pacific o Make up of Participants 18% C-Level Executives 5% Vice President 11% Director 16% Manager Level 28% Architect 3% Systems Analyst 3% Developer 16% Other Industries that appear to rate themselves with a higher level of maturity and adoption are Transportation, Computer HW/SW, Healthcare Telecom and Finance. Lower adoption appears to be in Banking, Education, Government, Insurance and Manufacturing. Senior Management consistently rate their organizations at a higher maturity/readiness state then Architects, Developers etc. BEA SOA DOMAIN AREA’S ARE: Business Process and Strategy Architecture Building Blocks Projects and Applications Cost and Benefits Organization and Governance
Accelerating Your SOA Implementation Bruce Graham SVP, Worldwide Consulting SOA Global Practice Lead BEA Systems
The Debate Is Over: A New Approach For Delivering IT Applications Has Been Embraced Presentation Services Shared Business Services Information and Access Services Services Management Service Bus Common Services Service Infrastructure Layer Sales B2E Engineering B2C Service Partners Customers Composite Applications Enterprise Information Systems Data and Middleware Custom Applications Third Party Products (Erp, CRM, etc.) Databases MiddleWare Interactions (TUXEDO, MQ Series,ect.) “ Role-based” Composite Applications… … connect to business services, built and managed with an integrated suite on open standards, with supporting infrastructure… … using content from “Vanilla” ERP and legacy applications Non-Functional Requirements Standards Development Tools Configuration Management System Management Network Management Provisioning Business Activity Monitoring Directories Patterns
SOA Is A Top Priority For Companies Over the Next 12 Months Q: As An IT Priority For the Next 12 Months, Where Is SOA On Your Company’s Radar Screen? As An IT Priority For the Next 12 Months, Where Is SOA On Your Company’s Radar Screen? 2006 2005
Companies Are Moving Forward Now With SOA 56 % of Companies Are Now In the Project Stage Q: What Stage Is Your Company Currently In With Respect to SOA? Don't Know Not Planning to Deploy Evaluation Pilot Projects Department-wide SOA Enterprise-wide SOA Only 19% of Companies Are Not Participating vs 53% in 2005 32% 21% 20% 13% 4% 8% 12% 7% 25% 28% 12% 16% 2005 2006
SOA Is A Significant Budget Item Q: How much does your company expect to spend on SOA in the next 12 months? Mean amount budgeted for SOA = $2.1 million 41% will spend $500K or more Less than $100K $100K-$499K $500K-$999K $1 million + 2006 2005
The Enterprise Software Landscape Is Changing “ It seems that if SOA really takes over, the software that links applications together , rather than the applications themselves, will become the most important strategic decision that CIOs make.” - Christopher Koch Executive Editor, CIO Magazine February 2006
The “Enablers” Are The Thought Leaders In SOA Today Q: Which of the following companies are SOA thought leaders? 14% 15% 20% 20% 24% 33% 38% 40% 62% 74% Systinet SAP webMethods Sonic Tibco Sun Microsystems Oracle Microsoft IBM BEA Systems
Desire to better serve the City constituents through online services
“ Make Payment” identified as a reusable service
Architect working in a central group
Process Projects Phase 1: Basic Payment Engine Client Portal Application Presentation Layer Business Layer User Interface Composite Processes Reusable Business Services Legacy Svcs & Adapters SMTP Server Payment Processor Cyber Source Cybersource Adapter Email Services Merchant Payment Service Notification Services Validation Services Addn’l Fee Service Make Payment Biz Taxes Specific UI Sticker App Specific UI Water App Specific UI
Process Approach Phase 3: Production Client Portal Application Presentation Layer Business Layer User Interface Composite Processes Reusable Business Services Portlets Legacy Svcs & Adapters SMTP Server Bank X A/R DB Payment Processor Cyber Source Cybersource Adapter Account Services Large Payment Adapter Email Services Merchant Payment Service Notification Services Validation Services Addn’l Fee Service A/R Update Services Make Payment Biz Taxes Specific UI
Process Projects Phase 4: “Service Orienting” The Portfolio Account Management Processes… Presentation Layer Business Layer User Interface Composite Processes Business Services Online Payment Portal Portlets Other Portals Department Specific Portals SMTP Server Ext App DB CDB Legacy Systems SSO/ LDAP Content Mgmt System Ext App Services CDB Services 311, ECM GIS, etc. Services Audit Services Addn’l Fee Service Validation Services Email Services Merchant Payment Service Account Update Services Various Business Services Make Payment Process Orchestration Create Account Update Account Remove Account Get History Link Account Shopping Cart Portlet Account History Portlet Account Mgmt Portlet Generic Payment Portlet User Profile Portlet Product Browsing Portlet Content Portlets External App Specific UI Sticker App Specific UI Legacy Svcs & Adapters Cybersource Adapter Payment Processor Cyber Source Framework Services (User/Acct/App/ Dept/Merchant…) Water App Specific UI Biz Taxes UI
SOA Starting Point: The IT Project IT-Led Projects Business Sponsorship High Low Low High SOA Complexity Process Projects Mega Projects Business-Led Projects
Active SOA development within the enterprise
Challenged with scale, and consistency
No overarching plan, but budgets exist
Focus on infrastructure services
Begin the creation of an Enterprise Reference Architecture
Develop a multi-period road map
IT-Led SOA: Starting From Point-to-Point Services
Scenario : Actively deploying web services, initially connected in a point-to-point configuration
Initial Challenge : Isolate and abstract service producers from service consumers
Stage 2 Deploy a Service Registry to provide visibility into existing services, promote reuse, and govern provisioning Stage 3 Deploy a Business Interaction Service to orchestrate human and system activities within a business process, interacting with services Stage 1 Introduce Service Bus to create an initial bus segment isolating producers from consumers
IT-Led SOA: Starting From a “Hard-wired” Portal
Scenario : Access to Legacy Systems are “hard-wired” to Portals
Initial Challenge : De-coupling information integration logic from the presentation layer
Stage 1 Deploy Data Services Platform to service enable enterprise data (e.g. create and expose common views of key information) Stage 2 Deploy a Service Registry to provide visibility into existing services, promote reuse, and govern provisioning Stage 3 As information services created in Stage 1 begin to change, Implement a Service Bus for isolation & abstraction
AquaLogic™ Product Family Service Infrastructure : Cross-Platform, LOB/IT, Composition-based Process Orchestration User Interaction Security Services Data and Information Services Message Services Integrated Composition Environment Business Process Management Business Rules Enterprise Connectivity Business Activity Management Portal Multi-channel Collaboration Interaction Management Federated Identity Management Distributed Application Security Management Business Intelligence Composite Data Management Unified Meta Data Repository Unified Data Modeling Service Manager Message Management Service Registry Compose Preview Monitor Update AquaLogic User Interaction AquaLogic Business Service Interaction AquaLogic Security AquaLogic Data AquaLogic Messaging Composer
Plan For SOA In Multiple Dimensions The BEA SOA Domain Model
Business Strategy & Process Architecture Costs & Benefits Projects & Applications Building Blocks Organization & Governance Projects and Applications Business Strategy and Process Architecture Costs & Benefits Building Blocks Organization & Governance
Baseline Your SOA Maturity: The BEA SOA Readiness Self-Assessment
Web Based Assessment Tool
Over 3000 companies to date
Foundation of the tool is the BEA Domain and Maturity Model
Provides a customized report automatically sent to client within 24 hours
Customized URL can be established to enable an intra-company baseline
Available in 10 languages
New BEA SOA Offerings Address Key SOA Challenges Organization & Governance Planning Service Over 50% state Organization & Governance as top inhibitor
Top challenge: Developing Effective SOA Governance Approaches
Enterprise-wide SOA deployments double driving Architecture Services
Top criteria: Real-world SOA expertise and enterprise experience
SOA Center of Excellence Client Architect Transformation Planning Service Trend 95% understand Service Infrastructure & Prioritize technology spend
Top Pain: Flexibility and Integration
Issue Reference Architecture Planning Service SOA Integration Service New Services Offering
New BEA SOA Offerings Address Key SOA Challenges Organization & Governance Planning Service Our team of SOA experts collaborate with you to produce an effective and pragmatic SOA Organization and Governance roadmap to be implemented in your organization Over 50% state Organization & Governance as top inhibitor
Top challenge: Developing Effective SOA Governance Approaches
Trend 95% understand Service Infrastructure & Prioritize technology spend
Top Pain: Flexibility and Integration
Issue Reference Architecture Planning Service SOA Integration Service New Services Offering
Objective and Benefits BEA SOA O&G Planning Service (OGPS)
Benefits of OGPS
At the conclusion of OGPS you will have answers to your key SOA O&G FAQs, and be able to decide upon, institute and enhance processes for them
Example SOA FAQs include:
What are my SOA objectives and what benefits do I expect from SOA?
What kind of SOA organization do I need?
How will the service lifecycle be managed?
How will SOA reference architecture and infrastructure be managed?
What services infrastructure do I need and how and when should I deploy it to facilitate SOA O&G?