VIEWS: 9 PAGES: 31 POSTED ON: 5/29/2010
AT&T SOA Experience Rich Erickson Enterprise SOA Practice Lead Copyright © 2006 AT&T. All rights Reserved. Session Overview Motivation For SOA Context and Terminology SOA Foundation and Fundamental Decision Points AT&T SOA Journey and Progress Summary Page 2 Copyright © 2006 AT&T. All rights Reserved. Motivation For SOA Traditional Interface Development Different project teams create similar interface functionality on the same systems in the same release cycles. Project 1 - Software Parallel Project 2 - Software Development Process Steps teams Development Process Steps 1. Determine conceptual solution 1. Determine conceptual solution including necessary system interfaces Project architects including necessary system interfaces 2. Concept Gate approval without con- specify project- 2. Concept Gate approval without con- sideration of target interfaces or reuse specific interfaces sideration of target interfaces or reuse 3. Prepare Business Reqs with high without trying to 3. Prepare Business Reqs with high level description of interfaces reuse/extend what level description of interfaces exists nor create a 4. Reqs Gate approval with no consider- 4. Reqs Gate approval with no consider- desired target API ation of interface target or reuse ation of interface target or reuse 5. Prepare Tier3 Requirements & IAs 5. Prepare Tier3 Requirements & IAs 6. Commit Gate approval without con- Project teams work 6. Commit Gate approval without con- sideration of interface target or reuse independently with sideration of interface target or reuse 7. Prepare Software Design little collaboration 7. Prepare Software Design 8. Design Gate approval without con- cross-team and 8. Design Gate approval without con- sideration of interface target or reuse end up deploying sideration of interface target or reuse similar interface 9. Implement, Test and Deploy functionality 9. Implement, Test and Deploy Note: Interfaces designed in the fire of project urgency are usually not reusable in Page 4 Copyright © 2006 AT&T. All rights Reserved. different contexts Impact of a SOA Development Process SOA cuts interface cost, complexity and time to market OCTOBER RELEASE VIEW: Sys1 Sys2 Project 1 Sys3 Project 2 Stops development, Sys5 Sys4 test & maintenance of Reduces total new versions of the complexity by same interface Sys6 constraining the functionality across growth of interfaces different projects Project 3 per system Traditional Approach With SOA Development Process Release- Dev Release- Project Interfaces Project Interfaces Dev Relevant Relevant New Extended Reused Total* $ New Extended Reused Total $ Sys1 4 1 0 7 675K Sys1 2 1 2 5 475K Sys2 2 1 0 4 375K Sys2 1 1 1 3 275K Sys3 4 0 0 6 600K Sys3 2 0 2 4 400K Sys4 2 0 0 2 300K Sys4 2 0 0 2 300K Sys5 1 0 0 1 150K Sys5 1 0 0 1 150K Sys6 1 0 0 1 150K S6s6 1 0 0 1 150K * Includes relevant interfaces that could have been reused 2250K 1200K Benefits increase over Cuts development cost time as the library of through interface reuse Page 5 services grows Copyright © 2006 AT&T. All rights Reserved. SOA Case Study By 2005 AT&T had documented over $40 million in savings from SOA, as in this example of a system that accrued $2.6 million in 2 years by reusing one service across 5 clients. Highlights: 2.6M • Reuse of a single service $ Cumulative Savings saved 50%-85% of the cost 2.1M of building custom interfaces. • Savings will continue to accumulate as more clients 1.6M are added. Client 6 • Maintenance costs will be Client lower (not shown) because 1.1M 5 fewer interfaces need to be Client versioned and maintained. 4 525K Client • Operational efficiencies 3 will be higher (not shown) Client Initial 2 because of increased Service consistency across SOA 0K customer/client interfaces. 2003 2005 Year Page 6 Copyright © 2006 AT&T. All rights Reserved. SOA Value to AT&T The SOA benefit model was recast and zeroed out in 2005. It projects additional savings in excess of $100M by 2009. Projected Cumulative SOA ROI SOA Benefit Model: Cumulative SOA ROI ROI w/o SOA • Service reuse contributes an average 50% reduction 250% in integration cost. 200% • Includes engineering 150% efficiencies from use of standards, models and 100% repositories. 50% • Includes development 0% efficiencies from use of 2005 2006 2007 2008 2009 standard integration toolkits -50% • Without SOA costs and -100% $ Represent Cum Net Savings complexity continue to increase. Key Assumptions: Constant annual development budget spend at 2005 levels. Rate of re-use of existing services is approximately 3 times per service during a 10 year period. − Note: The system on the previous slide provided 5 instances of reuse within 2 years SOA adoption rate grows from 25% of projects in 2006 to 90% of projects by 2009. Average overhead to create SOA services for the first time is 10% over the current costs. Cost of a new interface is $(att proprietary) on average. Page 7 Copyright © 2006 AT&T. All rights Reserved. Context and Terminology Page 8 Copyright © 2006 AT&T. All rights Reserved. The Challenge of Realignment SOA is a ‘Realignment’ challenge rather than a ‘Turnaround’ or ‘Startup’ challenge. • Realignments challenge established cultural norms that hamper high performance. – Realignments are important to business success. • But in realignments, the situation is not dire, leading many to feel change is not necessary. – So realignment advocacy is like farming: cultivating awareness of the need for change, influencing opinion leaders, keeping the pressure on. • Unlike startups or turnarounds, the impact of realignment is not always appreciated. – If abandoned, most will not know what could have been. • Major realignments like SOA need strong executive support to overcome inertia and resistance. Page 9 Copyright © 2006 AT&T. All rights Reserved. AT&T Definition of SOA Governance Different definitions of SOA abound Target SOA along with a lot of misinformation. Design To support SOA: A foundation of middleware, taxonomy and naming standards “SOA” is an approach to must be put in place. architecture & solution design which: Target architects & lead engineers must functionally decompose their • Requires architects and enterprise domains & applications engineers to itemize the into a set of highly reusable target services they are creating, services, which solution designers extending or reusing in their can reference in their designs and requirements documents. build out over time. • Brings governance to the treatment and selection of A common misconception is to these services as they flow equate SOA with Web Services or through the software integration technologies like ESBs. development lifecycle. Page 10 Copyright © 2006 AT&T. All rights Reserved. SOA Actors A SOA program needs to successfully engage five teams. STRATEGIC SOA Standards & Tools: Middle- TACTICAL SOA ware, SOA, Naming, Taxonomy Target Architecture: Solution Realization: Executive Target Systems and Project Feature Support Functional APIs Development Specifies target Builds production capabilities to be built capabilities referencing out over time; works the target; specifies with project teams to SOA service impacts in resolve issues solution designs Governance: Project Management & SDLC Page 11 Copyright © 2006 AT&T. All rights Reserved. Strategic and Tactical Aspects SOA has both strategic and tactical aspects resting on a foundation of enterprise standards. Contributor Output Puzzle Analogy Project Specification of Each solution team Tactical Aspect Solution SOA service assembles a few pieces; of SOA Designers impacts in over time they assemble solution designs the whole puzzle. Strategic Aspect Target The „To Be‟ view Definition of the puzzle of SOA Architects of functional to be built out over time, capabilities by including the shape of domain each piece. Foundation of Technical Interoperability Puzzle piece SOA Architects standards, SOA requirements and and SOA tools and governance of the Support governance assembly process. Page 12 Copyright © 2006 AT&T. All rights Reserved. SOA Foundation and Fundamental Decision Points Copyright © 2006 AT&T. All rights Reserved. Strategic SOA: Target Services Strategic SOA is tasked with functionally decomposing the architecture into a set of abstract target services. Sales Sales Decomposition starts by dividing Order Management OM FrameOrder[New|Change|Delete] FrameProvisionProvider[New|Change|Delete] the architecture into domains. FrameFulfillEquipment[New|Change|Delete] Orchestration PM GenericEventListener.notify GenericEventListener.notify OM Working top-down, domain teams Provisioning Management PM Sales PM FrameOrderNew initiate InvSys FrameOrderDataParcel initiate OM FrameProvisionProviderNew initiate FrameFulfillment[New|Change|Delete] FulfillSys define the target services they will Services FrameOrderDataParcel provide to other domains. − Domains expectations must be Provisioning CSI[Query|Insert|Update|Delete] Factory ProvPM FulfillSys NAI[Query|Insert|Update|Delete] Services InvSys FrameProvisionProvider[New|Change|Delete] vetted cross-team. − Service functionality is described Data FrameNumberPortability[New|Change|Delete] InvSys Services B2Bi InvSys Retrieve (Co Provide InvSys abstractly without regard to pro- Contract Account Data (C on tac t #) nta ct D ata ) (Acc ount #, C o Name) Hierarchy tocol or implementation details. OM Configure InvSys The hard work is the mental Solution Premise Eqpt Sales (Account #’s) ( Svc Type, Loc, etc) Provide Svc analysis that must be performed. ( Dates,Availability − Modeling tools can help docu- Routers Availability Activity (AcctK ey#, L OM (Serv oc, Sv ice/Ne c, Serv t twork ice ID Orchestrate ac n Inven ) ntr atio Contract Implementati Co ent Im ple m us (Us ag tory) Provide InvSys Service Inventory ment decisions but are not on tat et d Or de rS (Price) (term/MARC,Offer eta il s)) WT N essential to the actual analysis. Contract ID n Id (SolutionData) OM So lutio ContractData (SolutionId) Provide Usage InvSys Service definitions must extend to Orchestrate Order Store Price Store InvSys the data flowing in/out of opera- tions or the target won‟t be stable Activity Contract Solution Soluti Data InvSys Data on Solution Sys or usable. Page 14 Copyright © 2006 AT&T. All rights Reserved. Data Standardization SOA APIs express an implicit data model, which ideally should be identified to increase the comprehensibility & consistency of service definitions. Enterprise Data Models Target Object Requirements: Product Catalog (PSOC) Customer (CCI & eCRM) Technology for modeling and -CostKey -Status : int -Crea teD ate Cost -Effe ctiveDate : Date -CostRate : Date -Currency 1..* 1..* 0..* Offer -OfferKey -Status : int -OfferName -EffectiveD ate : D ate -End Date : Date -Cre ateD ate 1..* 1..* 1..* 1 ..* C amp aign -C a mpa ig nId A T& T A uthoriz ed Ag ent - Agen tId 0..* 1 - May re sult in -Sig ns for AT & T 0 ..* 0..* C ontrac t -C ontractId 1 1 0..* C ont ract A u thoriz ation - Co ntra ctAu thId describing objects 1 ..* 1 Standards for reuse and 1 -Cost to provide * * * 1 1 * * Product Bundle Payment Ter ms Order/LocationInstructions 0..* Component -Payme ntTermKey Price Plan Proposal Option 0..* Product 1..* -ActivityId -Produ ctComponen tKey -Statu s : int -Pa ymentTermKey * 0..* 1..* * -EffectiveDate : Date 1..* 1..* 1..* -CustomerSiteId Customer Location Customer Site -Produ ctKey -Status : int -Instructions -Sta tus : in t -EndD ate : D ate * * -is part of -CustomerLocationKey 1 -CustomerSiteKey -EffectiveDate -Effective Date -DaysToPay -C reateDate : Da te 0..* 0..* * -CreateDate : Date -CreateD ate * -EndDa te : D ate Discount 1 C ustom er -EndDate : Da te (C on tact) Lea dProject -Produ ctComponen tNa me 1 -De scription -D escriptio n -D iscoun tId Contract -Le adId -ProjectId 0..* 0..* -C C ID 0..* 0..* 1 aggregation of base components -Orderable -Discounts apply to -Sta tus : in t * 0..* B illing A cc ount No de * -H elpLink - -H as pre se nce at -DisplayN ame * -C reateDate 1 ..* * -Version -BillingAc co untId -XMLPath -C lassification -EffectiveDate : Date 1 * -EndDate : Da te 1 -XMLPath 0..* 1 -XPa th 1..* -D iscoun tType (Standard , Grow th, Waiver ,...) 1 -Level (Offer , Product, Prod uct Bundle Gro up , Product Bundle ) 0..1 -Coordinates delivery of Contract * * -Geo graphic Area -GrowthAssessmentBa se Related Solution X -Ref Product Instance Package * 1..* -SolutionId -GrowthAssessmentAmoun tPercentage 1 1 -Located at -Located at 0..* 0..* -Rated at -D iscoun tFre quency -SolutionId2 -D iscoun tC alculationBase -RelationshipType O ffe r -Is pr opo sed for * R atePla n -D iscoun tC alculationMeth od -Sequence -O fferTa g * 1 Component Instance-Sells to * Product Attribute -PricePla nKey -D iscoun tAmountPercentage 0..* -D iscoun tEligibleCharges 1 0..* 1 ..* -is a ss ig ned to 1 How to identify, propose and -Produ ctAttribute Key -Statu s : int 0..* * -EffectiveDate : Da te 1..* 0..* Sales Pers on * -CreateD ate 1 Op portunity 1 -Belongs to 1..* -EndD ate : D ate Solution * 1 -SalesId * * -O pp ortu nityId 1..* -Built from -State -pro posed ,contracted -Is comprised of 1 * -SolutionId 1..* 1 1..* 1 Commitment 0..* * 1 0..* 1 -CommitmentKey 1..* 0..* Produ ct Activity 0..1 0..* Product Instance 0..* -Status : int -Prod uctTag 1 1 * 0..* -Is prop os -ActivityId ed for * -Effe ctiveDate : Da te -Specifies an activity for 1..* -EndD ate : Date approve objects Supplier/C omponent Profile 1..* Supplier -Crea teD ate -SupplierId ProductRate -CommitmentType(Standard, Early Term, Shortfall, ...) Customer Contact Event * -Co mpo nentId -SupplierId -Level(Offer, Pro duct, ...) -EventId 1..* * -Grouped into -ProductRa teKey -Inven toryLevels 1..* 1 -Status : int -Geogra phicArea -Even Type 0..* * 1..* C ustom er related by 1 -Are Lo cation *-has a sso ciate d A ddres s -EffectiveD ate : D ate -Main Commitment 1 -Designed using -Ad dres sId -C ustome rLo cation Id -Cre ate Date -Frequency Solu tion -En dDate : Date -AssessmentBase 1 * -Calcula tionMethod Std Sol Template -So lution Id Group Activity -Type (MR C, NR C, Can celation , Ancillary) -Quantity /R ange -Te rm 1 -ActivityGroupId -Rate -UnitOfMeasure -SolutionTemplate 1* * -EligibleCh arges (N RC, MRC , All, ...) -ActivityGroupType -Currency 0..* -RetireMainCommitment -RetireMainCommitmentCa p Related C us tome r Site Products X -Ref 1 -ProductInstanceId -C us tom erSiteId SOA Service Best Practices: -ProductInstanceId2 -RelationshipType -C harge s used to retired * -Prepared for 1 0..* Related Activities X -Ref 1 -ActivityId 0..* Customer -ActivityId2 -RelationshipType -CCIKey -Sequence Proposal Option Strategy for using complex 1..* Circuit Schema Solution, Order (CSI ) objects in SOA APIs High Level Data Flow Diagrams Strategy for object-agnostic services Data Dictionary: Store and discover target objects Link to SOA Repository operation parameters Document data translations for key applications and flows Page 15 Copyright © 2006 AT&T. All rights Reserved. SOA Framework A SOA framework is used for consistent delivery of SOA services across parallel teams. A SOA Taxonomy divides the enterprise into domains SOA Naming Standards improve service discovery Best Practices provide guidance on service scope Architects specify the „To Be‟ Target View for each domain An Inventory of existing services is performed A SOA Repository captures service definitions online A Solution Design Flowchart specifies how Designers interact with Target Architects A Service Inventory template captures service impacts in SOA Design Templates Page 16 Copyright © 2006 AT&T. All rights Reserved. SOA Tools SOA tools are used to manage adoption, performance & reuse of SOA services, plus compliance with standards A SOA Repository captures service definitions online: − Promotes reuse of services and communicates the target A simple SOA Logger may be used to log SOA activities at various levels of detail: − Captures clients, versions, access frequency, latency, dependencies and more A SOA Dashboard tracks reuse and adoption of the „To Be‟ target by application & domain A Data Dictionary is the database of record for target data objects and abstractions Page 17 Copyright © 2006 AT&T. All rights Reserved. ‘Target’ and Implemented Services The SOA Repository supports both target & implemented services. „Target services‟ “Implemented describe „To Be‟ services” are functional capa- actually placed ilities to be built in production, out over time, and are further as defined by qualified by a architecture. “Phase” attribute. The SOA Repository is a design time discovery tool leveraged heavily by Solution Designers working on time to market projects. The UI is optimized for fast assimilation of enterprise service functionality down to the data passed to/from operations. Page 18 Copyright © 2006 AT&T. All rights Reserved. Tactical SOA: Delivering Solutions Tactical SOA is tasked with specifying and reviewing abstract SOA services in project solution designs. Design Templates and Governance Processes must be modified to capture and review service choices & impacts. − Specific target/production services must be identified, but the focus is on abstract service functionality (down to the data level); not on middleware. Service Phase Production – Target Production – Existing To Be Deleted Service Inventory Template Impact Type Create a target operation Create a non-target operation Create an operation which is expected to be deleted Create Extend an existing operation Extend an existing operation not Extend an existing operation which mapped to target mapped to target is marked for deletion Extend Reuse an existing operation Reuse an existing operation not Reuse an existing operation which mapped to target mapped to target is marked for deletion Reuse Service impacts SOA Services Architecture Diagram Sys1 must be specified Capacity Check Service as summarized on 3 Operation: initiateCapacityCheck the next slide. Invoked via an event received by the 1 GenericEventListener WSDL Event Subscription Service Operation: subscribe The service- operation is identified with Note: Every service listed The eTOM popsicle Event Broker a label stick convention here must be present in the shown at right is SOA Repository! Leverage the used to depict Event Submission Service Target Architects and SOA service-operations. 2 Operation: notify COE per the Design The circle represents Additional a service-operation Solutioning Flowchart. and extends out from Sys2 generates explanatory an event if : text may be its host. Clients • Condition 1 provided connect to it. • Condition 2 Sys2 Page 19 Copyright © 2006 AT&T. All rights Reserved. Governance SOA Enable Review (Naming, Taxonomy, SOA Modified Development SOA drives benefit by Design Granularity, Data Process Templates Objects) Design governing the creation Architects Express/One Team Templates and use of interfaces Create & Review SOA Repository (Naming, Taxonomy, Refine Target Granularity, Data APIs Target APIs Objects) Discover Design Architects & Engineers Design COE Existing/Target Solution APIs Manage Review Existing Architects Existing (Naming, Taxonomy, Production APIs & Engineers Granularity, Data APIs Objects) Architects & Engineers Design COE SOA Dashboard Approve Approve Enter Reports Implemented (Middleware (Naming, Taxonomy, (Clients, Dependencies, Technical Granularity, Data Repository Errors, APIs Standards) Objects) & Progress) Engineers & Developers IRB COE Design COE Log Receive Invocations & Process Legend: (Per SOA Log Tactical Strategic Supporting Artifacts Runtime (Batch or Real Time Level) Updates) Projects Groundwork and Infrastructure Activities Runtime Services SOA Logger Page 20 Copyright © 2006 AT&T. All rights Reserved. Foundation Integration Strategy A real world Enterprise will blend two fundamentally different ways of approaching integration. • The Integration Broker or ESB approach: – The challenge of ESBs lies not their technology but in the centralized organization required to support and develop integrations with it. Many protocols and handshaking schemes can be supported but, To the extent that it gets involved in pair-wise integrations, the ESB organization must be able to provide resources when they are requested or risk being branded as a bottleneck. • The Interoperability Standard approach: – The interoperability standard approach specifies enterprise-standard protocols and handshaking schemes, and requires all network endpoints to develop support for those standards. Once exposed to the network, a service is consumable by all endpoints. The choice of integration strategy has significant time and cost implications Page 21 Copyright © 2006 AT&T. All rights Reserved. The ESB / Integration Broker Approach Potential bottleneck if Supports many the ESB organization protocols and Organization A gets involved in most handshaking Service „A‟ client-server integra- schemes tions (organization Protocol „A‟ Handshaking „A‟ scalability issue) Service „A‟ Adapter The ESB Team Extra development (relative to an ESB Organization has great Client „1‟ Client „2‟ control over interoperability Service „A‟ Service „A‟ enforcement of approach) Adapter Adapter SOA Standards Protocol „1‟ Protocol „2‟ Handshaking „1‟ Handshaking „2‟ „A‟ Client „A‟ Client Client „1‟ Client „2‟ Organization Organization Page 22 Copyright © 2006 AT&T. All rights Reserved. The Interoperability Standard Approach Service providers All endpoints may have to express support standard Organization A their services in handshaking & Service „A‟ more than one protocols protocol (as dictated Standard Standard Protocol „1‟ Protocol „2‟ by the standard) Control over SOA standards is more There is no need difficult since Interoperability to interlock with integration are implemented by Standard a centralized ESB organization many teams Leveraging new protocols is as easy as with the „A‟ Client „A‟ Client ESB approach Client „1‟ Client „2‟ Organization Organization Page 23 Copyright © 2006 AT&T. All rights Reserved. Interoperability Standard An Interoperability standard must minimally cover: Protocol Standards − Strategy for requirements that exceed protocol capabilities Web Services has issues with large messages and extreme performance Handshaking − Credentials, callbacks, message ID, guaranteed delivery and other message semantics Vendor Product Standards Definition of the interoperable subset of protocol capabilities − WSDL & XML Schema Best Practices for Web Services Versioning strategy There is a danger in relying on emerging industry standards since vendors often implement them inconsistently Page 24 Copyright © 2006 AT&T. All rights Reserved. AT&T SOA Journey and Progress 2001-2003: Web Services Strategy A Web Services interoperability strategy was adopted in 2001 with the hope of ending redundant interface creation. Redundant interfaces common but the IRB detects them too late 2004 Realization: Establish formal 2004 We Need governance authority Executive Edict: SOA through the SDLC 2003 Thou Shalt Use SDLC Process Web Services! Confirmation Interlock of IRB 2003 Authority Political battles Review interfaces and over interface 2003 help project teams reviews First WS meet the standards Interfaces Appear Interface Web Services 2003 Review standard Board (IRB) adopted 2002 Communications 2001 2002 Formulate & training Publicize Web Services First Interop standards & Standards the policy Center of test vendors Published Excellence Page 26 Copyright © 2006 AT&T. All rights Reserved. 2004-2006: SOA Strategy In 2004, the Web Services Interoperability strategy matured into a true SOA strategy with strong Executive support. SOA Tool Updates & Merger Planning 2006 Design template SOA Tool modifications & SOA 2006 Updates incl. governance strategy Dashboard SDLC Process Interlock for SOA SOA Tools: Milestone: The business signs off Repository 2005 on $40 Million in SOA Savings & Logger Product agnostic 2005 Start of target definition: APIs & target 750 operations in 3 enterprise objects Data COE passes over 1.5 years Created Target Service SOA Center of 2004 Definition Excellence Begins Created (COE) 2004 Labs wide 2004 SOA plan, Naming, communications approach & Taxonomy & & training ROI model Best Practices Page 27 Copyright © 2006 AT&T. All rights Reserved. Other Approaches To SOA One approach does not fit all. Different strategies may work better for different organizations. For example: Implement target services in advance of Solution Design actually needing them. − Requires strategic funding! Build the SOA practice on top of key applications rather than the SDLC. − Work hard to define and implement highly reusable interfaces on key applications. − Build the NPV of the future stream of maintenance and operational costs into the estimates for non-standard functionality: Make it unacceptably high! AT&T has experimented with and had success with different approaches. Page 28 Copyright © 2006 AT&T. All rights Reserved. Summary Summary A SOA program offers great potential to cut cost, complexity and time to market. The SOA program comes into focus when the business goals are clearly articulated and quantified. Defining terms is very important since the words „SOA‟ and „service‟ are heavily overloaded and have been successfully appropriated by vendors. Executive support is essential to overcoming inertia & resistance. Many will question the need for SOA and the rationale for changing familiar practices. An ESB is not the only integration option for implementing SOA. In 2001, AT&T adopted a highly scalable interoperability strategy in which ESBs were the exception and not the rule. Other keys to success are: changing the development process, inventorying existing services, defining target services, deploying an online repository, and adopting a management strategy & dashboard. Page 30 May 29, 2010 Copyright © 2006 AT&T. All rights Reserved. For more information regarding this presentation: Please Contact Rich Erickson AT&T Labs firstname.lastname@example.org 732.567.5513 Page 31 May 29, 2010 Copyright © 2006 AT&T. All rights Reserved.
Pages to are hidden for
"AT_T SOA Experience_savings"Please download to view full document